The truly rough thing about Python though is that that is the speed when the code is being written to a benchmark. It is really, really easy to write Python that is multiples slower than that when not writing to a benchmark and just trying to get work done without hyperoptimizing. I did some testing of Python [1] to back some other commentary I was making that compared the time it took to set an attribute repeatedly on a particular instance of an empty class to the time it took to setting it on a subclass of a subclass of a class that had a property setter that was wrapped by a decorator. The latter was about 4.6 time slower than the direct attribute setting, which was itself already ~100x slower than an attribute setting in a static language.

And it's not like a three-deep nested class with a property wrapped by a decorator is all that absurd in Python or anything. That's a completely normal case, not some absurd example I made up to skew the test.

In practice the 40-50x number is more lower bound than what you can count on. If you are actually using Python's features I think you can easily score another order of magnitude slower without anything jumping out at you as being an obviously bad idea.

[1]: https://jerf.org/iri/post/2024/not_about_python_addendum/

It seems bandit is using some decent optimizations already, looking at the `@test.checks("Call")` seems like they already captured some easy wins.

The largest win honestly would be using the same ast.walk for multiple rules, which we also did, but not mentioned in the blog.

FST: Full Syntax Tree

CST: Concrete Syntax Tree

Comment preservation is a feature