4 ms·

As somebody who welcomes killing off the GIL. I would agree that Python is changing too much. It seems to be in this constant state of flux starting from around

As somebody who welcomes killing off the GIL. I would agree that Python is changing too much. It seems to be in this constant state of flux starting from around the Python 2 to 3 era (though maybe it was always like this and I wasn't familiar enough with it to know how it was before that). While all languages change, Pythons changes seem to be existential in nature. For such a long lived language to have this much immaturity is worrying. I guess the side affect of such popularity later in life.

mnky9800n 2y ago
I think partly to blame is the people who refused to move to 3.x. I remember in 2016-17 I worked on a new project and people say and argued that we simply had to use 2.x and that it would never go away. There wasn't even 2.x dependencies for the project. And I feel like that kind of mentality really slowed down migration and ultimately helped to create a culture that python would always be changing.
- rich_sasha 2y ago
  It's an interesting point, both the argument it makes and the background. I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerous and totally unnecessary minor syntax changes (print -> function, map and filter becoming lazy, str/unicode etc) with no major benefits in the upgrade for my use case (data science), other than compatibility. Some of the new syntax was neither bad or good (what's so wrong with print being a statement? Add a printfn function if you really want one), some were IMHO outright bad (map and filter becoming lazy, reduce being kicked out to a module), str->unicode was maybe the only good one, but even that is controversial. The deliberate neutering of `bytes` was unnecessary too. Python 3 brought various implementation improvements and nice new syntax, which could have been implemented in a Python 2 syntax too (dict and set comprehensions for example) So I saw no reason why Python 3 couldn't in fact be syntactically compatible with 2, and saw the whole thing as a bit of an upgrade circus: wanna keep using the language? Make these arbitrary changes because someone thought print ought to be a function. You could argue it was the same disregard for stability as the now many versions of Python 3.
  - robertlagrant 2y ago
    Why print as a function? From the PEP[0]: print is the only application-level functionality that has a statement dedicated to it. Within Python’s world, syntax is generally used as a last resort, when something can’t be done without help from the compiler. Print doesn’t qualify for such an exception. At some point in application development one quite often feels the need to replace print output by something more sophisticated, like logging calls or calls into some other I/O library. With a print() function, this is a straightforward string replacement, today it is a mess adding all those parentheses and possibly converting >>stream style syntax. Having special syntax for print puts up a much larger barrier for evolution, e.g. a hypothetical new printf() function is not too far fetched when it will coexist with a print() function. There’s no easy way to convert print statements into another call if one needs a different separator, not spaces, or none at all. Also, there’s no easy way at all to conveniently print objects with some other separator than a space. If print() is a function, it would be much easier to replace it within one module (just def print(*args):...) or even throughout a program (e.g. by putting a different function in __builtin__.print). As it is, one can do this by writing a class with a write() method and assigning that to sys.stdout – that’s not bad, but definitely a much larger conceptual leap, and it works at a different level than print. [0] https://peps.python.org/pep-3105 https://peps.python.org/pep-3105
    - rich_sasha 2y ago
      Yes, if Python was made from scratch, then perhaps function is better (I don't really mind). But breaking one of the most commonly used statements for what is essentially aesthetics? No thanks. Introduce a function that does the same if you like. That's precisely my point, this syntax change (and many others) was entirely unnecessary, put people off upgrading, then got them told off for being dinosauric luddites. Frankly, it's not even that consistent. Is `del dict[key]` necessary when you can call `dict.pop`? Either way, these would be fine discussions to have, but not when you consider the people upgrading thei codebases.
      - robertlagrant 2y ago
        > Is `del dict[key]` necessary when you can call `dict.pop`? Reason for Python 4 detected!
- mort96 2y ago
  I mean I do think Python 3 introduced some pretty bone-headed things. Their strings are horrible if you need to interact with the system. Most system APIs on UNIX-like systems don't promise that anything is UTF-8-encoded, so you can't e.g use strings to store paths. You need to use byte strings, and they have WAY worse ergonomics in many ways than strings. I would never use Python 2 now, but I do understand why some people would choose 2 back when 3 was new (and even slower than 2!).
  - isjsndn 2y ago
    But isn't exactly that the reason for the string/byte split? Rust has a similar thing with OsStr. In my opinion a clear type based separation between different kinds of strings (Text, data, os path, ...) is just required to write robust softwsre
  - robertlagrant 2y ago
    > so you can't e.g use strings to store paths. You need to use byte strings, and they have WAY worse ergonomics in many ways than strings Would you not use Pathlib?
- KaiserPro 2y ago
  I'm still not clear on what the real benifit of python3 over 2 was. I use python3 now by default, as it has fstrings, and probably some iteration things that I now rely on, and is faster for a lot of things. But for the longest time the only difference that I bumped into was that print isnt a keyword anymore, but assert still is.
  - robertlagrant 2y ago
    The main breaking change was Unicode for strings, which is what caused all the pain as lots of code was written to assume ASCII strings. But it's good that it's Unicode.
    - KaiserPro 2y ago
      Ahhh yes, that brings back memories. This also meant that stuff coming from things like UARTs and sockets were binary, rather than strings in python3.
    - Izkata 2y ago
      For anyone who doesn't remember: A python3 design decision they went partially back on meant it was easier to go from 2.7 to 3.3 than it was to go from 2.7 to 3.0 (I think it was 3.3 when they compromised, maybe 3.4?)
      - robertlagrant 2y ago
        3.3 - they reallowed unicode literals.

mnky9800n 2y ago

I think partly to blame is the people who refused to move to 3.x. I remember in 2016-17 I worked on a new project and people say and argued that we simply had to use 2.x and that it would never go away. There wasn't even 2.x dependencies for the project. And I feel like that kind of mentality really slowed down migration and ultimately helped to create a culture that python would always be changing.

rich_sasha 2y ago
It's an interesting point, both the argument it makes and the background. I'm one of the people who was unkeen to move to Py3. My reason was mostly the numerous and totally unnecessary minor syntax changes (print -> function, map and filter becoming lazy, str/unicode etc) with no major benefits in the upgrade for my use case (data science), other than compatibility. Some of the new syntax was neither bad or good (what's so wrong with print being a statement? Add a printfn function if you really want one), some were IMHO outright bad (map and filter becoming lazy, reduce being kicked out to a module), str->unicode was maybe the only good one, but even that is controversial. The deliberate neutering of `bytes` was unnecessary too. Python 3 brought various implementation improvements and nice new syntax, which could have been implemented in a Python 2 syntax too (dict and set comprehensions for example) So I saw no reason why Python 3 couldn't in fact be syntactically compatible with 2, and saw the whole thing as a bit of an upgrade circus: wanna keep using the language? Make these arbitrary changes because someone thought print ought to be a function. You could argue it was the same disregard for stability as the now many versions of Python 3.
- robertlagrant 2y ago
  Why print as a function? From the PEP[0]: print is the only application-level functionality that has a statement dedicated to it. Within Python’s world, syntax is generally used as a last resort, when something can’t be done without help from the compiler. Print doesn’t qualify for such an exception. At some point in application development one quite often feels the need to replace print output by something more sophisticated, like logging calls or calls into some other I/O library. With a print() function, this is a straightforward string replacement, today it is a mess adding all those parentheses and possibly converting >>stream style syntax. Having special syntax for print puts up a much larger barrier for evolution, e.g. a hypothetical new printf() function is not too far fetched when it will coexist with a print() function. There’s no easy way to convert print statements into another call if one needs a different separator, not spaces, or none at all. Also, there’s no easy way at all to conveniently print objects with some other separator than a space. If print() is a function, it would be much easier to replace it within one module (just def print(*args):...) or even throughout a program (e.g. by putting a different function in __builtin__.print). As it is, one can do this by writing a class with a write() method and assigning that to sys.stdout – that’s not bad, but definitely a much larger conceptual leap, and it works at a different level than print. [0] https://peps.python.org/pep-3105 https://peps.python.org/pep-3105
  - rich_sasha 2y ago
    Yes, if Python was made from scratch, then perhaps function is better (I don't really mind). But breaking one of the most commonly used statements for what is essentially aesthetics? No thanks. Introduce a function that does the same if you like. That's precisely my point, this syntax change (and many others) was entirely unnecessary, put people off upgrading, then got them told off for being dinosauric luddites. Frankly, it's not even that consistent. Is `del dict[key]` necessary when you can call `dict.pop`? Either way, these would be fine discussions to have, but not when you consider the people upgrading thei codebases.
    - robertlagrant 2y ago
      > Is `del dict[key]` necessary when you can call `dict.pop`? Reason for Python 4 detected!
mort96 2y ago
I mean I do think Python 3 introduced some pretty bone-headed things. Their strings are horrible if you need to interact with the system. Most system APIs on UNIX-like systems don't promise that anything is UTF-8-encoded, so you can't e.g use strings to store paths. You need to use byte strings, and they have WAY worse ergonomics in many ways than strings. I would never use Python 2 now, but I do understand why some people would choose 2 back when 3 was new (and even slower than 2!).
- isjsndn 2y ago
  But isn't exactly that the reason for the string/byte split? Rust has a similar thing with OsStr. In my opinion a clear type based separation between different kinds of strings (Text, data, os path, ...) is just required to write robust softwsre
- robertlagrant 2y ago
  > so you can't e.g use strings to store paths. You need to use byte strings, and they have WAY worse ergonomics in many ways than strings Would you not use Pathlib?
KaiserPro 2y ago
I'm still not clear on what the real benifit of python3 over 2 was. I use python3 now by default, as it has fstrings, and probably some iteration things that I now rely on, and is faster for a lot of things. But for the longest time the only difference that I bumped into was that print isnt a keyword anymore, but assert still is.
- robertlagrant 2y ago
  The main breaking change was Unicode for strings, which is what caused all the pain as lots of code was written to assume ASCII strings. But it's good that it's Unicode.
  - KaiserPro 2y ago
    Ahhh yes, that brings back memories. This also meant that stuff coming from things like UARTs and sockets were binary, rather than strings in python3.
  - Izkata 2y ago
    For anyone who doesn't remember: A python3 design decision they went partially back on meant it was easier to go from 2.7 to 3.3 than it was to go from 2.7 to 3.0 (I think it was 3.3 when they compromised, maybe 3.4?)
    - robertlagrant 2y ago
      3.3 - they reallowed unicode literals.