4 ms·

>> I fail to see how this is even being considered. To me it stinks of an ego-centric person thinking they're a "language developer" and knowing better than th

>> I fail to see how this is even being considered. To me it stinks of an ego-centric person thinking they're a "language developer" and knowing better than the actual users of the language what's best for them. Just because something can be misused doesn't mean you have to take it away. I haven't noticed, but since Rust came along is there a trend among languages to enforce "safer" programming at the language level? I could see that kind of thinking getting way out of hand. If that's the case, I would see this one as "I'm going to save the world with this dumb little change that breaks things for a bunch of people!" I would hope a PEP like this came about from frequent user requests but that doesn't seem to be the case.

gmueckl 2y ago
Rust had extremely successful marketing based on its security claims. It's no surprise that other languages jump on that bandwagon to not get left behind, is it?
slt2021 2y ago
can these language improvements be implemented at linter level? so that people can opt-in or opt-out selectively, per their own discretion, for these kinds of rules I dont see the point of this being part of the language since it break compat and brings zero benefits at runtime
- 0cf8612b2e1e 2y ago
  In the PEP, some of the comments noted this was basically a linting issue. No reason to break the language over it.
- willcipriano 2y ago
  Flake8 already provides this for anyone concerned about it. https://www.flake8rules.com/rules/E722.html https://www.flake8rules.com/rules/E722.html
  - strunz 2y ago
    So does pylint which has been there forever https://pylint.pycqa.org/en/latest/user_guide/messages/warning/bare-except.html https://pylint.pycqa.org/en/latest/user_guide/messages/warni...
- akkad33 2y ago
  Linters already flag this as error
sestep 2y ago
It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously; that's why it's still on version 1.x. Granted, sometimes there is a compiler bug that causes some old code not to compile with newer versions of Rust, but that is rare and never intentional like this PEP.
- School-Cotton 2y ago
  They do take it seriously, I agree. However, the commonly repeated meme that Rust only makes backwards-incompatible changes by mistake or to fix soundness issues is wrong. They allow themselves to make changes if they're judged to have a low (but nonzero) risk of causing backwards incompatibility in the wild. For example, adding a new function to a standard trait can be backwards incompatible but they do it all the time.
  - kibwen 2y ago
    Indeed. Although it's worth noting that the same is true of e.g. stable enterprise favorites like Java, which regularly makes minor breaking changes that are judged to have little impact (which is why every Java release is accompanied by a compatibility guide; see the "Important Changes", "Removed Features", and "Other Notes" sections of the most recent release notes: https://www.oracle.com/java/technologies/javase/23-relnote-issues.html https://www.oracle.com/java/technologies/javase/23-relnote-i...).
- phkahler 2y ago
  >> It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously; I mentioned Rust because the memory safety guarantees are a significant new thing for a language like that. I forgot about "managed" languages like C# because that's quite far from my mind, but that's another significant attempt at safety. This kind of little detail in the PIP is really insignificant by comparison, so I was speculating that it might be driven by some kind of "save everyone" mentality. If so, wondering if that's a trend lately and I hadn't noticed.
- jbiason 2y ago
  (Just to be sorta pedantic) I don't think it's the version 1.x that promotes backward compatibility, but editions. In 2016, you could call your function `fn async(...) { ... }` without any issues, and you can still compile this code with the modern version of rustc. If you want to use the async features of Rust, you need to change your edition to at least 2018, which brings breaking changes in the language. And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate. (So, I guess the ideal world would to first look at the package management in Python, and *then* try to introduce breaking changes. And I'm withholding how much I'm angry at the PSF for postponing having a decent package manager for 20 years and investing in removing the GIL and adding JIT.)
School-Cotton 2y ago
There have been people trying to enforce safer programming at the language level at least since Java positioned itself as the safer alternative to C++ way back in the 90s.
- riffraff 2y ago
  I'm pretty sure Bertrand Meyer's OOSC[0] from 1988 had something like "if a language has a feature which comes with warnings that you shouldn't use it, it shouldn't have that feature" (paraphrasing). [0] https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...
