5 ms·

> Python 3.14.0 introduced a new incremental garbage collector. But reports of higher memory usage caused the Python team to revert the garbage collector change

> Python 3.14.0 introduced a new incremental garbage collector. But reports of higher memory usage caused the Python team to revert the garbage collector changes in 3.14.5. If they didn't have very good objective reasons the new GC is better, they never should have shipped it. If they do, they should not have reverted the change.

moron4hire 4mo ago
It's this sort of stuff that leaves me scratching my head why people like Python so much. I hear them say they prefer the syntax and personally I feel like that's such a small part of the holistic experience of working with any particular language. It's one of the reasons why I gave up on C++ years ago for .NET, the whole system of tooling in .NET has never left me feeling like I was pigeonholed into doing things in stupid, self-flagelating ways. Why should I use a language like C++ that doesn't provide a standard set of package management and build tools? Why should I use a language like Python that feels like it's being designed by amateurs? I felt like the tooling in Racket, CLisp, and Java were similarly pragmatic and not either religiously devoted to some concept of "backwards compatibility" that I seriously doubt most people actually need, or "ease of use" that actually proves itself to be easy when you consider the not-happy-path of the beginner tutorials. Racket, I didn't continue just because the library ecosystem isn't mature enough to keep up with the latest in databases and other 3rd party services. Java I quit largely because of Oracle and some 2010s problems with stagnation. CLisp mostly because it was too hard to socialize. But never because I thought the core language and tooling were holding me back.
- SJC_Hacker 4mo ago
  Python is mostly about the “batteries included” standard library and what’s becoming nearly standard third party libs, being able to play around in the REPL,
  - Kwpolska 4mo ago
    The standard library is full of dead batteries. If the stdlib is so good, why does everyone install requests instead of using the stdlib http client? And why requests or something like it hasn't been adopted into stdlib after so many years of stability?
    - necovek 4mo ago
      Parts of requests has been adopted into stdlib: https://docs.python.org/3/library/urllib.request.html https://docs.python.org/3/library/urllib.request.html People mostly defer to requests because they do not track language development closely and because we are creatures of habit. I try to avoid non-stdlib packages when stdlib will do a good job, but I received negative feedback from people who aren't aware of the updates and couldn't foresee supply-chain attacks.
      - zahlman 4mo ago
        The current standard library urllib is a refactoring of previous attempts from the 2.x standard library, and urllib.request is just a sub-package. It does not represent adoption of requests; requests builds on urllib3, which was created to fill in gaps in what the standard library provided, and named like that because the 2.x standard library had both a `urllib` and a `urllib2` as they struggled to figure it out.
        necovek 4mo ago
        For a long time, urllib had everything deprecated except for the parsing code which remained relevant as the upstream RFCs have not changed IIRC. Urllib2 is now also gone and mostly replaced with urllib.request. It should cover 99% of the use-cases one would use requests for — I am not sure how and why it matters that it is a subpackage and not a top-level package? This is just a natural evolution of a widely used language where you have to be careful with backwards compatibility.
    - BoingBoomTschak 4mo ago
      Because the typical Python programmer does not appreciate the advantages of a slightly rusty stdlib compared to reaching for the bedlam that is PyPI.
  - zahlman 4mo ago
    > “batteries included” standard library and what’s becoming nearly standard third party libs Historically, the standard library made sense. And we're talking about a history that stretches back to before Internet connections were ubiquitous, to say nothing of connection speed. Now the standard library is full of things that they refuse to remove because it would supposedly be too disruptive, but which they would never think of adding today if they weren't already there.
