I built idemkit after cleaning up duplicate charges one too many times.

The version everyone writes checks whether a key has been seen and replays the stored response. Two requests a millisecond apart both find nothing and both charge the card. And if the worker dies between charging and recording it, the retry charges again. Neither reproduces locally.

idemkit does it properly: an atomic claim instead of check-then-act, a lease that expires on the storage server's clock, and a fencing token so a stalled worker can't overwrite a good result.

from idemkit import idempotent, RedisBackend, MethodConfig 

@idempotent(
    backend=RedisBackend.from_url("redis://localhost:6379"), 
    config=MethodConfig(key_fields=["order_id"]), 
) 
async def charge(*, order_id, amount): 
    return await payments.charge(order_id, amount)

One core, three ways to use it: middleware for FastAPI/Flask/Django, a queue consumer wrapper or @idempotent on any function. Backends are Redis, Postgres, Mongo, DynamoDB, or in-memory for tests.

pip install idemkit, Apache-2.0: https://github.com/idemkit/idemkit

If you find it useful, I'd appreciate a star. It's new, so visibility helps a lot right now.

Recursion becomes much easier once students have the right mental model. Visualization will help get them there.

Take the Tower of Hanoi problem. The recursive solution is beautifully short, to move n disks we:

• first remove n-1 disks from the largest disk
• then move the largest disk
• and then move the n-1 disks back on top

But when students try to implement recursion, they often get stuck, and adding debug prints only adds to the confusion. That is where visualization can help to bring the right mental model. Here is the Tower of Hanoi problem solved recursively, visualized with 𝗶𝗻𝘃𝗼𝗰𝗮𝘁𝗶𝗼𝗻_𝘁𝗿𝗲𝗲: https://www.invocation-tree.com/#codeurl=https%3A%2F%2Fraw.githubusercontent.com%2Fbterwijn%2Fmemory_graph_examples%2Frefs%2Fheads%2Fmain%2Ftowers_of_hanoi.py&timestep=0.5&play=

Instead of thinking about “a function calling itself again and again” students can now see the depth-first execution of a tree of subproblems showing the divide-and-conquer strategy in action. Once a student can think in terms of a tree of subproblems, recursion becomes much easier to understand, explain, and debug.

#Python #invocation_tree #Recursion

app.frontend() seems really handy!

So I have a Python package following the project structure outlined by the Python Packaging User Guide (Without the tests/ directory). Let's call it Package A.

This package can be used alongside another package, Package B, however no proper compatibility exists in Package A to support Package B's rendering system.

I want to make a compatibility package, Package AB, to make Package B's systems work with Package A. It shares the same dependencies as Package A, however it has Package B as a dependency.

How should I setup my project structure for Package AB? Should it be its own project directory? Should it be nested inside Package A's src directory?

Additionally, I have Sphinx /w Hatch setup with Package A for documentation. Depending on the setup chosen above, how should I setup documentation for Package AB?

Some things to note:

• Package AB would use classes and methods from Package A and Package B
• Package B's license (MIT) is compatible with Package A (GPLv3). Package AB would be licensed under the same as Package A

If more details are required, let me know.

The difference in Python OOP between:

• instance method
• class method
• static method

visually explained using 𝗺𝗲𝗺𝗼𝗿𝘆_𝗴𝗿𝗮𝗽𝗵:

I think I get why Cloudflare's CTO is asking this question.  personally started using Django for backend development, boy, that thing is robust and cool, esp...

It's rather easy to gather basic system performance metrics and info. Still, with game performance metrics like FPS, Python has to use existing specialized apps and parse their output or read their shared memory.

Not all coders are created equal. But there should be a line where we collectively just say, "Please stop".

Would like to say found two critical issues in two Python packages, but it's obvious to a six year old. Not sure can claim credit for such in your face obvious issues.

And since it's so obvious, responsible disclosure kinda got kicked to the curb.

These libraries pin the required dependencies and test only one python interpreter, so lets just say had lowered expectations going in.

get-gecko-driver and get-chrome-driver look like they are unneeded since both selenium and webdriver-manager can download selenium webdrivers. In the later two packages, web browser support is sparse; there is room for more flexibility. For example, support for waterfox, librewolf, and mullvad-browser.

Issues summary:

1. downloader module can send a GET request to any URL. There is no URL whitelist. These packages can be used for cover when making arbitrary GET requests.

2. downloader can save anywhere on the file system. So can be used for other purposes besides downloading selenium webdriver.

3. no permission checks before saving/writing the file.

4. get_gecko_driver.downloader and get_chrome_driver.downloader are the exact same module.