pca006132 2y ago
No. A serious language designer will try to make things they like at the beginning, not trying to patch it later. Patching via breaking public API (language design) is never a good thing.
- phkahler 2y ago
  >> A serious language designer.... That's why I put "language developer" in quotes.
- beeboobaa3 2y ago
  Let me just grab my time machine and go back 40 years

gmueckl 2y ago

Rust had extremely successful marketing based on its security claims. It's no surprise that other languages jump on that bandwagon to not get left behind, is it?

slt2021 2y ago

can these language improvements be implemented at linter level? so that people can opt-in or opt-out selectively, per their own discretion, for these kinds of rules I dont see the point of this being part of the language since it break compat and brings zero benefits at runtime

0cf8612b2e1e 2y ago
In the PEP, some of the comments noted this was basically a linting issue. No reason to break the language over it.
willcipriano 2y ago
Flake8 already provides this for anyone concerned about it. https://www.flake8rules.com/rules/E722.html https://www.flake8rules.com/rules/E722.html
- strunz 2y ago
  So does pylint which has been there forever https://pylint.pycqa.org/en/latest/user_guide/messages/warning/bare-except.html https://pylint.pycqa.org/en/latest/user_guide/messages/warni...
akkad33 2y ago
Linters already flag this as error

sestep 2y ago

It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously; that's why it's still on version 1.x. Granted, sometimes there is a compiler bug that causes some old code not to compile with newer versions of Rust, but that is rare and never intentional like this PEP.

School-Cotton 2y ago
They do take it seriously, I agree. However, the commonly repeated meme that Rust only makes backwards-incompatible changes by mistake or to fix soundness issues is wrong. They allow themselves to make changes if they're judged to have a low (but nonzero) risk of causing backwards incompatibility in the wild. For example, adding a new function to a standard trait can be backwards incompatible but they do it all the time.
- kibwen 2y ago
  Indeed. Although it's worth noting that the same is true of e.g. stable enterprise favorites like Java, which regularly makes minor breaking changes that are judged to have little impact (which is why every Java release is accompanied by a compatibility guide; see the "Important Changes", "Removed Features", and "Other Notes" sections of the most recent release notes: https://www.oracle.com/java/technologies/javase/23-relnote-issues.html https://www.oracle.com/java/technologies/javase/23-relnote-i...).
phkahler 2y ago
>> It's interesting that you mention Rust, since Rust takes backward compatibility quite seriously; I mentioned Rust because the memory safety guarantees are a significant new thing for a language like that. I forgot about "managed" languages like C# because that's quite far from my mind, but that's another significant attempt at safety. This kind of little detail in the PIP is really insignificant by comparison, so I was speculating that it might be driven by some kind of "save everyone" mentality. If so, wondering if that's a trend lately and I hadn't noticed.
jbiason 2y ago
(Just to be sorta pedantic) I don't think it's the version 1.x that promotes backward compatibility, but editions. In 2016, you could call your function `fn async(...) { ... }` without any issues, and you can still compile this code with the modern version of rustc. If you want to use the async features of Rust, you need to change your edition to at least 2018, which brings breaking changes in the language. And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate. (So, I guess the ideal world would to first look at the package management in Python, and *then* try to introduce breaking changes. And I'm withholding how much I'm angry at the PSF for postponing having a decent package manager for 20 years and investing in removing the GIL and adding JIT.)

School-Cotton 2y ago

There have been people trying to enforce safer programming at the language level at least since Java positioned itself as the safer alternative to C++ way back in the 90s.

riffraff 2y ago
I'm pretty sure Bertrand Meyer's OOSC[0] from 1988 had something like "if a language has a feature which comes with warnings that you shouldn't use it, it shouldn't have that feature" (paraphrasing). [0] https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

pca006132 2y ago

No. A serious language designer will try to make things they like at the beginning, not trying to patch it later. Patching via breaking public API (language design) is never a good thing.

phkahler 2y ago
>> A serious language designer.... That's why I put "language developer" in quotes.
beeboobaa3 2y ago
Let me just grab my time machine and go back 40 years