- hankbond 4mo ago
  It's easy to start learning on, or prototype with, and then sometimes momentum just keeps it going. Also it may not really be the best at anything, but it's "pretty good" at just about everything. It's kind of like vanilla ice cream. Packaging can be irritating although uv takes the sting out a bit. You are right that outside of verbosity, once you get used to the syntax of a language, the value of one over the other kind of fades.
  - Kwpolska 4mo ago
    > Packaging can be irritating although uv takes the sting out a bit. uv proves the OP’s point. Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv, and why is the Python package manager uv written in Rust and not Python?
    - necovek 4mo ago
      For the same reason GP posted and half the stdlib is written in C: Python is a language that is almost always good enough, but never really the best (and especially when it comes to performance of complex algorithms).
    - CamouflagedKiwi 4mo ago
      Because uv itself can fetch a Python distribution. If it's written in Python, it's quite a bit harder to distribute, assuming one of their goals is not to require an existing Python install.
    - zahlman 4mo ago
      > Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv Incredibly large backward-compatibility burdens [0], internal politics [1] and general institutional dysfunction (no footnote; if you're familiar then you need no explanation, and if you aren't then the less said the better). Nothing to do with Python as a language. Most of the important pieces to get uv-like performance are algorithmic choices, and most of the rest are available as built-in C code in the reference implementation [2]. (Edit: wait, I recognize your username. You should definitely know these sorts of things.) > why is the Python package manager uv written in Rust and not Python? Because that's the language that Astral devs like, and because installing Python itself is considered in scope for uv so there would be an intractable bootstrapping issue. [0]: In particular, the entire model of `setup.py` defining metadata is certifiably insane, especially when you consider the projects that expect to feed that code to Setuptools at build time in order to figure out what version of Setuptools is needed at build time. But this legacy approach is seen as something that absolutely must be guaranteed to work for well beyond even now; even attempts to remove long-deprecated, minor aspects of that functionality end up breaking major projects, including ones that didn't even require a build step in the first place [3]. [1]: Most obviously, GvR not wanting to have anything to do with it when initially approached by the SciPy people in IIRC 2011, leading to the creation of Conda). But a lot of other things, too. The backwards-compatibility issues synergize with this; consider for example the architectural dumpster fire of Setuptools, and the timeline of distutils removal from the standard library. [2]: See e.g. my analysis in https://zahlman.github.io/posts/oxidation/ https://zahlman.github.io/posts/oxidation/ . [3]: See e.g. my LWN article https://lwn.net/Articles/1020576/ https://lwn.net/Articles/1020576/ .
- petre 4mo ago
  > It's this sort of stuff that leaves me scratching my head why people like Python so much Because of the libraries, not necessarily the language, which is also quite straightforward. For example we found a niche library that speaks the ISO-TP protocol in Python, which allows us to communicate with vehicle ECUs. That's why people also use C++, even tough I quite doubt it's because they like the language. Add to that that it's also heavily used in embedded programming. Yes, you could call a C/C++ library from another language, depending how well the language can do that. I prefer Ruby, but Python probably has just about everything one would need. It's also great for data processing. We hardly have anything better than pandas, polars, numpy, scipy in other languages and that:s without even mentioning ML tooling.
- deleted 4mo ago
  [deleted]
- pjmlp 4mo ago
  C++ has vcpkg, conan, cmake and ninja nowadays. They are as standard as arguing about Ant, Maven, Gradle in Java, npm, pnpm, yarn in node, and so on. However I fully agree with the gist of your comment, basically Python is the new BASIC. However at least BASIC was compiled, with exception of the 8 bit home micros.
- zahlman 4mo ago
  > Racket, CLisp Syntax really does matter more than you give it credit for. Were that not the case, I'd expect one Lisp or Scheme dialect or other to take Python's place. Outside of that counterfactual, Python's competition was stuff like Ruby, and it turned out that network effects were also pretty important.
  - throwaway81523 4mo ago
    Python's main competition was Perl. Ruby was later, I think.
- graemep 4mo ago
  You are right the syntax is a small part of it, but it is more important than you say in this case because Python syntax is one of the things that makes it very readable. Even if you dislike the direction Python is going in, a lot of what attracted people to Python in the first place is still there. The readability, the large standard library, the huge ecosystem. There are libraries and frameworks for everything: numerical stuff, web development, GUIs etc. Its actually a nice language in itself, just going in the wrong direction now. If you look at it historically it was really good comparatively. If you compare it to the alternatives available 20 years ago it looks pretty good.
- Lutger 4mo ago
  When people say they prefer 'the syntax', I think they usually mean a bit more than just that: at least a fair bit of this is semantics. Python provides a lot of features out of the box, and if you work superficially along the happy path, it is very easy to understand how these work and read code using them. Take list comprehensions for example. It is mostly syntax: you can do virtually all list comprehensions with just a map and filter function. But the way that it is integrated and presents the code, makes is vastly easier to follow for most developers, which tilts the balancer in favor of doing away with loops and mutable state. Is it syntax that made them do so? Yes, maybe. But its the actual semantics that provide the value.
ameliaquining 4mo ago
It's better in some ways (order-of-magnitude reductions in pause times were cited) but worse in other ways (higher peak memory usage). That the higher peak memory usage was catastrophic for some users only became apparent through post-release feedback.
- petre 4mo ago
  They should have shipped it as an addon GC, not enabled by default. One could have turned it on with a command line switch or an env var, just like the Ruby JIT.