I lack confidence the author will respond, will be very pleasantly surprised if the author fix these issues in a timely manner. Nor confidence he'd do a good job. But at least these issues are disclosed and the ball is in his court.

For your entertainment:

All these coding errors are unforgivable and obvious to even a novice coder, a laymen, or a random drunk. It takes talent not to see it. If bothered to do unit testing, would be unavoidable to not see it.

These issues are both CRITICAL SECURITY issues.

Obvious is obvious, don't kill the messenger, instead lets just fix this issue. The correct action is to quickly fix it and then just agree never to mention it again and pray there is no Darwin award for coders.

We would like to take a moment to talk about the experimental just-in-time compiler in CPython, and the path we think it should take from here.

Over the past several years, several core developers and contributors have been building a JIT compiler in the main branch of CPython. We want to begin by thanking them. This has been hard, deeply technical work that has been done with great care, and the recent performance improvements are real and encouraging. None of what follows is a criticism of that effort or of the people behind it. Quite the opposite. It is precisely because the project has been underway for so long, undergoing several re-architectures, that we think now is a good time to re-evaluate the JIT’s informal status in the project.

When the JIT was originally merged into main, it entered as an experiment, and the only enhancement proposal written about it, PEP 744, is Informational. That PEP did valuable work in explaining the initial design and even sketched the criteria under which the JIT might become a permanent feature, including questions it explicitly left open: committed long-term maintainers, a security review, debugging and out-of-process tooling support, the guarantees the runtime would make, and the obligations the JIT would place on redistributors and downstream packagers. There has also been a fair amount of back and forth over the years, on that PEP and elsewhere, and we acknowledge that a good deal of useful communication has happened along the way. We want to be clear that we are not implying that the authors have intentionally bypassed the formal process. The responsibility is a shared one, ourselves included: collectively we (the Steering Council) have not been as strict about following the process as a change of this complexity and reach deserves. Those open questions in PEP 744 (and more) are exactly the kinds of commitments that the community should weigh and agree to through the PEP process, and they have not yet been settled.

For that reason, the Steering Council is formally requesting a Standards Track PEP be authored that the community can discuss and the Steering Council can formally accept (or reject), making the case for the JIT as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors.

Until such a PEP is accepted, we ask that no new development on the JIT land on main, including new features, optimizations, and performance work. Bugfixes and security fixes may of course continue as normal; the request is specifically that no further new JIT functionality be added until a PEP has been accepted.

While the intent is not to call for competing proposals, we believe that now is a good time to discuss and propose alternative proposals as well. We believe this approach is also consistent with our previous long-standing view that experiments should not be done on the main branch of CPython without a backing PEP.

For example, rather than proposing one single concrete JIT implementation, it may make more sense for the PEP to describe a JIT infrastructure that can support multiple implementation strategies. Since many different and promising JIT tracing approaches continue to be proposed, we believe the infrastructure should make it easy to experiment with and evaluate those approaches within CPython rather than be highly coupled with a single strategy.

We would like the PEP to address at least the following points:

• Maintenance is a real concern for a subsystem of this size and complexity, and the PEP should set out a clear plan for how the JIT will be sustained and maintained over the long term and how it will impact maintainers and contributors that don’t directly contribute to the JIT.

• How it will keep compatibility with existing CPython features and tooling. How the JIT interacts with, and what it guarantees for, the capabilities CPython already supports. This includes things such as free-threading, profilers, and debuggers, but the PEP should treat this broadly and with nuance rather than as a fixed checklist.

• Clear, measurable success metrics and timelines. What the project is aiming for and by when, for example performance targets, platform coverage, and memory overhead.

• Relationship to other JIT compilers. Whether the design is intended to provide general infrastructure that other efforts could build on, and whether it is expected to be compatible or incompatible with third-party JIT implementations such as CinderX, Numba, and PyTorch or any other 3rd party JIT.

• Whether the current JIT architecture is considered stable, or likely to change further.

This list is not exhaustive. It is meant to be indicative of the kinds of questions we want the PEP to engage with, and we expect further points to be added as the community discussion evolves.

We are setting a window of six months for a PEP to be submitted and resolved. If no such PEP is accepted within that window, the JIT code must be removed from the main branch and development must be continued outside the main Python repository.

We know this asks something of the people who have invested years in this work, and we don’t take that lightly. We see this not as winding the project down but as giving it, and the community, the clarity and the explicit commitment that a change of this magnitude to CPython’s runtime deserves.

Thank you for your understanding, and for everything you’ve built so far.

— The Python Steering Council