4 ms·

> But a simple solution to address your fears: simply don't use threads. You'll be fine. Im not worried about new code. Im worried about stuff written 15 years

> But a simple solution to address your fears: simply don't use threads. You'll be fine. Im not worried about new code. Im worried about stuff written 15 years ago by a monkey who had no idea how threads work and just read something on stack overflow that said to use threading. This code will likely break when run post-GIL. I suspect there is actually quite a bit of it.

bgwalter 1y ago
If it is C-API code: Implicit protection of global variables by the GIL is a documented feature, which makes writing extensions much easier. Most C extensions that will break are not written by monkeys, but by conscientious developers that followed best practices.
bayindirh 1y ago
Software rots, software tools evolve. When Intel released performance primitives libraries which required recompilation to analyze multi-threaded libraries, we were amazed. Now, these tools are built into processors as performance counters and we have way more advanced tools to analyze how systems behave. Older code will break, but they break all the time. A language changes how something behaves in a new revision, suddenly 20 year old bedrock tools are getting massively patched to accommodate both new and old behavior. Is it painful, ugly, unpleasant? Yes, yes and yes. However change is inevitable, because some of the behavior was rooted in inability to do some things with current technology, and as hurdles are cleared, we change how things work. My father's friend told me that length of a variable's name used to affect compile/link times. Now we can test whether we have memory leaks in Rust. That thing was impossible 15 years ago due to performance of the processors.
- delusional 1y ago
  > Software rots No it does not. I hate that analogy so much because it leads to such bad behavior. Software is a digital artifact that can does not degrade. With the right attitude, you'd be able to execute the same binary on new machines for as long as you desired. That is not true of organic matter that actually rots. The only reason we need to change software is that we trade that off against something else. Instructions are reworked, because chasing the universal Turing machine takes a few sacrifices. If all software has to run on the same hardware, those two artifacts have to have a dialogue about what they need from each other. If we didnt want the universal machine to do anything new. If we had a valuable product. We could just keep making the machine that executes that product. It never rots.
  - kstrauser 1y ago
    That’s not what the phrase implies. If you have a C program from 1982, you can still compile it on a 1982 operating system and toolchain and it’ll work just as before. But if you tried to compile it on today’s libc, making today’s syscalls… good luck with that. Software “rots” in the sense that it has to be updated to run on today’s systems. They’re a moving target. You can still run HyperCard on an emulator, but good luck running it unmodded on a Mac you buy today.
    - zahlman 1y ago
      > You can still run HyperCard on an emulator, but good luck running it unmodded on a Mac you buy today. I grew up with HyperCard, so I had a moment of sadness here.
      - kstrauser 1y ago
        We all have our own personal HyperCard.
  - eblume 1y ago
    Software is written with a context, and the context degrades. It must be renewed. It rots, sorry.
    - igouy 1y ago
      You said it's the context that rots.
      - bayindirh 1y ago
        It's a matter of perspective, I guess... When you look from the program's perspective, the context changes and becomes unrecognizable, IOW, it rots. When you look from the context's perspective, the program changes by not evolving and keeping up with the context, IOW, it rots. Maybe we anthropomorphize both and say "they grow apart". :)
