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

Hi, I'm creating a web app using flask, the app has an api and a frontend that uses that api, the authentication system uses a JWT, heres the login code for the api:

@api.route("/login", methods=["POST"])  
def api_login():  
    username = request.json.get("username")  
    password = request.json.get("password")  

    # Checks if both a username and a password were submitted  
    if not (username and password):  
        return jsonify({"successful": False, "status": "Either a username or a password wasn't submitted", "code": 2}), 400  

    # Search the user by username  
    user = db.session.scalars(db.select(User).where(User.username == username)).one()  

    # Checks that both the username and the password are correct  
    if user is None:  
        return jsonify({"successful": False, "status": "Username or password incorrect", "code": 1}), 401  
    if not check_password_hash(user.password_hash, password):  
        return jsonify({"successful": False, "status": "Username or password incorrect", "code": 1}), 401  

    # Create a JWT and returns it  
    token = create_access_token(identity=username, expires_delta=False)  
    return jsonify({"successful": True, "jwt": token})  

In the frontend, I have an html login page returned by flask with the following code

@users.route("/login")  
def login():  
    return render_template("auth/login.html")  

this page sends a request from a form to the api via javascript, now here's the problem, from what I can gather online the most secure way to store the returned jwt is in an httponly cookie however that means that the javascript code can't create the cookie. I can see multiple ways to solve this problem but all of them have drawbacks, the first one would be to add, in the flask frontend code, a url to store a jwt in an httponly cookie and then from javascript, call that endpoint, however it feels strange to have a url never directly accessed by the browser in the frontend. I could also put that same code in the api, but that feels even stranger as that endpoint would be specific to the frontend and wouldn't be used by eg. a mobile app. Finally, I could store the jwt in an unsecure cookie, or localstorage, this is apparently less secure due to the risk of an xss attack but it seems to be the approach of several frontends for lemmy. Is there a better way to store the token that I'm not thinking of, if not which solution would be the best?

So, I'm making documentation for my project using Sphinx with hatch/hatchling. I'm currently using the sphinx-rtd-theme as my theme. I already make a quickstart page for my project, but the src directory page is included in the sidebar. I would like to rename it to "Source Files", but when changing the header in my modules.rst file, it gets reset each time I build.

The main extensions I'm using for Sphinx are 'sphinx.ext.todo', 'sphinx.ext.viewcode', and 'sphinx.ext.autodoc'.

For context, my project structure looks something like this:

my_project/
| ---- requirements.txt
| ---- README.md
| ---- src/
| -------- my_project_module/
| -------------- __init__.py
| -------------- foo.py
| -------------- bar.py
| -------- docs/
| -------------- requirements.txt
| -------------- requirements.in
| -------------- conf.py
| -------------- modules.rst
| -------------- index.rst
| -------------- quickstart.rst
| -------------- my_project_module.rst
| -------------- _static/
| ------------------ some_img.png

Is there a way to change the display name of my src directory without renaming the actual directory in my project?

Also, is there a way to reorder the list so my quickstart guide shows up above the source page?

I'm trying to create a web app with flask and most tutorials I can find recommend using flask-login, however the last release was around two and a half years ago and the last commit was nine months ago. The only statement I could find is this issue where the maintainer says it's still maintained but there has only been one new commit since then. Is it still safe to use, if not, what alternatives are there?

I kept struggling to sit down and start my side projects, so I tried reading more about productivity and motivation. At some point I realized I just needed something simple to get me moving — so I wrote a tiny Pomodoro timer in Python.

It’s intentionally minimal: you enter the title, work time, break time, and number of intervals. After the session it generates a short report and asks you to write your own conclusion. I like reviewing these later, so I added that part for myself.

I enjoy building small tools instead of searching for the “perfect” app, and Python made it easy to keep everything clean and simple.

Works on Windows & Linux, pure Python.

GitHub: https://github.com/Mietkiewski/MPomidoro
Gumroad PWYW $0+: https://mietkiewski.gumroad.com/l/mpomidoro

I saw that PiWheels posted their PyPI (pronounced pie-pee-eye, not pie-pie as that's the JIT interpreter) article, showing off some neato stats, like the longest PyPI package names, and such.