8 ms·

If I’m understanding this correctly this proposal would fully break compatibility with many (most?) codebases, actually remove syntactic sugar and force more ch

If I’m understanding this correctly this proposal would fully break compatibility with many (most?) codebases, actually remove syntactic sugar and force more characters for the same functionality. I fail to see how this is even being considered. I don’t understand the idiomatic viewpoint either here, I understand the author personally finds it confusing when excepts aren’t verbose but I think you would be hard pressed to find many python developers who agree. Even outside the ecosystem, most languages have been adding more support for bare excepts (like js with bare catch) so this feels like a step backwards. But maybe I’m just not understanding this proposal!

Larrikin 2y ago
Python feels like they are fixing the language the best they can by slowly and properly adding explicit types. Character count is not a valid argument when we have hard drives that are multiple terabytes and IDEs and LLMs that will gladly auto complete a full word with the import. Foo, bar variable names and i, n incrementers should be banished to freshman level undergrad tests meant to intentionally confuse the student. I'm hoping Python 4 will be a big breaking change similar to the previous one and full support for explicit types will be one of the reasons.
- AlexandrB 2y ago
  Character count is a valid argument because a human is going to have to read the code at some point. Otherwise, Java style names like "countriesFromAsiaWhereAreTheMostPlanesAndBoats" would be just fine. Edit: I don't get the hate for "i" or "j" as increment variables. When you're working with numerical data they closely match how you would express the same operation with mathematical notation and are idiomatic to the point that everyone with non-trivial experience in programming knows what they represent. There are better options in some cases (e.g. "for name in names:"), but there's nothing inherently wrong with i, j, k, etc.
  - Larrikin 2y ago
    But that's a ridiculous example you're proposing in bad faith. I flag nearly all abbreviations in code reviews because code is meant to be read and the names of things should be clear.
    - AlexandrB 2y ago
      It's not in bad faith to say that there's a cognitive load to having longer line lengths or, god forbid, wrapped lines when you're trying to figure out what the code is actually doing with that data the variables represent. Obviously the Python "except" case being discussed is not a big deal in this regard, but you made a blanket statement about character count being no big deal because of big hard drives and IDEs.
    - lostdog 2y ago
      How about abbreviating the 12 most common things in the codebase, but everything else is long? That's a nice compromise where you need to learn a few core concepts, but the code itself is easier to scan for bugs in a lot of places.
    - School-Cotton 2y ago
      I work on code that uses `pid` pervasively, and it would drive me crazy if someone insisted I write out `processId` every time. Same with `tx` or `rx` for channel endpoints, `i` for loop variables, `txId` or `tid` for transaction ID in databases, etc. If something is very common in the domain you're working in it's more annoying _not_ to abbreviate it.
      - Kim_Bruning 2y ago
        In certain contexts, I'm ok with eg (off the top of my head): * x, y, z (coordinates) * r, g, b, a; c, m, y, k; y, u, v (colors) * i, j, k matrices and such * p, i, d; Kp, Ki, Kd in process control * rv (return value), where it is clear what The Thing To Be returned is. * common variables from eg physics Generally because these are well known and defined in particular contexts. I don't always make it, but sometimes an argument can be made that single letters are better known/recognizable by their single letter name. Compare: * total_energy = mass * light_speed_constant ^ 2 vs * E=m*c^2 Or: * process_control_setting = proportional_component + integral_component + derivative_component vs * q=p+i+d (for those of us who know PID control)
  - NAHWheatCracker 2y ago
    At my last job, there was a frontend developer who added a linter rule that variable names must be at least 2 characters long. The project already had 20,000 lines of code. Every time anyone made a change to a file, they would have to rename all the one letter variables. Usually, this meant all the for loops in the file. I tried to explain how pointless this rule was, but he wasn't having any of it. Most people just renamed variables like i > ii, which was worse.
    - deleted 2y ago
      [deleted]
    - morkalork 2y ago
      What is even the point of digging in deeper, did they not see everyone around them doing the i>ii workaround? You've lost, call it a failed experiment and move on.
    - tomrod 2y ago
      Eye and Jay are go to as well
    - johnny22 2y ago
      a good linter rule would have exceptions for loop variables by context by just by name like i, j, k. Often just by name is good enough at least for a solo dev or small team. I require them to be at least 3 chars EXCEPT those. For example: https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-length.html#cmdoption-arg-IgnoredLoopCounterNames https://clang.llvm.org/extra/clang-tidy/checks/readability/i...