- cestith 1y ago
  My only concern is this kind of change in semantics for existing syntax is more worthy of a major revision than a point release.
  - rbanffy 1y ago
    It's opt-in at the moment. It won't be the default behavior for a couple releases. Maybe we'll get Python 4 with no GIL. /me ducks
  - necovek 1y ago
    Python already has a history of "misrepresenting" the ycope of the change (like changing behaviour of one of core data types and calling it just a major version change — that's really a new language IMHO). Still, that's only a marketing move, technically the choice was still the right one, just like this one is.
  - markkitti 1y ago
    Agreed. This should have been Python 4.
- spookie 1y ago
  The other day I compiled a 1989 C program and it did the job. I wish more things were like that. Tired of building things on shaky grounds.
  - rbanffy 1y ago
    If you go into mainframes, you'll compile code that was written 50 years ago without issue. In fact, you'll run code that was compiled 50 years ago and all that'll happen is that it'll finish much sooner than it did on the old 360 it originally ran on.
  - Too 1y ago
    Hello world without -O2 -Werror? I've done several compiler toolchain updates on larger code bases and every new version of Clang, GCC or glibc will trip up new compiler warnings. Worse, occasionally taking advantage of some UB laying around leading to runtime bugs. I'm not complaining, the new stricter warnings are usually for the better, what I'm saying is that the bedrock of that world isn't as stable as it's sometimes portraited.
- zahlman 1y ago
  > A language changes how something behaves in a new revision, suddenly 20 year old bedrock tools are getting massively patched to accommodate both new and old behavior. In my estimation, the only "20 year old bedrock tools" in Python are in the standard library - which currently holds itself free to deprecate entire modules in any minor version, and remove them two minor versions later - note that this is a pseudo-calver created by a coincidentally annual release cadence. (A bunch of stuff that old was taken out recently, but it can't really be considered "bedrock" - see https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/). Unless you include NumPy's predecessors when dating it (https://en.wikipedia.org/wiki/NumPy#History https://en.wikipedia.org/wiki/NumPy#History). And the latest versions of NumPy don't even support Python 3.9 which is still not EOL. Requests turns 15 next February (https://pypi.org/project/requests/#history https://pypi.org/project/requests/#history). Pip isn't 20 years old yet (https://pypi.org/project/pip/#history https://pypi.org/project/pip/#history) even counting the version 0.1 "pyinstall" prototype (not shown). Setuptools (which generally supports only the Python versions supported by CPython, hasn't supported Python 2.x since version 45 and is currently on version 80) only appears to go back to 2006, although I can't find release dates for versions before what's on PyPI (their own changelog goes back to 0.3a1, but without dates).
actinium226 1y ago
If code has been unmaintained for more than a few years, it's usually such a hassle to get it working again that 99% of the time I'll just write my own solution, and that's without threads. I feel some trepidation about threads, but at least for debugging purposes there's only one process to attach to.
dhruvrajvanshi 1y ago
> Im not worried about new code. Im worried about stuff written 15 years ago by a monkey who had no idea how threads work and just read something on stack overflow that said to use threading. This code will likely break when run post-GIL. I suspect there is actually quite a bit of it. I was with OP's point but then you lost me. You'll always have to deal with that coworker's shitty code, GIL or not. Could they make a worse mess with multi threading? Sure. Is their single threaded code as bad anyway because at the end of the day, you can't even begin understand it? Absolutely. But yeah I think python people don't know what they're asking for. They think GIL less python is gonna give everyone free puppies.
zahlman 1y ago
>Im worried about stuff written 15 years ago Please don't - it isn't relevant. 15 years ago, new Python code was still dominantly for 2.x. Even code written back then with an eye towards 3.x compatibility (or, more realistically, lazily run through `2to3` or `six`) will have quite little chance of running acceptably on 3.14 regardless. There have been considerable removals from the standard library, `async` is no longer a valid identifier name (you laugh, but that broke Tensorflow once). The attitude taken towards """strings""" in a lot of 2.x code results in constructs that can be automatically made into valid syntax that appears to preserve the original intent, but which are not at all automatically fixed. Also, the modern expectation is of a lock-step release cadence. CPython only supports up to the last 5 versions, released annually; and whenever anyone publishes a new version of a package, generally they'll see no point in supporting unsupported Python versions. Nor is anyone who released a package in the 3.8 era going to patch it if it breaks in 3.14 - because support for 3.14 was never advertised anyway. In fact, in most cases, support for 3.9 wasn't originally advertised, and you can't update the metadata for an existing package upload (you have to make a new one, even if it's just a "post-release") even if you test it and it does work. Practically speaking, pure-Python packages usually do work in the next version, and in the next several versions, perhaps beyond the support window. But you can really never predict what's going to break. You can only offer a new version when you find out that it's going to break - and a lot of developers are going to just roll that fix into the feature development they were doing anyway, because life's too short to backport everything for everyone. (If there's no longer active development and only maintenance, well, good luck to everyone involved.) If 5 years isn't long enough for your purposes, practically speaking you need to maintain an environment with an outdated interpreter, and find a third party (RedHat seems to be a popular choice here) to maintain it.

bgwalter 1y ago

If it is C-API code: Implicit protection of global variables by the GIL is a documented feature, which makes writing extensions much easier. Most C extensions that will break are not written by monkeys, but by conscientious developers that followed best practices.

bayindirh 1y ago

Software rots, software tools evolve. When Intel released performance primitives libraries which required recompilation to analyze multi-threaded libraries, we were amazed. Now, these tools are built into processors as performance counters and we have way more advanced tools to analyze how systems behave. Older code will break, but they break all the time. A language changes how something behaves in a new revision, suddenly 20 year old bedrock tools are getting massively patched to accommodate both new and old behavior. Is it painful, ugly, unpleasant? Yes, yes and yes. However change is inevitable, because some of the behavior was rooted in inability to do some things with current technology, and as hurdles are cleared, we change how things work. My father's friend told me that length of a variable's name used to affect compile/link times. Now we can test whether we have memory leaks in Rust. That thing was impossible 15 years ago due to performance of the processors.

delusional 1y ago
> Software rots No it does not. I hate that analogy so much because it leads to such bad behavior. Software is a digital artifact that can does not degrade. With the right attitude, you'd be able to execute the same binary on new machines for as long as you desired. That is not true of organic matter that actually rots. The only reason we need to change software is that we trade that off against something else. Instructions are reworked, because chasing the universal Turing machine takes a few sacrifices. If all software has to run on the same hardware, those two artifacts have to have a dialogue about what they need from each other. If we didnt want the universal machine to do anything new. If we had a valuable product. We could just keep making the machine that executes that product. It never rots.
- kstrauser 1y ago
  That’s not what the phrase implies. If you have a C program from 1982, you can still compile it on a 1982 operating system and toolchain and it’ll work just as before. But if you tried to compile it on today’s libc, making today’s syscalls… good luck with that. Software “rots” in the sense that it has to be updated to run on today’s systems. They’re a moving target. You can still run HyperCard on an emulator, but good luck running it unmodded on a Mac you buy today.
  - zahlman 1y ago
    > You can still run HyperCard on an emulator, but good luck running it unmodded on a Mac you buy today. I grew up with HyperCard, so I had a moment of sadness here.
    - kstrauser 1y ago
      We all have our own personal HyperCard.
- eblume 1y ago
  Software is written with a context, and the context degrades. It must be renewed. It rots, sorry.
  - igouy 1y ago
    You said it's the context that rots.
    - bayindirh 1y ago
      It's a matter of perspective, I guess... When you look from the program's perspective, the context changes and becomes unrecognizable, IOW, it rots. When you look from the context's perspective, the program changes by not evolving and keeping up with the context, IOW, it rots. Maybe we anthropomorphize both and say "they grow apart". :)
cestith 1y ago
My only concern is this kind of change in semantics for existing syntax is more worthy of a major revision than a point release.
- rbanffy 1y ago
  It's opt-in at the moment. It won't be the default behavior for a couple releases. Maybe we'll get Python 4 with no GIL. /me ducks
- necovek 1y ago
  Python already has a history of "misrepresenting" the ycope of the change (like changing behaviour of one of core data types and calling it just a major version change — that's really a new language IMHO). Still, that's only a marketing move, technically the choice was still the right one, just like this one is.
- markkitti 1y ago
  Agreed. This should have been Python 4.
spookie 1y ago
The other day I compiled a 1989 C program and it did the job. I wish more things were like that. Tired of building things on shaky grounds.
- rbanffy 1y ago
  If you go into mainframes, you'll compile code that was written 50 years ago without issue. In fact, you'll run code that was compiled 50 years ago and all that'll happen is that it'll finish much sooner than it did on the old 360 it originally ran on.
- Too 1y ago
  Hello world without -O2 -Werror? I've done several compiler toolchain updates on larger code bases and every new version of Clang, GCC or glibc will trip up new compiler warnings. Worse, occasionally taking advantage of some UB laying around leading to runtime bugs. I'm not complaining, the new stricter warnings are usually for the better, what I'm saying is that the bedrock of that world isn't as stable as it's sometimes portraited.
zahlman 1y ago
> A language changes how something behaves in a new revision, suddenly 20 year old bedrock tools are getting massively patched to accommodate both new and old behavior. In my estimation, the only "20 year old bedrock tools" in Python are in the standard library - which currently holds itself free to deprecate entire modules in any minor version, and remove them two minor versions later - note that this is a pseudo-calver created by a coincidentally annual release cadence. (A bunch of stuff that old was taken out recently, but it can't really be considered "bedrock" - see https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/). Unless you include NumPy's predecessors when dating it (https://en.wikipedia.org/wiki/NumPy#History https://en.wikipedia.org/wiki/NumPy#History). And the latest versions of NumPy don't even support Python 3.9 which is still not EOL. Requests turns 15 next February (https://pypi.org/project/requests/#history https://pypi.org/project/requests/#history). Pip isn't 20 years old yet (https://pypi.org/project/pip/#history https://pypi.org/project/pip/#history) even counting the version 0.1 "pyinstall" prototype (not shown). Setuptools (which generally supports only the Python versions supported by CPython, hasn't supported Python 2.x since version 45 and is currently on version 80) only appears to go back to 2006, although I can't find release dates for versions before what's on PyPI (their own changelog goes back to 0.3a1, but without dates).

actinium226 1y ago

If code has been unmaintained for more than a few years, it's usually such a hassle to get it working again that 99% of the time I'll just write my own solution, and that's without threads. I feel some trepidation about threads, but at least for debugging purposes there's only one process to attach to.

dhruvrajvanshi 1y ago

> Im not worried about new code. Im worried about stuff written 15 years ago by a monkey who had no idea how threads work and just read something on stack overflow that said to use threading. This code will likely break when run post-GIL. I suspect there is actually quite a bit of it. I was with OP's point but then you lost me. You'll always have to deal with that coworker's shitty code, GIL or not. Could they make a worse mess with multi threading? Sure. Is their single threaded code as bad anyway because at the end of the day, you can't even begin understand it? Absolutely. But yeah I think python people don't know what they're asking for. They think GIL less python is gonna give everyone free puppies.

zahlman 1y ago

>Im worried about stuff written 15 years ago Please don't - it isn't relevant. 15 years ago, new Python code was still dominantly for 2.x. Even code written back then with an eye towards 3.x compatibility (or, more realistically, lazily run through `2to3` or `six`) will have quite little chance of running acceptably on 3.14 regardless. There have been considerable removals from the standard library, `async` is no longer a valid identifier name (you laugh, but that broke Tensorflow once). The attitude taken towards """strings""" in a lot of 2.x code results in constructs that can be automatically made into valid syntax that appears to preserve the original intent, but which are not at all automatically fixed. Also, the modern expectation is of a lock-step release cadence. CPython only supports up to the last 5 versions, released annually; and whenever anyone publishes a new version of a package, generally they'll see no point in supporting unsupported Python versions. Nor is anyone who released a package in the 3.8 era going to patch it if it breaks in 3.14 - because support for 3.14 was never advertised anyway. In fact, in most cases, support for 3.9 wasn't originally advertised, and you can't update the metadata for an existing package upload (you have to make a new one, even if it's just a "post-release") even if you test it and it does work. Practically speaking, pure-Python packages usually do work in the next version, and in the next several versions, perhaps beyond the support window. But you can really never predict what's going to break. You can only offer a new version when you find out that it's going to break - and a lot of developers are going to just roll that fix into the feature development they were doing anyway, because life's too short to backport everything for everyone. (If there's no longer active development and only maintenance, well, good luck to everyone involved.) If 5 years isn't long enough for your purposes, practically speaking you need to maintain an environment with an outdated interpreter, and find a third party (RedHat seems to be a popular choice here) to maintain it.