Python has a few of these things, which is really sad.
Also, the obvious solution is self-testing code. (Jokes aside, structures like code contracts attempt something like this).
the tests are only as good as the code they're written with, and as good as the code review process they were merged under.
It avoids replicating the same category of errors in both the test and the code under test, especially when some calculation or some sub-tests generation is made in the test.
You could say that about anything and everything in software.
It's not acceptable that testing needs to be run for something the language should 100% accommodate.
The whole point of the language is to provide algorithmic clarity and avoid these things.
This isn't really an issue of 'trade offs' is just a bad feature of the language that should have been remedied more than a decade ago.
The lack of proper declaration of variables is even more absurd, there's only downside to that.
test did not work but did not fail either, imagine being that dev maintaining the code that the test professes to cover. Imagine being the user relying on the feature that test was meant to check (if the feature under test actually broke).
Along those lines. I wonder how many of these come from ad-hoc file path handling instead of using pathlib.
And there’s no evaluation of importance as to whether these instances are in test files or non-critical code. Packages are big and can have hundreds or thousands of files.
It could be that if these mattered, they would have been detected and fixed.
A good example for unit tests and perhaps checking to see if these bugs are covered or not covered.
I like these kinds of analyses but don’t like the presented like it’s some significant failure.