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.
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.
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.
I flag nearly all abbreviations in code reviews because code is meant to be read and the names of things should be clear.
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.
* 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)
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.
"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'."
Most people just renamed variables like i > ii, which was worse.
For example: https://clang.llvm.org/extra/clang-tidy/checks/readability/i...
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.
Does the interpreter actually optimize code based on type information? My knowledge is that it does not
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.
[1]: https://mypyc.readthedocs.io/en/stable/
[2]: https://mypyc.readthedocs.io/en/stable/differences_from_pyth...
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..
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
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.
If you're going to escape from Python, I think you need something more like Plissken.
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!
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.)
* 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 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.
I agree - it should have broken more (and thereby become able to fix more). It should also have been usable out of the gate and not majorly reworked (there was a serious battle over the syntax of byte and string literals, and possibly some other things, that resulted in 3.0 and 3.1 not seeing a full 5-year maintenance lifetime), and of course developers should have actually fixed stuff promptly and accepted that the obviously superior new ways of doing things were, in fact, obviously superior.
Unfortunately, a lot of other developers don't seem to agree.
And as for explicit types - I really wish people would stop trying to fight the type system - of Python, and of whatever other language. Python is not meant to support static types. It's not designed to reject your code at compile time for a type error and it isn't designed to take type information into account when generating bytecode. It's designed, instead, very explicitly, to let you care about what a given object can do, rather than about how it categorizes itself.
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.