7 ms·

My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all

My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jettison packages they may want to keep using, or deal with the hassle of patching unmaintained dependencies on their own. For those Python users for whom writing python is the core of their work that might be fine. For all the other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...) the choice is untenable. While python can and should strive to be a more 'serious', 'professional' language, it _must_ have respect and empathy for the latter camp. Elevating something that should be a linter rule to a language change ain't that.

rurban 2y ago
major changes with breaking backward compatibility would require a major bump. Fine for python 4 I would say.
- kristjansson 2y ago
  Sure I guess? But we've just barely stopped talking about Python3, and that was released 13-16 years ago[1]. Is _this_ change worth another decade of thrashing the ecosystem? Is __any__ change? [1]: depending on if we count 3.0 vs 3.2 when it was actually kinda usable.
- nine_k 2y ago
  Why, it just should be opt-in: from __future__ import no_bare_except ...and enjoy.
  - afiori 2y ago
    Python should have the ability to set per-module flags for these kinds of incompatibilities. I guess that __future__ is doing something similar, but I am thinking of something like declaring how options should be set for your module and then only the code in that module is affected. (It would be nice being able to set constraints on what options your dependencies can enable) I guess that for std functionality this is impossible (like if the dict changed its key sorting it might be too hard to dispatch on the original file) but for syntax it should be perfectly possible.
- williamsmj 2y ago
  Again, python does not use semantic versioning. 3.12 and 3.13 are different major versions. The deprecation policy is documented and public. https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/.
  - unethical_ban 2y ago
    TIL. In the doc you linked, they reference "major" and "minor" versions. So they claim to have some concept of version numbers having different significance... Why don't they adhere to semantic versioning if they dress their version numbers like that? At least Linux just admits their X.Y scheme means nothing.
isoprophlex 2y ago
Exactly this. I totally agree. It's incredible to think that some people still run python 2 scripts; something unpalatable to the point of being nauseating for a day-to-day python programmer, but totally understandable in the context of incidental usage by a scientist dealing with legacy systems. If these things start happening to python 3 on a larger scale, might as well throw in the towel and go for python 4.
- mrbungie 2y ago
  I read "python 2" and a part of my soul cried in utf-8.
  - bdowling 2y ago
    Are you sure it didn't cry in `bytes()`?
  - nine_k 2y ago
    There are places that don't operate in anything but ASCII. Or even anything but 0123456789,\n\r.
  - bobim 2y ago
    Not sure 3 did anything to the number of circular permutations of encode and decode one need to fiddle with until that damn csv is pulled in correctly.
  - afiori 2y ago
    Programming languages are too obsessed with unicode in my opinion: String operations should have bytes and utf-{8,16} versions. The string value would have is_valid_utf_{8,16} flags and operations should unset them if they end up breaking the format (eg str[i] = 0xff would always mark the string as not unicode, str[i] = 0x00 would check if the flag was set and it so check whether the assignment broke a codepoint and unset the flag if so)
    - sigh_again 2y ago
      There are zero reasons to not go full UTF-8, everywhere, all the time. Strings should not be allowed to be built directly from bytes, but only from converting them into explicitly UTF-8 (or, for API specific needs, other encodings should you want to enter the fun world of UCS-2 for some reason), which can and should be a cheap wrapper to minimize costs. Bytes are not strings. Bytes can represent strings, numbers, pointers, absolutely anything.
Narhem 2y ago
Disagree, I’m so disappointed in companies who do sprint type development refusing to use Python. It works well with the “Silicon Valley startup ecosystem”. That being said, as far as workplace differences I’d say Java shops would be the ideal, slower, less long term problems but so much more initial investment.
- stackskipton 2y ago
  As SV startup with Python monolith, yes, it's very common for startup but generally gets ejected because lack of strict typing and speed. We are replacing with Go, Node and .Net.
  - Narhem 2y ago
    Python offers typing with static compiling. .Net doesn’t really match with startup culture. I’m on the fence about Go, but maybe that’s my preference to having classes. But yeah I’m the general case if I was an investor I’d be more careful with purely Python based startups.
    - bigstrat2003 2y ago
      > Python offers typing with static compiling. Python doesn't enforce types and as far as I know has no plans to. > .Net doesn’t really match with startup culture. Who the hell cares? If it's the best tool for the job, use it. Anything else is unprofessional as hell.
      - Narhem 2y ago
        Tell that to the people who downvote me which seems unprofessional as hell. If I want to learn .Net which is more time consuming and more difficult to find employees why would I use it? Makes sense if you are in an area with a lot of windows people, but that’s not the case anywhere other than Texas. And the compiler enforce typing. Admittedly not as nice as Go since you have to rely on external tools but workable. People like their curly brackets though. Just not as helpful when dealing with system problems.
