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 𝗶𝗻𝘃𝗼𝗰𝗮𝘁𝗶𝗼𝗻_𝘁𝗿𝗲𝗲: www.invocation-tree.com/#codeurl=https%3A%2F%2Fra…

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.