5 ms·

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 h

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)
    - fwip 2y ago
      Recently, I saw somebody writing that in their projects, they define a Glossary.txt of terms, and then set up their tooling to flag any use of an identifier that isn't a word or defined in the Glossary. (Allowing also for compound words like camelCase and snake_case, of course). So in their project they could define `pid: process identifier [...]`, and then their tooling would be allow a variable named `new_pid`. Upsides: consistent vocabulary in your project, a centralized place to look up jargon, and a subtle friction to avoid adding new terms that people might not immediately grok. I wish I could remember the source; because it sounded like a nice setup to steal.
    - kstrauser 2y ago
      That "in the domain" bit is an excellent callout, and I'm stealing it. "Why don't you write out 'process_id'?" "Because the people who maintain the sort of code that cares about pids all refer to it as 'pid'."
  - xorcist 2y ago
    So you intentionally make code harder to read for most of the humans on this planet, so satisfy a desire to use longer identifiers?
  - tsimionescu 2y ago
    So your code is full of HyperTextTransferProtocolSecureClients, using a TransportLayerSecurityCertificate?
- 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.

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)
  - fwip 2y ago
    Recently, I saw somebody writing that in their projects, they define a Glossary.txt of terms, and then set up their tooling to flag any use of an identifier that isn't a word or defined in the Glossary. (Allowing also for compound words like camelCase and snake_case, of course). So in their project they could define `pid: process identifier [...]`, and then their tooling would be allow a variable named `new_pid`. Upsides: consistent vocabulary in your project, a centralized place to look up jargon, and a subtle friction to avoid adding new terms that people might not immediately grok. I wish I could remember the source; because it sounded like a nice setup to steal.
  - kstrauser 2y ago
    That "in the domain" bit is an excellent callout, and I'm stealing it. "Why don't you write out 'process_id'?" "Because the people who maintain the sort of code that cares about pids all refer to it as 'pid'."
- xorcist 2y ago
  So you intentionally make code harder to read for most of the humans on this planet, so satisfy a desire to use longer identifiers?
- tsimionescu 2y ago
  So your code is full of HyperTextTransferProtocolSecureClients, using a TransportLayerSecurityCertificate?
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.