hmry 4mo ago
Really? You've never reverted a positive change because it contained a regression only discovered after release?

moron4hire 4mo ago

It's this sort of stuff that leaves me scratching my head why people like Python so much. I hear them say they prefer the syntax and personally I feel like that's such a small part of the holistic experience of working with any particular language. It's one of the reasons why I gave up on C++ years ago for .NET, the whole system of tooling in .NET has never left me feeling like I was pigeonholed into doing things in stupid, self-flagelating ways. Why should I use a language like C++ that doesn't provide a standard set of package management and build tools? Why should I use a language like Python that feels like it's being designed by amateurs? I felt like the tooling in Racket, CLisp, and Java were similarly pragmatic and not either religiously devoted to some concept of "backwards compatibility" that I seriously doubt most people actually need, or "ease of use" that actually proves itself to be easy when you consider the not-happy-path of the beginner tutorials. Racket, I didn't continue just because the library ecosystem isn't mature enough to keep up with the latest in databases and other 3rd party services. Java I quit largely because of Oracle and some 2010s problems with stagnation. CLisp mostly because it was too hard to socialize. But never because I thought the core language and tooling were holding me back.

SJC_Hacker 4mo ago
Python is mostly about the “batteries included” standard library and what’s becoming nearly standard third party libs, being able to play around in the REPL,
- Kwpolska 4mo ago
  The standard library is full of dead batteries. If the stdlib is so good, why does everyone install requests instead of using the stdlib http client? And why requests or something like it hasn't been adopted into stdlib after so many years of stability?
  - necovek 4mo ago
    Parts of requests has been adopted into stdlib: https://docs.python.org/3/library/urllib.request.html https://docs.python.org/3/library/urllib.request.html People mostly defer to requests because they do not track language development closely and because we are creatures of habit. I try to avoid non-stdlib packages when stdlib will do a good job, but I received negative feedback from people who aren't aware of the updates and couldn't foresee supply-chain attacks.
    - zahlman 4mo ago
      The current standard library urllib is a refactoring of previous attempts from the 2.x standard library, and urllib.request is just a sub-package. It does not represent adoption of requests; requests builds on urllib3, which was created to fill in gaps in what the standard library provided, and named like that because the 2.x standard library had both a `urllib` and a `urllib2` as they struggled to figure it out.
      - necovek 4mo ago
        For a long time, urllib had everything deprecated except for the parsing code which remained relevant as the upstream RFCs have not changed IIRC. Urllib2 is now also gone and mostly replaced with urllib.request. It should cover 99% of the use-cases one would use requests for — I am not sure how and why it matters that it is a subpackage and not a top-level package? This is just a natural evolution of a widely used language where you have to be careful with backwards compatibility.
  - BoingBoomTschak 4mo ago
    Because the typical Python programmer does not appreciate the advantages of a slightly rusty stdlib compared to reaching for the bedlam that is PyPI.
- zahlman 4mo ago
  > “batteries included” standard library and what’s becoming nearly standard third party libs Historically, the standard library made sense. And we're talking about a history that stretches back to before Internet connections were ubiquitous, to say nothing of connection speed. Now the standard library is full of things that they refuse to remove because it would supposedly be too disruptive, but which they would never think of adding today if they weren't already there.
