miguelgrinberg

The idea is not for the benchmarking scripts to be efficient. For this type of benchmark it does not really matter if the code is efficient or not, because I'm running the same code and comparing how it performs on different versions of the interpreter.

I mention in the article that the reason I like the Fibonacci script that I'm using is that it is extremely slow, because recursion in Python is very slow. The point is to track improvements for the class of algorithms that rely on recursion.

For those on version 15 LTS, this fix was released with v15.0.8.

> One thing I’ve noticed is that different people get wildly different results with LLMs, so I suspect there’s some element of how you’re talking to them that affects the results.

It's always easier to blame the prompt and convince yourself that you have some sort of talent in how you talk to LLMs that other's don't.

In my experience the differences are mostly in how the code produced by the LLM is reviewed. Developers who have experience reviewing code are more likely to find problems immediately and complain they aren't getting great results without a lot of hand holding. And those who rarely or never reviewed code from other developers are invariably going to miss stuff and rate the output they get higher.

The OWASP CSRF prevention cheat sheet page does mention SameSite cookies, but they consider it defense in depth: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re....

Hi, author here.

This was actually a mistake. If you look at the OWASP cheat sheet today you will see that Fetch Metadata is a top-level alternative to the traditional token-based protection.

I'm not sure I understand why, but the cheat sheet page was modified twice. First it entered the page with a top-level mention. Then someone slipped a revision that downgraded it to defense in depth without anyone noticing. It has now been reverted back to the original version.

Some details on what happened are in this other discussion from a couple of days ago: https://news.ycombinator.com/item?id=46347280.

Okay, now I understand where you are coming from.

Confession, I did not read the PR. I assumed that what is currently published in the cheatsheet is the same as the PR. This is what guided my analysis.

I will update my article to be in agreement with reality, now that I understand it. Thanks!

When I said "the maintainer is warming up to the idea" I meant to the idea of upgrading Fetch Metadata from the current status of defense-in-depth to a full solution that can replace the token-based approaches.

It is pretty clear to me that the maintainer is cautious and is seeking other expert opinions before accepting the proposed upgrade to full solution. This, to me, shows integrity and not the lack of it. I apologize if my choice of words somehow can be interpreted in any other way!

Hi, blog post author here. With regard to state-changing GET requests, I do not recommend their use and I agree that they create some problems for CSRF protection, but you are correct that I did include tests that verify that they can be enabled in my Microdot web framework.

Please correct me if I have missed anything, but I have designed this feature in my framework so that the default action when evaluating CSRF-related headers is to block. I then check all the conditions that warrant access. The idea is that for any unexpected conditions I'm not currently considering the request is going to be blocked, which ensures security isn't put at risk.

I expect there are some situations in which state-changing GET requests are not going to be allowed, where they should be. I don't think the reverse situation is possible, though, which is what I intended with my security first design. I can always revisit the logic and add more conditions around state-changing GET requests if I have to, but as you say, these are uncommon, so maybe this is fine as it is.

That tells you how much I know about the feature. :) But in any case, I'm positive that the flag was enabled, so my results are with tail calls. I suppose part of the difference between 3.13 and 3.14 could be thanks to this.

FastAPI is a web framework, which by definition is (or should be!) an I/O bound process. My benchmark evaluates CPU, so it's a different thing. There are a ton of web framework benchmarks out there if you are interested in FastAPI and other frameworks.

And numpy is a) written in C, not Python, and b) is not part of Python, so it hasn't changed when 3.14 was released. The goal was to evaluate the Python 3.14 interpreter. Not to say that it wouldn't be interesting to evaluate the performance of other things as well, but that is not what I set out to do here.

There is no "realistic" benchmark, all benchmarks are designed to measure in a specific way. I explain what my goals were in the article, in case you are curious and want to read it.

The build of Python that I used has tail calls enabled (option --with-tail-call-interp). So that was in place for the results I published. I'm not sure if this optimization applies to recursive tail calls, but if it does, my Fibonacci test should have taken advantage of the optimization.

Thank you so much!

