We're behind on our Python release updates, so I was reviewing older Python releases and found this gem at the bottom of the 3.12 notes:

They have no need of our help

So do not tell me

These haggard faces could belong to you or me

Should life have dealt a different hand

We need to see them for who they really are

Chancers and scroungers

Layabouts and loungers

With bombs up their sleeves

Cut-throats and thieves

They are not

Welcome here

We should make them

Go back to where they came from

They cannot

Share our food

Share our homes

Share our countries

Instead let us

Build a wall to keep them out

It is not okay to say

These are people just like us

A place should only belong to those who are born there

Do not be so stupid to think that

The world can be looked at another way

(now read from bottom to top)

Refugees, by Brian Bilston

Data structures become much easier to understand when students can see the structure of their data visualized using memory_graph. A data structure is no longer an abstract idea but concrete, clear and debuggable. Here’s a live demo of a Linear Linked List: https://memory-graph.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph%2Frefs%2Fheads%2Fmain%2Fsrc%2Flinked_list_lin.py&breakpoints=27&continues=1&timestep=0.2&play=

Hi there! After writing approximately the same bunch of test functions at two jobs, I've extracted a little pytest library for doing expectation testing the way that I like to, and published in the usual places. So, I thought I'd tell y'all about it.

Essentially, it allows lots of variations of this kind of test:

def test_compute(resources):  
    input = resources.load_json("input")  
    output = compute(input)  
    resources.expect_json(output, "output")  

The input data and expected results will be located in predictable places relative to the test function, and in a format that is nice to work with as a developer. No magic pickles or multiple expectations squashed into a single file that you're afraid to edit.

It works well with text data, json and pydantic models and others may appear over time. Test file path creation is completely configurable, but I think the defaults are reasonable.

I'd love for it to see some usage and to get some feedback about how to make it better.

That's it!

An exercise to help build the right mental model for Python data. The “Solution” link uses memory_graph to visualize execution and reveals what’s actually happening:

• Solution: https://memory-graph.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph_videos%2Frefs%2Fheads%2Fmain%2Fexercises%2Fexercise19.py&play=
• Explanation: https://github.com/bterwijn/memory_graph?tab=readme-ov-file#python-data-model

With a project structure like this:

├─main.py
└─src
    ├─dep1.py
    └─dep2.py

where the contents of each file is as follows:

main.py: import src.dep1 as firstdep; print("Total success")

dep1.py: import dep2 as seconddeb; print("success 1/3")

dep2.py: print("success 2/3")

Is the best way to do this creating an __init__.py file in src and importing src.dep2 in dep1.py? or is this a bad idea?

Barry Warsaw, writing for the Python steering council, has announced that PEP 810 ("Explicit lazy imports") has been approved, unanimously, by the four who could vote. Since Pablo Galindo Salgado was one of the PEP authors, he did not vote. The PEP provides a way to defer importing modules until the names defined in a module are needed by other parts of the program. We covered the PEP and the discussion around it a few weeks back. The council also had "recommendations about some of the PEP's details, a few suggestions for filling a couple of small gaps", including:

Use lazy as the keyword. We debated many of the given alternatives (and some we came up with ourselves), and ultimately agreed with the PEP's choice of the lazy keyword. The closest challenger was defer, but once we tried to use that in all the places where the term is visible, we ultimately didn't think it was as good an overall fit. The same was true with all the other alternative keywords we could come up with, so... lazy it is!

What about from foo lazy import bar? Nope! We like that in both module imports and from-imports that the lazy keyword is the first thing on the line. It helps to visually recognize lazy imports of both varieties.

Python already has several ways to run programs concurrently — including asynchronous functions, threads, subinterpreters, and multiprocessing — but all of those options have drawbacks of one kind or another. PEP 703 ("Making the Global Interpreter Lock Optional in CPython") removed a major barrier to running Python threads in parallel, but also exposed Python programmers to the same tricky synchronization problems found in other languages supporting multithreaded programs. A new draft proposal by Mark Shannon, PEP 805 ("Safe Parallel Python"), suggests a way for the CPython runtime to cut down on concurrency bugs, making it more practical for Python programmers to use versions of the language without the global interpreter lock (GIL).

Understanding and debugging Python data structures gets easier with memory_graph visualization. Here's a Multiway Tree example. A Multiway Tree is similar to a Binary Tree but has an arbitrary number of children making the tree less deep and more efficient.

An exercise to help build the right mental model for Python data. The “Solution” link uses memory_graph to visualize execution and reveals what’s actually happening:

• Solution
• Explanation

Though I still consider myself active, the other maintainers are... not really. We require approval from a maintainer who didn't author the PR to merge a PR, and thus 4 PRs have been collecting dust waiting for review for half a year now, including the quite critical #376 addressing more indent_namespace false positives.

While maintainers don't necessarily need to commit code, they do need to learn how the code works so they may check code quality when reviewing PRs. Some Python experience would be preferred.

The Python Software Foundation, earlier this year, successfully obtained a $1.5 million grant from the US National Science Foundation "to address structural vulnerabilities in Python and PyPI". The actual grant came with some strings attached though, in the form of a requirement not to pursue diversity, equity, and inclusion programs. So the Foundation has withdrawn the proposal rather than agree to terms that run counter to its own mission.

We're disappointed to have been put in the position where we had to make this decision, because we believe our proposed project would offer invaluable advances to the Python and greater open source community, protecting millions of PyPI users from attempted supply-chain attacks. The proposed project would create new tools for automated proactive review of all packages uploaded to PyPI, rather than the current process of reactive-only review.

cross-posted from: https://lemmy.dbzer0.com/post/56411678

https://fosstodon.org/users/ThePSF/statuses/115446659188615376

I'm looking for a way to generate a single Markdown (.md) file that includes all the file names, function definitions, and docstrings from my Python files. Ideally, this should traverse a directory recursively while respecting the .gitignore rules.

Does anyone know of a package that accomplishes this?

An exercise to help build the right mental model for Python data. The “Solution” link uses memory_graph to visualize execution and reveals what’s actually happening:

• Solution
• Explanation