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.

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.