- gjvc 2y ago
  >>> I'm hoping Python 4 will be a big breaking change similar to the previous one Python3 did not break enough to justify the jump from 2 to 3, IMHO. >>> and full support for explicit types will be one of the reasons. Fair point!
  - hyperbrainer 2y ago
    It did though. Anything worse would be reminiscent of the Perl5->Perl6 disaster.
  - klardotsh 2y ago
    Python 3 broke almost literally every non-trivial Python file on earth, and was saved only by `2to3` and `six` being able to automate or library-ify away 75% or so of the changes. The remaining 25% was make-work for teams needing to avoid the deprecation/EOL/vuln demons (or wanting to take up new language features that became Py3-only), and many teams took the opportunity to instead spend that time rewriting their codebases in Go or TypeScript+Node. I don't know how much more breakage you really wanted out of Python 3 if "permanently scoured the public image of the language and caused many Python shops to, at least partially, stop being Python shops" wasn't enough. (I say this as a still-fan of Python who has written quite a lot of it and contributed to MicroPython/CircuitPython's internals - I just also worked at a Python shop during the Py2->3 hell, and frankly, even my current dayjob still talks about that transition as a nightmare to watch out for if any other language starts doing similar talk.)
    - kstrauser 2y ago
      My experience was different. The single biggest change I had to deal with in a zillion places was change of str from bytes to unicode. That wasn't just a syntax change. It forced me to chase down all the places where I'd been handling treating strings like bytes because it worked 99% of the time as long as I was only dealing with ASCII. No amount of clever AST re-writing would save me from those earlier mistakes.
    - zahlman 2y ago
      Python 3 made entire classes of errors impossible: * Beginners don't introduce ACE exploits into their program from the get-go, because `input` is what `raw_input` was before and the "convenient" wrapper using `eval` was no longer available - so instructors were forced to teach students about explicit type conversions, like they should have been doing the whole time. * You can't get `UnicodeDecodeError` from calling `.encode`, or `UnicodeEncodeError` from calling `.decode`, because you're never in the position of pretending that a sequence of bytes is a "string". There's no illogical "basestring" type and no `str` objects with ambiguous semantics - `.decode` and `.encode` do what they say, and belong to separate types. These problems resulted in a huge mess of duplicate Q&A on Stack Overflow full of incorrect advice from people with no clue what they were doing, and empowered people to ignore essential truths about Unicode until it blew up into a bigger problem. * Similarly, when you read from a text file, you actually get text now. * `print` used to be confusing and have weird ambiguities and tons of special syntax. Being a function means it can be taught the same way as any other function call; plus you get use as a higher-order function, unpacking operators (you can't do `print(*range(10))` in 2.x). * `1000000000 in range(1000000000)` no longer hangs. `xrange` does not solve this problem (although it does improve matters quite a bit by avoiding high memory usage). * Sorting heterogeneous lists correctly produces an error, rather than an ordering so strange as to merit its own Stack Overflow Q&A (https://stackoverflow.com/questions/3270680 https://stackoverflow.com/questions/3270680 and many duplicates). (You can still replicate the old order if you want.) * `isinstance(x, int)` doesn't fail because of `x` being too large. This was a bizarre speed bump in such a high-level language. * You can write '£' in your source code and you only have to declare an encoding if you use something other than UTF-8 (which Python correctly identified as the eventual winner). When Python 3.2 came out I found it to be a breath of fresh air. By 3.4 I was already starting to wonder why so many others were dragging their feet on migrating.
- gizmo 2y ago
  Javascript somehow manages to grow without breaking backwards compatibility. So does C++. Breaking countless packages (and forks of packages) in the pursuit of something as nebulous as language purity is a big mistake. I happen to like explicit typing but it's not the kind of thing you can graft onto a mature language without making awful compromises. Also, it pushes massive externalities onto the millions of people who rely on Python for their work.
  - deleted 2y ago
    [deleted]
- jerf 2y ago
  By the time you've written a Python that has all explicit types in it, and harvested the speed advantages the interpreter can have when it can count on that, and all the other cascading changes that would result, and the fact that you would discard 100% of all previous modules both Python and C, you might as well just start using one of the existing statically-typed languages that already has a mature ecosystem. Python should be working on being the best Python it can be, not being an adequate Python and an inadequate bodged-on static language on the side.
  - akkad33 2y ago
    > harvested the speed advantages the interpreter can have when it can count on that, Does the interpreter actually optimize code based on type information? My knowledge is that it does not
    - jerf 2y ago
      Python 3 does not, but the hypothetical Python 4 would be crazy to put types on everything and then not accelerate its interpreter with the resulting data. The problem Python 3 has is dynamic types, as the dynamically-typed languages implement them, are viral; one little crack lets them in somehow and all the code operating on the data has to assume it's viral.
      - akkad33 2y ago
        I would be pleasantly surprised if they manage to do that. The current type checkers of Python, as useful as they are, hit the limit pretty fast, because of its extremely dynamic nature and the type system struggling to type check valid expressions. The number of times I've seen common pandas and numpy code not type check
    - morningsam 2y ago
      CPython doesn't, but there is Mypyc [1] which compiles statically typed Python to faster C extensions leveraging the type information. As usual, this comes with tons of limitations [2] [1]: https://mypyc.readthedocs.io/en/stable/ https://mypyc.readthedocs.io/en/stable/ [2]: https://mypyc.readthedocs.io/en/stable/differences_from_python.html#unsupported-features https://mypyc.readthedocs.io/en/stable/differences_from_pyth...
- Chris2048 2y ago
  > I'm hoping Python 4 will be I'm hoping "Python 4" will be another language entirely that displaces it, Fixing some ecosystem problems upfront (packaging, concurrency/GIL). Nim is possible candidate, though Go is pretty popular w/ Pythonistas. My personal unhappiness with how Py3K was handled, plus recent PSF events make me feel new leadership would also be a boon..
  - cb321 2y ago
    I have found Nim more useful/usable than Python + Cython since about 2014 for my personal use cases and almost always much more efficient on a "per unit of effort basis" than Go. At least if you are willing to write whatever code you need or link in C/C++ instead of relying on people gifting it to you. I think the ecosystem leadership position Python finds itself in lately may well make Py-core silly enough to think "our users will tolerate our breaking-all-their-code antics no matter what". I suggest a more consenting-adults alternative here: https://news.ycombinator.com/item?id=41790766 https://news.ycombinator.com/item?id=41790766
  - zahlman 2y ago
    FWIW I've been semi-actively designing a language of that sort, which I call Fawlty, since about February of this year. I was planning to start writing about it in July but then all the PSF drama stuff happened and I didn't want people to assume incorrectly that the idea was motivated by my disappointment with the community. In fact, I'd been thinking about doing it since probably November of the previous year - and it's motivated by long-held beliefs that Python's design falls short of the Zen; several of the most common beginner pitfalls could and should be avoided by syntax changes and by a different approach to parsing the code; and the standard library is full of ancient APIs that look terrible because they're motivated by C and Java designs that used to be the best we had but seem highly unidiomatic now. It was somewhere in November or December last year that I first wrote those thoughts down more concretely (with details about what those pitfalls are etc.). Given that pace of progress, however, I've more or less given up on ever expecting myself to publish something usable - by myself, at least. I've decided for now that it will be more practical to add blog posts about my ideas to the queue, and possibly see about my own implementation later.
- bryanlarsen 2y ago
  > I'm hoping Python 4 will be a big breaking change similar to the previous one and full support for explicit types will be one of the reasons. History shows that's a good idea if and only if you use a new name for the new language. cf Python 2 -> 3, Perl 5 -> 6 -> Raku, Javascript -> Typescript You can keep Python as part of the name. Call it SuperPython or something. Just don't call it Python 4.
smohare 2y ago
[dead]
dataflow 2y ago
> force more characters for the same functionality This is actually a good thing in some cases (possibly this one). Risky stuff should inherently be harder to do than safer stuff, otherwise people will reach for the risky alternatives when they don't need to, just to save time - or because they don't realize the risk. Or at least, that's often the case. What's lacking here is evidence that this is actually happening. I can believe it, but evidence is necessary for breaking the language.
phkahler 2y ago
>> 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...
chefandy 2y ago
PEP contains lots of best practices that aren't enforced by the interpreter though, doesn't it? e.g. PEP 8. It's been a while so maybe PEP 8 is more unique than I realize? It seems like a pretty sensible recommendation that wouldn't necessarily need to change the way exceptions are handled by Python. Right there in PEP 8 it says in big text "A Foolish Consistency is the Hobgoblin of Little Minds." I imagine that enforcing this in the interpreter would fall under that, but it seems like a good piece of advice for folks new to the language, or more likely, new to coding.
- kristjansson 2y ago
  There are PEPs that are not language features, but this PEP is emphatically proposing a modification to the language.
- theamk 2y ago
  No one would anyone would object if this was a "best practice" or "linter rule". It's the enforcement by compiler, which will break lots of existing code, that makes people unhappy.
amelius 2y ago
I do have to say that this fun little scripting language is starting to look more and more like a serious compiled language.
- zahlman 2y ago
  Python is compiled to bytecode just like Java and C# - it just also happens to provide an environment out of box that will do it on the fly, and makes it much easier to access the "compiler services" in the standard library (and the built-in `eval`). And it's always been that way. The idea that some languages are "serious" and others are not is already suspect. The idea that being a "serious" language requires being "compiled", or that other languages are just for "scripting", will severely limit you as a developer.
thiht 2y ago
I love using the bare except in small 1-file scripts, it just does the job elegantly
zahlman 2y ago
>actually remove syntactic sugar and force more characters for the same functionality. I fail to see how this is even being considered. Python is not APL. Getting at the functionality in fewer characters is not a design goal - it's just a usually consequence of the actual design goal. This is being considered because "Explicit is better than implicit." and because it helps avoid a common class of error (e.g. `except: continue` prevents aborting a loop with Ctrl-C, which is often not intentional). Or as the PEP puts it: > While this syntax can be convenient for a “catch all” handler, it often leads to poor coding practices: > > 1. It can mask important errors that should be propagated. > 2. It makes debugging more difficult by catching and potentially hiding unexpected exceptions. > 3. It goes against the Python principle of explicit over implicit. Python isn't any other language, either. It certainly isn't taking design guidance from JavaScript (which runs in an environment where the page is expected to show something coherent, and not a loud screaming error, no matter how absurd the input data and/or code). As for how much code it would break, you made me curious: ~/Desktop/dev$ find . -name "*.py" | wc -l 49433 ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except.*:' | wc -l 109801 ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except:' | wc -l 5692 ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except[ \t]*:' | wc -l # just to make sure 5692 But drilling down further, over 2/3 of those bare excepts are in local copies of Python itself (i.e., multiple versions of the standard library) that I built from source. Probably all the rest are in dependencies. I don't write code like that myself if I'm even remotely paying attention. (Of course, that only tells me how many occurrences there were, not how many files have them. But the first two results imply an average of about 2 `except`s per file, so.)
01100011 2y ago
I don't know, but it seems like, as a language grows, the type of people working on improvements changes. In the beginning, the contributions come from people trying to solve application problems. In the end, the committees and contributors seem to be less connected to reality and more internal and isolated. They make changes that seem conceptually sound but aren't grounded in what the users of the language actually care about.

Larrikin 2y ago

Python feels like they are fixing the language the best they can by slowly and properly adding explicit types. Character count is not a valid argument when we have hard drives that are multiple terabytes and IDEs and LLMs that will gladly auto complete a full word with the import. Foo, bar variable names and i, n incrementers should be banished to freshman level undergrad tests meant to intentionally confuse the student. I'm hoping Python 4 will be a big breaking change similar to the previous one and full support for explicit types will be one of the reasons.

AlexandrB 2y ago
Character count is a valid argument because a human is going to have to read the code at some point. Otherwise, Java style names like "countriesFromAsiaWhereAreTheMostPlanesAndBoats" would be just fine. Edit: I don't get the hate for "i" or "j" as increment variables. When you're working with numerical data they closely match how you would express the same operation with mathematical notation and are idiomatic to the point that everyone with non-trivial experience in programming knows what they represent. There are better options in some cases (e.g. "for name in names:"), but there's nothing inherently wrong with i, j, k, etc.
- Larrikin 2y ago
  But that's a ridiculous example you're proposing in bad faith. I flag nearly all abbreviations in code reviews because code is meant to be read and the names of things should be clear.
  - AlexandrB 2y ago
    It's not in bad faith to say that there's a cognitive load to having longer line lengths or, god forbid, wrapped lines when you're trying to figure out what the code is actually doing with that data the variables represent. Obviously the Python "except" case being discussed is not a big deal in this regard, but you made a blanket statement about character count being no big deal because of big hard drives and IDEs.
  - lostdog 2y ago
    How about abbreviating the 12 most common things in the codebase, but everything else is long? That's a nice compromise where you need to learn a few core concepts, but the code itself is easier to scan for bugs in a lot of places.
  - School-Cotton 2y ago
    I work on code that uses `pid` pervasively, and it would drive me crazy if someone insisted I write out `processId` every time. Same with `tx` or `rx` for channel endpoints, `i` for loop variables, `txId` or `tid` for transaction ID in databases, etc. If something is very common in the domain you're working in it's more annoying _not_ to abbreviate it.
    - Kim_Bruning 2y ago
      In certain contexts, I'm ok with eg (off the top of my head): * x, y, z (coordinates) * r, g, b, a; c, m, y, k; y, u, v (colors) * i, j, k matrices and such * p, i, d; Kp, Ki, Kd in process control * rv (return value), where it is clear what The Thing To Be returned is. * common variables from eg physics Generally because these are well known and defined in particular contexts. I don't always make it, but sometimes an argument can be made that single letters are better known/recognizable by their single letter name. Compare: * total_energy = mass * light_speed_constant ^ 2 vs * E=m*c^2 Or: * process_control_setting = proportional_component + integral_component + derivative_component vs * q=p+i+d (for those of us who know PID control)
- NAHWheatCracker 2y ago
  At my last job, there was a frontend developer who added a linter rule that variable names must be at least 2 characters long. The project already had 20,000 lines of code. Every time anyone made a change to a file, they would have to rename all the one letter variables. Usually, this meant all the for loops in the file. I tried to explain how pointless this rule was, but he wasn't having any of it. Most people just renamed variables like i > ii, which was worse.
  - deleted 2y ago
    [deleted]
  - morkalork 2y ago
    What is even the point of digging in deeper, did they not see everyone around them doing the i>ii workaround? You've lost, call it a failed experiment and move on.
  - tomrod 2y ago
    Eye and Jay are go to as well
  - johnny22 2y ago
    a good linter rule would have exceptions for loop variables by context by just by name like i, j, k. Often just by name is good enough at least for a solo dev or small team. I require them to be at least 3 chars EXCEPT those. For example: https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-length.html#cmdoption-arg-IgnoredLoopCounterNames https://clang.llvm.org/extra/clang-tidy/checks/readability/i...
gjvc 2y ago
>>> I'm hoping Python 4 will be a big breaking change similar to the previous one Python3 did not break enough to justify the jump from 2 to 3, IMHO. >>> and full support for explicit types will be one of the reasons. Fair point!
- hyperbrainer 2y ago
  It did though. Anything worse would be reminiscent of the Perl5->Perl6 disaster.
- klardotsh 2y ago
  Python 3 broke almost literally every non-trivial Python file on earth, and was saved only by `2to3` and `six` being able to automate or library-ify away 75% or so of the changes. The remaining 25% was make-work for teams needing to avoid the deprecation/EOL/vuln demons (or wanting to take up new language features that became Py3-only), and many teams took the opportunity to instead spend that time rewriting their codebases in Go or TypeScript+Node. I don't know how much more breakage you really wanted out of Python 3 if "permanently scoured the public image of the language and caused many Python shops to, at least partially, stop being Python shops" wasn't enough. (I say this as a still-fan of Python who has written quite a lot of it and contributed to MicroPython/CircuitPython's internals - I just also worked at a Python shop during the Py2->3 hell, and frankly, even my current dayjob still talks about that transition as a nightmare to watch out for if any other language starts doing similar talk.)
  - kstrauser 2y ago
    My experience was different. The single biggest change I had to deal with in a zillion places was change of str from bytes to unicode. That wasn't just a syntax change. It forced me to chase down all the places where I'd been handling treating strings like bytes because it worked 99% of the time as long as I was only dealing with ASCII. No amount of clever AST re-writing would save me from those earlier mistakes.
  - zahlman 2y ago
    Python 3 made entire classes of errors impossible: * Beginners don't introduce ACE exploits into their program from the get-go, because `input` is what `raw_input` was before and the "convenient" wrapper using `eval` was no longer available - so instructors were forced to teach students about explicit type conversions, like they should have been doing the whole time. * You can't get `UnicodeDecodeError` from calling `.encode`, or `UnicodeEncodeError` from calling `.decode`, because you're never in the position of pretending that a sequence of bytes is a "string". There's no illogical "basestring" type and no `str` objects with ambiguous semantics - `.decode` and `.encode` do what they say, and belong to separate types. These problems resulted in a huge mess of duplicate Q&A on Stack Overflow full of incorrect advice from people with no clue what they were doing, and empowered people to ignore essential truths about Unicode until it blew up into a bigger problem. * Similarly, when you read from a text file, you actually get text now. * `print` used to be confusing and have weird ambiguities and tons of special syntax. Being a function means it can be taught the same way as any other function call; plus you get use as a higher-order function, unpacking operators (you can't do `print(*range(10))` in 2.x). * `1000000000 in range(1000000000)` no longer hangs. `xrange` does not solve this problem (although it does improve matters quite a bit by avoiding high memory usage). * Sorting heterogeneous lists correctly produces an error, rather than an ordering so strange as to merit its own Stack Overflow Q&A (https://stackoverflow.com/questions/3270680 https://stackoverflow.com/questions/3270680 and many duplicates). (You can still replicate the old order if you want.) * `isinstance(x, int)` doesn't fail because of `x` being too large. This was a bizarre speed bump in such a high-level language. * You can write '£' in your source code and you only have to declare an encoding if you use something other than UTF-8 (which Python correctly identified as the eventual winner). When Python 3.2 came out I found it to be a breath of fresh air. By 3.4 I was already starting to wonder why so many others were dragging their feet on migrating.
gizmo 2y ago
Javascript somehow manages to grow without breaking backwards compatibility. So does C++. Breaking countless packages (and forks of packages) in the pursuit of something as nebulous as language purity is a big mistake. I happen to like explicit typing but it's not the kind of thing you can graft onto a mature language without making awful compromises. Also, it pushes massive externalities onto the millions of people who rely on Python for their work.
- deleted 2y ago
  [deleted]
jerf 2y ago
By the time you've written a Python that has all explicit types in it, and harvested the speed advantages the interpreter can have when it can count on that, and all the other cascading changes that would result, and the fact that you would discard 100% of all previous modules both Python and C, you might as well just start using one of the existing statically-typed languages that already has a mature ecosystem. Python should be working on being the best Python it can be, not being an adequate Python and an inadequate bodged-on static language on the side.
- akkad33 2y ago
  > harvested the speed advantages the interpreter can have when it can count on that, Does the interpreter actually optimize code based on type information? My knowledge is that it does not
  - jerf 2y ago
    Python 3 does not, but the hypothetical Python 4 would be crazy to put types on everything and then not accelerate its interpreter with the resulting data. The problem Python 3 has is dynamic types, as the dynamically-typed languages implement them, are viral; one little crack lets them in somehow and all the code operating on the data has to assume it's viral.
    - akkad33 2y ago
      I would be pleasantly surprised if they manage to do that. The current type checkers of Python, as useful as they are, hit the limit pretty fast, because of its extremely dynamic nature and the type system struggling to type check valid expressions. The number of times I've seen common pandas and numpy code not type check
  - morningsam 2y ago
    CPython doesn't, but there is Mypyc [1] which compiles statically typed Python to faster C extensions leveraging the type information. As usual, this comes with tons of limitations [2] [1]: https://mypyc.readthedocs.io/en/stable/ https://mypyc.readthedocs.io/en/stable/ [2]: https://mypyc.readthedocs.io/en/stable/differences_from_python.html#unsupported-features https://mypyc.readthedocs.io/en/stable/differences_from_pyth...
Chris2048 2y ago
> I'm hoping Python 4 will be I'm hoping "Python 4" will be another language entirely that displaces it, Fixing some ecosystem problems upfront (packaging, concurrency/GIL). Nim is possible candidate, though Go is pretty popular w/ Pythonistas. My personal unhappiness with how Py3K was handled, plus recent PSF events make me feel new leadership would also be a boon..
- cb321 2y ago
  I have found Nim more useful/usable than Python + Cython since about 2014 for my personal use cases and almost always much more efficient on a "per unit of effort basis" than Go. At least if you are willing to write whatever code you need or link in C/C++ instead of relying on people gifting it to you. I think the ecosystem leadership position Python finds itself in lately may well make Py-core silly enough to think "our users will tolerate our breaking-all-their-code antics no matter what". I suggest a more consenting-adults alternative here: https://news.ycombinator.com/item?id=41790766 https://news.ycombinator.com/item?id=41790766
- zahlman 2y ago
  FWIW I've been semi-actively designing a language of that sort, which I call Fawlty, since about February of this year. I was planning to start writing about it in July but then all the PSF drama stuff happened and I didn't want people to assume incorrectly that the idea was motivated by my disappointment with the community. In fact, I'd been thinking about doing it since probably November of the previous year - and it's motivated by long-held beliefs that Python's design falls short of the Zen; several of the most common beginner pitfalls could and should be avoided by syntax changes and by a different approach to parsing the code; and the standard library is full of ancient APIs that look terrible because they're motivated by C and Java designs that used to be the best we had but seem highly unidiomatic now. It was somewhere in November or December last year that I first wrote those thoughts down more concretely (with details about what those pitfalls are etc.). Given that pace of progress, however, I've more or less given up on ever expecting myself to publish something usable - by myself, at least. I've decided for now that it will be more practical to add blog posts about my ideas to the queue, and possibly see about my own implementation later.
bryanlarsen 2y ago
> I'm hoping Python 4 will be a big breaking change similar to the previous one and full support for explicit types will be one of the reasons. History shows that's a good idea if and only if you use a new name for the new language. cf Python 2 -> 3, Perl 5 -> 6 -> Raku, Javascript -> Typescript You can keep Python as part of the name. Call it SuperPython or something. Just don't call it Python 4.

smohare 2y ago

[dead]

dataflow 2y ago

> force more characters for the same functionality This is actually a good thing in some cases (possibly this one). Risky stuff should inherently be harder to do than safer stuff, otherwise people will reach for the risky alternatives when they don't need to, just to save time - or because they don't realize the risk. Or at least, that's often the case. What's lacking here is evidence that this is actually happening. I can believe it, but evidence is necessary for breaking the language.

phkahler 2y ago

>> 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...

chefandy 2y ago

PEP contains lots of best practices that aren't enforced by the interpreter though, doesn't it? e.g. PEP 8. It's been a while so maybe PEP 8 is more unique than I realize? It seems like a pretty sensible recommendation that wouldn't necessarily need to change the way exceptions are handled by Python. Right there in PEP 8 it says in big text "A Foolish Consistency is the Hobgoblin of Little Minds." I imagine that enforcing this in the interpreter would fall under that, but it seems like a good piece of advice for folks new to the language, or more likely, new to coding.

kristjansson 2y ago
There are PEPs that are not language features, but this PEP is emphatically proposing a modification to the language.
theamk 2y ago
No one would anyone would object if this was a "best practice" or "linter rule". It's the enforcement by compiler, which will break lots of existing code, that makes people unhappy.

amelius 2y ago

I do have to say that this fun little scripting language is starting to look more and more like a serious compiled language.

zahlman 2y ago
Python is compiled to bytecode just like Java and C# - it just also happens to provide an environment out of box that will do it on the fly, and makes it much easier to access the "compiler services" in the standard library (and the built-in `eval`). And it's always been that way. The idea that some languages are "serious" and others are not is already suspect. The idea that being a "serious" language requires being "compiled", or that other languages are just for "scripting", will severely limit you as a developer.

thiht 2y ago

I love using the bare except in small 1-file scripts, it just does the job elegantly

zahlman 2y ago

>actually remove syntactic sugar and force more characters for the same functionality. I fail to see how this is even being considered. Python is not APL. Getting at the functionality in fewer characters is not a design goal - it's just a usually consequence of the actual design goal. This is being considered because "Explicit is better than implicit." and because it helps avoid a common class of error (e.g. `except: continue` prevents aborting a loop with Ctrl-C, which is often not intentional). Or as the PEP puts it: > While this syntax can be convenient for a “catch all” handler, it often leads to poor coding practices: > > 1. It can mask important errors that should be propagated. > 2. It makes debugging more difficult by catching and potentially hiding unexpected exceptions. > 3. It goes against the Python principle of explicit over implicit. Python isn't any other language, either. It certainly isn't taking design guidance from JavaScript (which runs in an environment where the page is expected to show something coherent, and not a loud screaming error, no matter how absurd the input data and/or code). As for how much code it would break, you made me curious: ~/Desktop/dev$ find . -name "*.py" | wc -l 49433 ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except.*:' | wc -l 109801 ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except:' | wc -l 5692 ~/Desktop/dev$ grep --include='*.py' -rnw . -e 'except[ \t]*:' | wc -l # just to make sure 5692 But drilling down further, over 2/3 of those bare excepts are in local copies of Python itself (i.e., multiple versions of the standard library) that I built from source. Probably all the rest are in dependencies. I don't write code like that myself if I'm even remotely paying attention. (Of course, that only tells me how many occurrences there were, not how many files have them. But the first two results imply an average of about 2 `except`s per file, so.)

01100011 2y ago

I don't know, but it seems like, as a language grows, the type of people working on improvements changes. In the beginning, the contributions come from people trying to solve application problems. In the end, the committees and contributors seem to be less connected to reality and more internal and isolated. They make changes that seem conceptually sound but aren't grounded in what the users of the language actually care about.