nikcub 2y ago
Most active developers opt into this behaviour via linter rules[0]. I see only the downsides of building this into the language. [0] https://docs.astral.sh/ruff/rules/bare-except/ https://docs.astral.sh/ruff/rules/bare-except/
- adamc 2y ago
  This, in a huge way. Especially given all the code that already exists.
kragen 2y ago
The Python maintainers have switched from considering backward compatibility useful but costly to considering it actively harmful; there was a campaign a few years ago to convince library maintainers to stop making their code Python-2-compatible: > The Python 3 statement was drawn up around 2016. Projects pledged to require Python 3 by 2020, giving other projects confidence that they could plan a similar transition, and allowing downstream users to figure out their options without a nasty surprise. We didn’t force people to move to Python 3, but if they wanted to stick with Python 2, they would stop getting new versions of our projects. (https://python3statement.github.io/ https://python3statement.github.io/) I know this sounds like a joke, and you probably think you're misreading, but no. Projects pledged to require Python 3 by 2020. They made a promise to break backward compatibility. Not just a few minor projects, either; TensorFlow, Spark, IPython, Pandas, NumPy, SymPy, Hypothesis, etc. Since that happened, everyone who considers backward-compatibility good (if costly), rather than evil, has abandoned Python. The "other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...)" would have to fork Python, but it's probably too late for that; they can hardly hope to fork TensorFlow, Pandas, etc., as well.
- williamsmj 2y ago
  1. That python 3 statement was not drawn up by "the Python maintainers". It was drawn up by downstream library owners. 2. To the extent you object to changes in the core language, the python maintainers do have a backwards compatibility statement and prominent timelines for deprecation. You may disagree with these, but they are public. 3. At the time it was written, the python 3 statement proposed dropping support for a version of python with known security problems and no plans for security updates. It seems like your argument is with the python 2 to python 3 transition, which feels like a conversation we've had here before.
  - kragen 2y ago
    Anyone can of course apply security fixes to Python 2, because it's open-source. My objection is not to library owners dropping support for Python 2, which is a perfectly reasonable choice for them to make—backward compatibility can be costly, after all, and the benefits may not be worth it. My objection is to library owners pledging to drop support for Python 2, because that entails that they think backward compatibility is itself harmful. To me, that's pants-on-head crazy thinking, like not wanting to wear last season's sweater, or not wanting to use JSON because it's too old. Observably, since this happened, the Python maintainers have been very active at breaking backward compatibility. (And there's substantial overlap between Python maintainers and major Python library maintainers, which I suspect explains the motivation.) I think this is probably due to people who don't think backward compatibility is actually evil (the aforementioned "all the other users for whom python is an foreign, incidental, but indispensable part of their work") fleeing Python for ecosystems like Node, Golang, and Rust. This eliminates the constituency for maintaining backward compatibility. I do think the botched 2→3 transition was probably the wellspring of this dysfunction, but I don't think that in itself it was necessarily a bad idea, just executed badly. As a result of this mess, it's usually easy for me to run Lisp code from 40 years ago, C code from 30 years ago, or Perl or JS code from 20 years ago, but so difficult to run most Python code from 5 years ago as to be impractical.
zitterbewegung 2y ago
Well this PEP won't be going forward see https://discuss.python.org/t/pep-760-no-more-bare-excepts/67182/83 https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...
m463 2y ago
Honestly 2->3 has been a HUGE mess, and python should be learning from these sorts of mistakes.
o999 2y ago
s/except:/except Exception:/g
- orf 2y ago
  Not the same: should be BaseException. I guess this highlights op’s issue quite well.

rurban 2y ago

major changes with breaking backward compatibility would require a major bump. Fine for python 4 I would say.

kristjansson 2y ago
Sure I guess? But we've just barely stopped talking about Python3, and that was released 13-16 years ago[1]. Is _this_ change worth another decade of thrashing the ecosystem? Is __any__ change? [1]: depending on if we count 3.0 vs 3.2 when it was actually kinda usable.
nine_k 2y ago
Why, it just should be opt-in: from __future__ import no_bare_except ...and enjoy.
- afiori 2y ago
  Python should have the ability to set per-module flags for these kinds of incompatibilities. I guess that __future__ is doing something similar, but I am thinking of something like declaring how options should be set for your module and then only the code in that module is affected. (It would be nice being able to set constraints on what options your dependencies can enable) I guess that for std functionality this is impossible (like if the dict changed its key sorting it might be too hard to dispatch on the original file) but for syntax it should be perfectly possible.
williamsmj 2y ago
Again, python does not use semantic versioning. 3.12 and 3.13 are different major versions. The deprecation policy is documented and public. https://peps.python.org/pep-0387/ https://peps.python.org/pep-0387/.
- unethical_ban 2y ago
  TIL. In the doc you linked, they reference "major" and "minor" versions. So they claim to have some concept of version numbers having different significance... Why don't they adhere to semantic versioning if they dress their version numbers like that? At least Linux just admits their X.Y scheme means nothing.

isoprophlex 2y ago

Exactly this. I totally agree. It's incredible to think that some people still run python 2 scripts; something unpalatable to the point of being nauseating for a day-to-day python programmer, but totally understandable in the context of incidental usage by a scientist dealing with legacy systems. If these things start happening to python 3 on a larger scale, might as well throw in the towel and go for python 4.

mrbungie 2y ago
I read "python 2" and a part of my soul cried in utf-8.
- bdowling 2y ago
  Are you sure it didn't cry in `bytes()`?
- nine_k 2y ago
  There are places that don't operate in anything but ASCII. Or even anything but 0123456789,\n\r.
- bobim 2y ago
  Not sure 3 did anything to the number of circular permutations of encode and decode one need to fiddle with until that damn csv is pulled in correctly.
- afiori 2y ago
  Programming languages are too obsessed with unicode in my opinion: String operations should have bytes and utf-{8,16} versions. The string value would have is_valid_utf_{8,16} flags and operations should unset them if they end up breaking the format (eg str[i] = 0xff would always mark the string as not unicode, str[i] = 0x00 would check if the flag was set and it so check whether the assignment broke a codepoint and unset the flag if so)
  - sigh_again 2y ago
    There are zero reasons to not go full UTF-8, everywhere, all the time. Strings should not be allowed to be built directly from bytes, but only from converting them into explicitly UTF-8 (or, for API specific needs, other encodings should you want to enter the fun world of UCS-2 for some reason), which can and should be a cheap wrapper to minimize costs. Bytes are not strings. Bytes can represent strings, numbers, pointers, absolutely anything.

Narhem 2y ago

Disagree, I’m so disappointed in companies who do sprint type development refusing to use Python. It works well with the “Silicon Valley startup ecosystem”. That being said, as far as workplace differences I’d say Java shops would be the ideal, slower, less long term problems but so much more initial investment.

stackskipton 2y ago
As SV startup with Python monolith, yes, it's very common for startup but generally gets ejected because lack of strict typing and speed. We are replacing with Go, Node and .Net.
- Narhem 2y ago
  Python offers typing with static compiling. .Net doesn’t really match with startup culture. I’m on the fence about Go, but maybe that’s my preference to having classes. But yeah I’m the general case if I was an investor I’d be more careful with purely Python based startups.
  - bigstrat2003 2y ago
    > Python offers typing with static compiling. Python doesn't enforce types and as far as I know has no plans to. > .Net doesn’t really match with startup culture. Who the hell cares? If it's the best tool for the job, use it. Anything else is unprofessional as hell.
    - Narhem 2y ago
      Tell that to the people who downvote me which seems unprofessional as hell. If I want to learn .Net which is more time consuming and more difficult to find employees why would I use it? Makes sense if you are in an area with a lot of windows people, but that’s not the case anywhere other than Texas. And the compiler enforce typing. Admittedly not as nice as Go since you have to rely on external tools but workable. People like their curly brackets though. Just not as helpful when dealing with system problems.

nikcub 2y ago

Most active developers opt into this behaviour via linter rules[0]. I see only the downsides of building this into the language. [0] https://docs.astral.sh/ruff/rules/bare-except/ https://docs.astral.sh/ruff/rules/bare-except/

adamc 2y ago
This, in a huge way. Especially given all the code that already exists.

kragen 2y ago

The Python maintainers have switched from considering backward compatibility useful but costly to considering it actively harmful; there was a campaign a few years ago to convince library maintainers to stop making their code Python-2-compatible: > The Python 3 statement was drawn up around 2016. Projects pledged to require Python 3 by 2020, giving other projects confidence that they could plan a similar transition, and allowing downstream users to figure out their options without a nasty surprise. We didn’t force people to move to Python 3, but if they wanted to stick with Python 2, they would stop getting new versions of our projects. (https://python3statement.github.io/ https://python3statement.github.io/) I know this sounds like a joke, and you probably think you're misreading, but no. Projects pledged to require Python 3 by 2020. They made a promise to break backward compatibility. Not just a few minor projects, either; TensorFlow, Spark, IPython, Pandas, NumPy, SymPy, Hypothesis, etc. Since that happened, everyone who considers backward-compatibility good (if costly), rather than evil, has abandoned Python. The "other users for whom python is an foreign, incidental, but indispensable part of their work (scientists, analysts, ...)" would have to fork Python, but it's probably too late for that; they can hardly hope to fork TensorFlow, Pandas, etc., as well.

williamsmj 2y ago
1. That python 3 statement was not drawn up by "the Python maintainers". It was drawn up by downstream library owners. 2. To the extent you object to changes in the core language, the python maintainers do have a backwards compatibility statement and prominent timelines for deprecation. You may disagree with these, but they are public. 3. At the time it was written, the python 3 statement proposed dropping support for a version of python with known security problems and no plans for security updates. It seems like your argument is with the python 2 to python 3 transition, which feels like a conversation we've had here before.
- kragen 2y ago
  Anyone can of course apply security fixes to Python 2, because it's open-source. My objection is not to library owners dropping support for Python 2, which is a perfectly reasonable choice for them to make—backward compatibility can be costly, after all, and the benefits may not be worth it. My objection is to library owners pledging to drop support for Python 2, because that entails that they think backward compatibility is itself harmful. To me, that's pants-on-head crazy thinking, like not wanting to wear last season's sweater, or not wanting to use JSON because it's too old. Observably, since this happened, the Python maintainers have been very active at breaking backward compatibility. (And there's substantial overlap between Python maintainers and major Python library maintainers, which I suspect explains the motivation.) I think this is probably due to people who don't think backward compatibility is actually evil (the aforementioned "all the other users for whom python is an foreign, incidental, but indispensable part of their work") fleeing Python for ecosystems like Node, Golang, and Rust. This eliminates the constituency for maintaining backward compatibility. I do think the botched 2→3 transition was probably the wellspring of this dysfunction, but I don't think that in itself it was necessarily a bad idea, just executed badly. As a result of this mess, it's usually easy for me to run Lisp code from 40 years ago, C code from 30 years ago, or Perl or JS code from 20 years ago, but so difficult to run most Python code from 5 years ago as to be impractical.

zitterbewegung 2y ago

Well this PEP won't be going forward see https://discuss.python.org/t/pep-760-no-more-bare-excepts/67182/83 https://discuss.python.org/t/pep-760-no-more-bare-excepts/67...

m463 2y ago

Honestly 2->3 has been a HUGE mess, and python should be learning from these sorts of mistakes.

o999 2y ago

s/except:/except Exception:/g

orf 2y ago
Not the same: should be BaseException. I guess this highlights op’s issue quite well.