Keep in mind that the two scripts that I used in my benchmark are written in pure Python, without any dependencies. This is the sweet spot for pypy. Once you start including dependencies that have native code their JIT is less efficient. Nevertheless, the performance for pure Python code is out of this world, so I definitely intend to play more with it!

One reason is that I did not spend much time optimizing the Node and Rust versions, I just translated the Python logic as directly and quickly as I could. At least I did not ask an LLM to do it for me, which I hope counts. ;-)

Edit: fixed a couple of typos.

You have made my day, sir. :)

This is true for any kind of project, regardless of hardware or software stack. You always need to evaluate the performance for the specific use case you are targeting to make sure it falls in the expected range, and it is your job to do this evaluation as the project owner, because only you know the specifics of your project.

The point I was trying to make in my reply above was that an abstract RPS number, obtained measuring a general purpose web app on a general purpose microcontroller does not mean anything. What matters is your own performance evaluation.

You got it backwards. If I were to release a benchmark for Microdot, everyone would say that it is biased!

The article you are referring to is intended to benchmark microcontrollers running MicroPython. Nothing to do with Microdot.

I'm not really sure what conclusions you expect to reach if you had a Microdot benchmark that gives you a requests per second number. I would not stop using microcontrollers if the number was low, and I wouldn't start more projects if the number was high. I don't really care. It works for the intended purpose.

It's important to note that for most small devices that run MicroPython asyncio is the only available method of concurrency.

These devices have no concept of processes, your application is the only thing that runs. Most devices do not support threads, and those that do have really big limitations. Like for example, a device with two cores would allow you to spawn just one thread, to run on the second core and that's it. This is due to the lack of a proper operating system with a scheduler that can move threads in and out of the CPU.

Right. Microdot just gives you the support to build the web application. This is built on top of the standard asyncio Python library, so you are likely to find good support for most tasks in the ecosystem.

You are more than welcome to evaluate Microdot on the specific device you are interested in. It is good to keep in mind that people don't run web apps on microcontrollers because they have good performance. Don't expect any miracles.

I wanted to use MicroPython for this. I have nothing against C, it is a language that I actually know and use for other projects, but I wanted the challenge to try to build something similar to Flask or FastAPI that could run well on small devices.

To clarify this, note that the extensions are entirely optional, and unlike what you are saying, most do not require any dependencies.

The only two extensions that use dependencies are the one that adds template rendering, and the one that implements secure user sessions.

For templates, you can use Jinja on CPython (where you wouldn't normally have space issues), or the uTemplate library (https://github.com/pfalcon/utemplate) on MicroPython, which is quite small.

For secure sessions, on CPython you have to add PyJWT. On MicroPython you need to add the HMAC and JWT modules from the MicroPython standard library, which are not installed by default. These are also very small.

Thanks. The smart heating device in question is one that is fairly popular in Ireland, but I believe it isn't sold elsewhere. The brand is Climote (https://www.climote.ie/).

As part of the service, this controller gives you the option to send commands through an app, or by sending SMS (the device comes with a SIM card and gets its own mobile number). The commands would allow you to ask if the heating is running or not, to turn the heating on or off, and so on.

I first implemented the SMS interface with Twilio, but then found that the number of texts you can send to the device is capped. I don't remember what was the monthly allowance, but I reached it in a few days after querying the device every 15 minutes or so 24/7.

I then found a project on GitHub with the reverse-engineered API that the phone app used to send commands. So I then reimplemented the command logic using this API to be able to talk to the controller without limitations.

I'm not familiar with the Nest devices, but I'd suggest you do a search on GitHub to see if someone figured how to reverse-engineer its API.

Always a nice surprise to find my stuff on the front page. If you have any questions about Microdot, I'm here to answer them!

Thanks, will keep it in mind!

I have written a few microservices/APIs with Microdot, actually. Works really well for that.

If you deploy it with a production grade web server (uvicorn, etc.) it should be able to scale just fine, while using less RAM than the larger frameworks.

It has some traction in the MicroPython community, used with IoT projects running on microcontrollers.

Yep!