4 ms·

There is a certain beauty with the GIL and without it there will be more unnecessary complexity for the 80% of applications in the future and potential maintena

• guappa 2y ago
  He's ok with all the breaking changes I think, from what I can see on the python forum.
  • IshKebab 2y ago
    Python 3.12 had a ton of breaking changes too so that doesn't surprise me. They clearly didn't learn from the Python 3 experience! Or maybe they did and their lesson was "still make breaking changes but just don't change the major version number".
    • guappa 2y ago
      Yes I think that was their takeaway, so now instead of having a slooooow migration we just have tens of libraries that break at every python update. Also there's no way to get access to pypi and fix the abandoned libraries. So they get patched in distributions and remain broken forever on pypi.
      • smcin 2y ago
        Which libraries are you claiming break at every Python update? (3.12 or later)
        • ChrisRackauckas 2y ago
          The last updates deleted modules from the standard library like distutils. Any library that used those modules is now broken.
          • smcin 2y ago
            But that's not "break at every Python update", I asked you to substantiate your claim "breaks at every Python update". distutils was deprecated and being phased out since 2014 [https://peps.python.org/pep-0632/ https://peps.python.org/pep-0632/]. It was removed in 3.12. People were preparing for this in 2021 already [https://news.ycombinator.com/item?id=26159509 https://news.ycombinator.com/item?id=26159509]. Python almost never does breaking changes in non-major versions, and only when necessary. And even at that, "Python" didn't break, only those (abandoned) packages that depend on distutils, and they already got/are getting fixed/removed. Honestly this isn't "breaks at every Python update". All those of us who aren't using those distributions don't even see the abandoned libraries in the first place. (I asked you guys for a list of the libraries.)
        • IshKebab 2y ago
          It's not every Python update. 3.12 was particularly bad. Blessed is an example. I believe they had fixed it in the latest version, but we weren't using the latest version. Another example of breaking changes in the Python ecosystem: when Numpy updated to 2.0 (with breaking changes) we had a package that depended on `numpy >= 1.something` but it didn't actually work with Python 2.0. You can say "well they should have known to use the very unobvious non-default syntax 'numpy >= 1.0, < 2'" but even that isn't right because it turns out Python packages don't use semver; they just deprecate things and then remove them at arbitrary versions, so there's no reasonable upper bound you can actually put there.
• make3 2y ago
  why is it crazy? Java, c-sharp, and more all have normal threading enabled, why couldn't Python? clearly it's going to be massively useful.
  • zarzavat 2y ago
    Because there’s decades worth of libraries that written under the assumption that Python has a GIL. All of these need to be updated, it’s Python 3 all over again.
    • aardvark179 2y ago
      There are many C extensions written with that assumption, but if you were relying on the GIL to avoid Python level concurrency bugs you probably didn’t, they’ll just be slightly rarer and harder to reproduce. That was certainly my experience working on TruffleRuby, and I doubt Python is very different. We found a few bugs because we didn’t have a global lock, but they were often problems that showed up in a soak test on an implementation with a GIL, just not quite as often so they had escaped notice and were likely causing real failures in production somewhere.
    • Joeboy 2y ago
      AIUI if you want the GIL, you can just not disable it. I don't think the GIL is going away in the near future.
  • guappa 2y ago
    It would be if it wouldn't be massively slower too.
• jillesvangurp 2y ago
  It's a thirty year old design decision that even at the time was fairly naive but somewhat excusable given the scarcity of multi processor systems at the time. Undoing this and tackling all the technical debt is overdue. The main challenge never was that it's not doable (see other languages for a variety of solutions) but simply that it's a bit of work. Basically it won't become a default until after it works. Which is the opposite of crazy; it's very reasonable. Guido has spoken out on this and I don't think he's against this. It's more that he's in favor of stability and moving forward. The challenge with python is that you can't do a lot of things in it very efficiently that people keep on doing in it anyway. Like trying to use multiple threads. Making those things work a bit better is not a bad thing. There's a simple solution for code that depends on the GIL, which is simply to don't do what's fairly pointless with the GIL anyway: using more than 1 thread. The GIL only serves a purpose if you use more than 1 thread. And since it makes doing that kind of impractical anyway, most python code doesn't need the GIL because it is single threaded. That code will only break if the GIL is gone and multiple threads are used. Simple solution if that affects you: don't do that.
  • skeledrew 2y ago
    Tell that to the dependency of the dependency you can find no decent alternative for that does find threads useful.