I think we should hold claims about effective static analysis and/or program verification to a higher standard than this.
[1]: https://github.com/psf/requests/blob/4bd79e397304d46dfccd76f...
It’s correct to flag this code. The check is performed manually outside of the function in question. If you call the function directly, the bug surfaces.
There is no mention in the function documentation of the validation requirement, making it easy to call incorrectly. Also, if it is required to call the validator before calling this function, then the function could just call it itself.
In short, it’s possible to make this code safe by definition, but instead it relies upon the developer to always make the undocumented right choices every single time it is called. I would expect something more rigorous from verified code.
No, that’s just called a precondition. I’m not aware of a single program that doesn’t have functions like these, particularly internal APIs.
(It should go without saying, but it’s not even an issue in this case: it’ll cause an IndexError, but so will thousands of other APIs. Python very explicitly doesn’t have exceptions in its type contract; anything can always raise anything.)
> I would expect something more rigorous from verified code.
Nobody said that requests is “formally verified.” The only place where that claim is made is in the AI-generated blog post above.
I think you just want the illusion of safety :p
A big advantage of verified code is that it enables you to write the sketchy and dangerous-looking code BECAUSE it's proven correct
In fact, skipping as many safety checks as possible is highly desirable. For performance, yes, but also because it's less code to maintain.
Our tools already do this to some extent, for performance. E.g. compilers that remove your bounds or type checks in the generated code when it can prove it's not needed.
There's nothing inherently wrong with a function throwing an exception when it receives invalid input. The math.sqrt function isn't buggy because it fails if you pass it a negative argument.
I disagree. If the obvious way to use an API is the incorrect way, there is a problem with the code.
If you must call A each time before calling B, drop A and have B do both things.
If you must call A once before calling B, make A return a token that you then must pass to B to show you called A.
As another example, look at https://blog.trailofbits.com/2026/02/18/carelessness-versus-... (HN discussion: https://news.ycombinator.com/item?id=47060334):
“Two popular AES libraries, aes-js and pyaes, “helpfully” provide a default IV in their AES-CTR API, leading to a large number of key/IV reuse bugs. These bugs potentially affect thousands of downstream projects.”
Would you call that “poor code style that could theoretically lead to a bug in the future”, too?
Invariant-preserving types are always going to be the right way to eliminate certain classes of bugs, but they’re also completely overkill in this context given that the “bug” in question doesn’t even cause unsound program behavior; it just raises an exception, which is completely sound and well-defined.
It's possible to have no false positives or no false negatives, but it can be proven it's impossible to have neither of them.
(In case it isn’t clear, I’m saying this is slop that someone whipped up and didn’t even bother to spot check.)
Well, you'd get this embarrassing mess, apparently.
And yes, the exclamation mark matters!
Should we even read this or should we get an LLM to summarise it onto a few bullet points again?
This bit was interesting in illuminating the human authors’ credulity (assuming they believe in their own article):
‘The central move was elegant: stop asking only “is the system safe?“, start asking “how far is it from safety?“‘
This ersatz profundity couched in a false opposition is common in generated text - does it have anything at all to do with the code generated or is it all just convincing bullshit?