3 ms·

Personally I consider 3.2 to be the first usable version of Python 3, though that obviously already had a very large and complex data and language model. New i

Personally I consider 3.2 to be the first usable version of Python 3, though that obviously already had a very large and complex data and language model. New in 3.3: - yield from: I'm okay with this - PEP 420 / namespace packages: I think this is/was the best compromise, but this remains a fundamentally ugly topic for something that is sort-of necessary to have - raise from None: This is okay for library code - __qualname__: It's a mess. It's not like I'm against having it, but this is a corner of the language that practically invites you to hang yourself one way or another. - importlib: It's better than the previous iteration but this package was and still is a mess. Again, lots of this is due to legacy aka "the other packaging packages". New in 3.4 - asyncio beta (no coroutine syntax yet): While coroutines are highly useful, asyncio and Python coroutines simply are not good. This is the beginning of the badness. - pathlib: Ok! - enum: Ok! New in 3.5 - async def, await: This is the release that really set colored functions in stone for Python. - "@" operator: I've never used this once I think, but that's because I don't write math code in Python. If I did, I think I'd like it, so I'm okay with this. - type hints: Another oof moment New in 3.6 - f-strings: Yay! - dict now ordered: Yay! - async generators and such: Again, I think colored functions are a big blunder, but if you have them, you need this. - Variable annotations New in 3.7 - PEP 563: Type annotations can be turned into quoted annotations without a syntactic change through __future__ import. - contextvars: "thread-locals for coroutines" - PEP 562: Added the Python 2 misfeature back where Python 2 interpreted __get__ and __set__ on modules - Typing becomes part of the core language, I think this is when you could start writing things like "list[int]" (instead of "typing.List[int]"). New in 3.8 - := Yuck - "Positional-only parameters" because the simplified CPython API for defining functions has this, so ... Python code needs that as well? Wot? - More typing New in 3.9 - More typing New in 3.10 - And even more typing - Pattern matching

jerf 5y ago
"I'm okay with this" I pulled this out of your post because it's something I think about a lot of the individual changes. Individually, they generally make sense. It's just that the sum total of all the individual sensible things is a large mess, getting larger every release. I first used Python in the 20th century, and have clocked many thousands of hours with it overall. Now I mostly program in Go. (Actually, even after ~7 years part-time professional with Go, I'm not sure which I've used more yet! I may still technically have more time with Python. If I do, though, I'm close to the crossover.) Occasionally, I miss iterators, and with Go getting generics it's probably my #1 ask in Go. Other than that, though... I just can't help but notice that I don't actually miss that many features of Python very often. I miss Haskell features, I sometimes miss Rust features, every once in a while I'll miss something more exotic like an Erlang feature, but I almost never think "gee, I really miss this Python feature". It isn't that I can't see where I'd use them if they exist, I just don't sit there pining for them all the time. I consider this a big data point. I should also point out I'm talking about subconscious inclinations, it's not like I'm setting out and daily disciplining myself to not miss Python features. It's just a thing that happens or doesn't. YMMV. I'm probably more often grateful for a missing Python feature than I'm missing it (e.g., it's actually kinda nice after a certain scale to know what "x.y" does, rather than have to go resolving down an arbitrarily-complicated chain of classes, inheritance, method overrides, etc.).
cuteboy19 5y ago
its quite fun to see python api generated from C/C++ libraries. They always go ham on the type specification, making the resulting code unrecognizable as Python.

jerf 5y ago

"I'm okay with this" I pulled this out of your post because it's something I think about a lot of the individual changes. Individually, they generally make sense. It's just that the sum total of all the individual sensible things is a large mess, getting larger every release. I first used Python in the 20th century, and have clocked many thousands of hours with it overall. Now I mostly program in Go. (Actually, even after ~7 years part-time professional with Go, I'm not sure which I've used more yet! I may still technically have more time with Python. If I do, though, I'm close to the crossover.) Occasionally, I miss iterators, and with Go getting generics it's probably my #1 ask in Go. Other than that, though... I just can't help but notice that I don't actually miss that many features of Python very often. I miss Haskell features, I sometimes miss Rust features, every once in a while I'll miss something more exotic like an Erlang feature, but I almost never think "gee, I really miss this Python feature". It isn't that I can't see where I'd use them if they exist, I just don't sit there pining for them all the time. I consider this a big data point. I should also point out I'm talking about subconscious inclinations, it's not like I'm setting out and daily disciplining myself to not miss Python features. It's just a thing that happens or doesn't. YMMV. I'm probably more often grateful for a missing Python feature than I'm missing it (e.g., it's actually kinda nice after a certain scale to know what "x.y" does, rather than have to go resolving down an arbitrarily-complicated chain of classes, inheritance, method overrides, etc.).

cuteboy19 5y ago

its quite fun to see python api generated from C/C++ libraries. They always go ham on the type specification, making the resulting code unrecognizable as Python.