Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • "AI reflex-app builder" slop alert
    by ozgrakkurt
  • I really enjoy making Python faster. I feel like the sweet spot for me is proving a concept with the dumbest possible implementation to show that something would work, and then using that as a comparison implementation to prove that later improvements match the results of the dumb, obviously correct implementation.
    by anitil
  • I wonder if these lints could have been expressed as semgrep rules?
    by fwip
  • The second part, where it says that Rust is faster than Python, is so obvious than doesn't deserve any further comments. What I found interesting, is that idiomatic Python, with generators and all, can be so much worse than "C-style" Python, if you will pardon that term. It's a pity many kids are taught Python before C...
    by teo_zero
  • I still recommend to use idiomatic Python though. If you like C-style Python, you can use Cython and get a performance boost at the same time.
    by Loranubi
  • Could this ast.sprint ast.walk optimization make libCST or bandit faster? https://news.ycombinator.com/item?id=39111747

    libCST: https://github.com/Instagram/LibCST

    bandit: https://github.com/PyCQA/bandit

    Links to codemod tools; "Baby Steps into Genetic Programming" https://news.ycombinator.com/item?id=43617655

    by westurner
  • AST: Abstract Syntax Tree

    FST: Full Syntax Tree

    CST: Concrete Syntax Tree

    Comment preservation is a feature

    by westurner
  • it's possible! although many of the constraints in this blog were because we wanted to work with ast module in Python. If we were allowed to create our own types, we can do so much better. I think ruff has an even faster walk by those standards.

    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.

    by adhami
  • It’s amazing how much Python punishes you for modularizing your code
    by bionhoward
  • I appreciate that you first tried to optimize the original Python code. Idiomatic Python is unfortunately disappointingly slow and not so interesting to compare to.
    by eska
  • > not so interesting to compare to

    Absolutely disagree here, something that is considered good practice is very interesting to compare to!

    by flockonus
  • I've generally taken the position that if you're considering doing micro optimizations in your python code you should just switch to another language instead. The gains from switching language are going to be so much higher than the gains from trying to get the python interpreter to be a little less slow (and empirically, every time I've seen it tried the code has been rewritten in the end anyway).
    by rcxdude
  • I often use the rough approximation that Python is 40-50x slower than C. This is what you'll see in the benchmarks.

    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/

    by jerf