Data structures like Trie can in Python be easier understood and debugged after visualization using the memory_graph package.

A Trie is a tree of dictionaries and can be used for things like word completion.

geteilt von: https://programming.dev/post/42846946

Hi everyone,

we, the iceoryx community, just released iceoryx2 v0.8, an ultra-low latency inter-process communication middleware in Rust, with C, C++, Python and with this release, C# bindings.

If you are into robotics, embedded real-time systems (especially safety-critical), autonomous vehicles or just want to hack around, iceoryx2 is built with you in mind.

Check out our release announcement for more details: https://ekxide.io/blog/iceoryx2-0.8-release

And the link to the project: https://github.com/eclipse-iceoryx/iceoryx2

TL;DR Over the last several years, tools like uv, Pydantic, FastAPI, and type hints have made Python DX feel as modern as TypeScript, with similar performance and type safety.

We are thrilled to announce that the Sovereign Tech Agency has committed to a €86,000 investment in work to be performed by the Python Software Foundation to improve the security of CPython and the Python Package Index (PyPI).

I'm doing a course on coding with Python and we were told to install Anaconda and Jupyter Notebook.

I followed this installation guide and am currently at the part "Post Installation Guide", I have installed Jupyter notebook. https://thelinuxcode.com/install-anaconda-in-linux-mint-20/

As a further step it says: Launch Anaconda Navigator If you prefer graphical application interfaces, Navigator brings an intuitive package manager, notebook launcher, and IDE options like Spyder3.

I've been going through my applications but I can find neither Anaconda Navigator nor Jupyter there and I have no idea what I'm supposed to do next.

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).