Python 3.15: features that didn't make the headlines

(changs.co.uk)

87 points | by rbanffy 1 hour ago

3 comments

  • JohnKemeny 39 minutes ago
    > I've left this one to the bonus section because I've never used set operations on Counters and I'm finding it extremely hard to think of a use case for xor specifically. But I do appreciate the devs adding it for completeness.

    Check out symmetric difference

    https://en.wikipedia.org/wiki/Symmetric_difference

  • kokada 1 hour ago
    From this example:

        lazy from typing import Iterator
    
        def stream_events(...) -> Iterator[str]:
            while True:
                yield blocking_get_event(...)
    
        events = stream_events(...)
    
        for event in events:
            consume(event)
    
    Do we finally have "lazy imports" in Python? I think I missed this change. Is this also something from Python 3.15 or earlier?
    • llimllib 39 minutes ago
    • karpetrosyan 16 minutes ago
      Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions
    • boxed 1 hour ago
      Yes, 3.15+
    • rad120 50 minutes ago
      Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports (1% of which are probably Shai Hulud now).

      And now even type imports are apparently so slow that you have to disable them if unused during the normal untyped execution.

      If Instagram or others wants a professional language, they should switch to Go or PHP instead of shoehorning strange features into a language that wasn't built for their use cases.

      • stingraycharles 47 minutes ago
        > Python is such a weird language. Lazy imports are a bandaid for AI code base monstrosities with 1000 imports

        Just because you don’t like a feature doesn’t mean it’s because of AI and bad code.

        • sigmoid10 42 minutes ago
          I think this is just a natural consequence of an easy-to-use package system. The exact same story as with node. If you don't want lots of imports, don't make it so damn easy to pile them into projects. I'm frankly surprised we still see so few supply chain attacks, even though they picked up their cadence dramatically.
      • novov 30 minutes ago
        Empirically, I have used the current accepted way to do lazy imports (import statement inside a function) before AI coding was even a mainstream thing, for personal code that sometimes needs a heavy import and sometimes doesn’t.

        The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.

        • afH12 23 minutes ago
          As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them.

          Python-dev now is paid to shore up the failed Instagram stack.

          • brookst 6 minutes ago
            I too am outraged that a product would prioritize its biggest users.
      • formerly_proven 24 minutes ago
        On most unix-likes all "imports" via shared libraries (e.g. in C / C++) are lazy by default.
  • brianwawok 1 hour ago
    I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.
    • zabzonk 15 minutes ago
      Three things I find unlikely about this:

      - You wrote 100K lines of code (I've worked on several large C++ projects that were far smaller)

      - You wrote those lines in Python (surely the whole point of Python is to write less code)

      - You deleted them (never delete anything, isn't this what modern VCS is all about?)

      But whatever floats your boat.

    • BOOSTERHIDROGEN 24 minutes ago
      Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?
    • stuaxo 49 minutes ago
      This is straightforward in the first instance, but how do you see maintenance of those projects going forward - especially adding more complex features ?

      I can see one way forward being to prototype them in python and convert.

    • physicsguy 1 hour ago
      Go is terrible for scientific/ML work though, the libraries just aren't there. The wrapping C API story is weak too even with LLMs to assist.

      Try and write a signal processing thing with filters, windowing, overlap, etc. - there's no easy way to do it at all with the libraries that exist.

      • LtWorf 1 hour ago
        I think the purpose of go is to write CRUD. Stray from that and you're on your own.
    • shankysingh 1 hour ago
      Thats very intersting, If I may ask was it from professional projects or personal projects?
    • mountainriver 1 hour ago
      Same, I’m not sure how Python survives this outside of machine learning.

      All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do

      • prodigycorp 1 hour ago
        the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.
        • rplnt 8 minutes ago
          AI benefits from tools to verify its halucinations. That's much easier in a typed and compiled language. Then have a language that can't be monkey patched at runtime and the confidence increases even more.

          If you mean "easy to get something out of it" then yeah, it's great.

        • tyre 32 minutes ago
          I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar.

          Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??)

          Type decoration has been a welcome addition, but too slowly iterated on and the native implementations (mypy) are horribly slow at any meaningful size.

          Concurrency was never good and its GIL+FFI story has boxed it into a long-term pit of sadness.

          I’ve used it for years, but I’m happy to see it go. It didn’t win because it was the best language.

          • zabzonk 5 minutes ago
            > there’s a reason no other language went this way)

            Except of course for those that did, Haskell, Fortran for example.

          • groundzeros2015 17 minutes ago
            I’m always baffled when language complaints come down to syntax
        • lexicality 51 minutes ago
          a lot of the training data is either for python 2 or just generally very low quality
          • prodigycorp 37 minutes ago
            That could be it. I still see LLMs fail a set of static typing challenges that I created a couple years ago as a benchmark. Google models still fail it. I wonder if the lack of typing in a lot of the training data makes python harder to reason about?
          • stuaxo 47 minutes ago
            The quality issue doesn't seem unique to Python.

            The versioning issue I've seen across libraries that version change in many languages.

            I don't tend to hit Python 2 issues using LLMs with it, but I do hit library things (e.g. Pydantic likes to make changes between libraries - or loads of the libraries used a lot by AI companies).

        • lsbehe 50 minutes ago
          The tons of python code would be great training data if there was any consistency across the ecosystem. Yet every project I've touched required me to learn it's unique style. Then I'd imagine they practically poisoned half the training set because python2 is subtly different.
      • LtWorf 1 hour ago
        You can test on the device directly, without needing to recompile to try something.
    • deppep 46 minutes ago
      i don’t really see it this way. the value of a token in Python is much higher than it is in lower-level language