hankbond 4mo ago
It's easy to start learning on, or prototype with, and then sometimes momentum just keeps it going. Also it may not really be the best at anything, but it's "pretty good" at just about everything. It's kind of like vanilla ice cream. Packaging can be irritating although uv takes the sting out a bit. You are right that outside of verbosity, once you get used to the syntax of a language, the value of one over the other kind of fades.
- Kwpolska 4mo ago
  > Packaging can be irritating although uv takes the sting out a bit. uv proves the OP’s point. Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv, and why is the Python package manager uv written in Rust and not Python?
  - necovek 4mo ago
    For the same reason GP posted and half the stdlib is written in C: Python is a language that is almost always good enough, but never really the best (and especially when it comes to performance of complex algorithms).
  - CamouflagedKiwi 4mo ago
    Because uv itself can fetch a Python distribution. If it's written in Python, it's quite a bit harder to distribute, assuming one of their goals is not to require an existing Python install.
  - zahlman 4mo ago
    > Why couldn’t the core team and the core-adjacent PyPA make a tool as liked as uv Incredibly large backward-compatibility burdens [0], internal politics [1] and general institutional dysfunction (no footnote; if you're familiar then you need no explanation, and if you aren't then the less said the better). Nothing to do with Python as a language. Most of the important pieces to get uv-like performance are algorithmic choices, and most of the rest are available as built-in C code in the reference implementation [2]. (Edit: wait, I recognize your username. You should definitely know these sorts of things.) > why is the Python package manager uv written in Rust and not Python? Because that's the language that Astral devs like, and because installing Python itself is considered in scope for uv so there would be an intractable bootstrapping issue. [0]: In particular, the entire model of `setup.py` defining metadata is certifiably insane, especially when you consider the projects that expect to feed that code to Setuptools at build time in order to figure out what version of Setuptools is needed at build time. But this legacy approach is seen as something that absolutely must be guaranteed to work for well beyond even now; even attempts to remove long-deprecated, minor aspects of that functionality end up breaking major projects, including ones that didn't even require a build step in the first place [3]. [1]: Most obviously, GvR not wanting to have anything to do with it when initially approached by the SciPy people in IIRC 2011, leading to the creation of Conda). But a lot of other things, too. The backwards-compatibility issues synergize with this; consider for example the architectural dumpster fire of Setuptools, and the timeline of distutils removal from the standard library. [2]: See e.g. my analysis in https://zahlman.github.io/posts/oxidation/ https://zahlman.github.io/posts/oxidation/ . [3]: See e.g. my LWN article https://lwn.net/Articles/1020576/ https://lwn.net/Articles/1020576/ .
petre 4mo ago
> It's this sort of stuff that leaves me scratching my head why people like Python so much Because of the libraries, not necessarily the language, which is also quite straightforward. For example we found a niche library that speaks the ISO-TP protocol in Python, which allows us to communicate with vehicle ECUs. That's why people also use C++, even tough I quite doubt it's because they like the language. Add to that that it's also heavily used in embedded programming. Yes, you could call a C/C++ library from another language, depending how well the language can do that. I prefer Ruby, but Python probably has just about everything one would need. It's also great for data processing. We hardly have anything better than pandas, polars, numpy, scipy in other languages and that:s without even mentioning ML tooling.
deleted 4mo ago
[deleted]
pjmlp 4mo ago
C++ has vcpkg, conan, cmake and ninja nowadays. They are as standard as arguing about Ant, Maven, Gradle in Java, npm, pnpm, yarn in node, and so on. However I fully agree with the gist of your comment, basically Python is the new BASIC. However at least BASIC was compiled, with exception of the 8 bit home micros.
zahlman 4mo ago
> Racket, CLisp Syntax really does matter more than you give it credit for. Were that not the case, I'd expect one Lisp or Scheme dialect or other to take Python's place. Outside of that counterfactual, Python's competition was stuff like Ruby, and it turned out that network effects were also pretty important.
- throwaway81523 4mo ago
  Python's main competition was Perl. Ruby was later, I think.
graemep 4mo ago
You are right the syntax is a small part of it, but it is more important than you say in this case because Python syntax is one of the things that makes it very readable. Even if you dislike the direction Python is going in, a lot of what attracted people to Python in the first place is still there. The readability, the large standard library, the huge ecosystem. There are libraries and frameworks for everything: numerical stuff, web development, GUIs etc. Its actually a nice language in itself, just going in the wrong direction now. If you look at it historically it was really good comparatively. If you compare it to the alternatives available 20 years ago it looks pretty good.
Lutger 4mo ago
When people say they prefer 'the syntax', I think they usually mean a bit more than just that: at least a fair bit of this is semantics. Python provides a lot of features out of the box, and if you work superficially along the happy path, it is very easy to understand how these work and read code using them. Take list comprehensions for example. It is mostly syntax: you can do virtually all list comprehensions with just a map and filter function. But the way that it is integrated and presents the code, makes is vastly easier to follow for most developers, which tilts the balancer in favor of doing away with loops and mutable state. Is it syntax that made them do so? Yes, maybe. But its the actual semantics that provide the value.

ameliaquining 4mo ago

It's better in some ways (order-of-magnitude reductions in pause times were cited) but worse in other ways (higher peak memory usage). That the higher peak memory usage was catastrophic for some users only became apparent through post-release feedback.

petre 4mo ago
They should have shipped it as an addon GC, not enabled by default. One could have turned it on with a command line switch or an env var, just like the Ruby JIT.

hmry 4mo ago

Really? You've never reverted a positive change because it contained a regression only discovered after release?