5 ms·

While I like all these proposed changes individually and PEPs are always well intentioned, my concern is the the Python syntax is getting too “big”. Pythons ma

While I like all these proposed changes individually and PEPs are always well intentioned, my concern is the the Python syntax is getting too “big”. Pythons massive advantage and the reason it’s so successful is it’s simplicity. Adding syntactic features only adds more surface area for people to learn when coming to the language and barriers to entry for people looking to contribute to an unfamiliar codebase. There are a few over the last few years I truly love, such as “f strings”, the typing syntax though I’m less convinced by (and I really like TypeScript). The recently added “walrus operator” is a good example of a syntactic addition that is both brilliant for experienced Python coders but also adds friction to new people learning the language. It’s presence in a codebase could confuse people. Python is supposed to “favour explicit over implicit” and has always been more “wordy”, symbol based operators that aren’t inherently explicit in their meaning (like this proposed =>) are the type I’m particularly worried about. Edit: I just want to add, I don’t think these additions “damage” the language, it’s just the additional friction for people to pick it up or approach an unfamiliar codebase that worries me (maybe unduly). I love Python and these don’t put me off wanting to continue to use it as my primary language. In many ways I look forward to using them as an experienced Python developer.

gabythenerd 5y ago
I completely agree, one of the advantages of python is that it reads like pseudo-code for people not familiar with the language. Some of the proposed syntax changes are not that intuitive and require knowing how they work beforehand.
- BiteCode_dev 5y ago
  There were already a lot of features like that: - context manager - decorators - inline conditions - else keywords in loops, which nobody knows even exist. - raise from (empty, or with params). - yield from (espacially with send()) - comprehension lists - advanced unpacking. This is valid: (a, (b, *c)) = [1, {*range(4)}] - advanced slicing. This is valid: foo[2:8:2] = bar[:4] Most of which existed in Python 2 already ! But it has never been a problem before. Why ? Because the community doesn't abuse features, it's part of the creed. But also because half of the python coders don't even know they exist (they are just trying to solve their problem, but dev is not their job), and are productive without it, so they just don't use it. In fact, a lot of tutorials on the internet never even mention those. Since the walrus came out, I used it once, and never saw it on a client code base. But when the community do use the features, they usually make things better: decorators made flask/click what it is, slicing made numpy/pandas what it is, type hints made fastapi/pydantic what they are. Those worries are mostly that: worries. They don't reflect what happens in practice.
  - ahoka 5y ago
    I wanted to joke about still waiting for COME FROM to be added to Python, then I found it that someone already did that...
  - popularonion 5y ago
    You are right. Let's be real, if you're teaching Python to kids and bootcampers, you're going to only cover a little bit of what's in Python 2, and that's fine. The other stuff is mostly designed by framework authors to by used by framework authors. And having nice libraries and frameworks is what really makes this language so useful for everyone. It's trendy to claim Python is meant to be some kind of "pure environment" where the source code of Flask or SQLAlchemy or NumPy should just like a tutorial, but Python has never been that in the 10+ years I've been getting paid to use it. I thought that was the aspiration of Go. As far as I could tell, Hacker News commenters hated Go and now it's mostly ignored and forgotten here.
est 5y ago
Also: there used to be one and best way to do a thing. Now there's multiple ways to do a half-assed job.
- ciupicri 5y ago
  Could you give some examples?
- mrtranscendence 5y ago
  There's always been more than one effective way to do things in Python. The contention otherwise is just some rosy thinking. Heck, decorators were introduced almost 20 years ago and they're basically just additional syntax for def foo(): return "hi" foo = my_decorator(foo) Similarly for context managers and many other features. We can go back much farther than that even: why have lists and tuples, when they're basically interchangeable in most cases? Why have list comprehensions when a loop does the job just fine and might arguably be clearer?
jerf 5y ago
Python probably passed that point about 10 years ago. I'm not trying to be cynical, I've thought this for a while. At this point, I just wish the best to Python's new features because the language is well past "simple" and it's been many years since that was a thing that was even possible to save. I've watched new and inexperienced programmers trying to learn full, modern Python up close and personal. (That is, they were trying to get into real code bases that were using the many features in Python, not that we were in a teaching space incrementally introducing things.) Anyone who has done that in the last ten years knows it's not simple anymore.
- formerly_proven 5y ago
  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
alexaholic 5y ago
The walrus operator, the `match` statement, the f-strings etc. these seem like just syntactic sugar. Also note the type hints are optional. So these changes are opt in: you can still write the Python of yesterday. But, if you can afford to take it up a notch, you can write the Python of today. I don't see Python getting harder for the newcomers, instead I find it getting better for the ones who have invested deeply into it, and I quite enjoy it.
- chriswarbo 5y ago
  > these changes are opt in Only for personal projects, with no outside contributors, no external dependencies, etc. If you want to read someone else's code, e.g. to learn more, or see how one of your dependencies works, etc. then you may need to face these features. If you want to allow external contributions to your project, then you'll have to face these features (even if that just means an informal coding standard that says "don't use XYZ"). If you want to work more closely/collaboratively with others, e.g. in an organisation, then you'll have to face these features (even if it's just a discussion about whether to allow them). If you want to write tooling for the language, e.g. parsers, doc generators, linters, formatters, diffing tool, etc. then you'll need to face them. Finally, if you're writing library code that's intended for use by others, you need to be aware of such language features, in case they break any of your assumptions. For example, a library might rely on the fact that lambdas can't re-bind variables (they can mutate the content of an object, but they can't change the reference, since '=' is a statement rather than an expression); the introduction of ':=' expressions violates that assumption.
  - popularonion 5y ago
    In the real world, I'm still nagging people to use docstrings and type hints. It is really not my experience that people read PEPs and try to shoehorn in language tricks they don't need into their random scripts at $DAYJOB. I would actually be thrilled to see a walrus operator show up in a PR from one of my coworkers. But I'd have to shoot it down because we need to be compatible with 3.6.
- anhner 5y ago
KptMarchewa 5y ago
>Pythons massive advantage and the reason it’s so successful is it’s simplicity. Yet, if you use it more than few years, you see how it's just a disguise. Underneath superficial simplicity there's ton of leaking abstractions, semantics which designers designed themself into the corner, and gigantic C API that blocks any performance improvements.
- N1H1L 5y ago
  Yes. And currently it has also split into several sub-languages almost now. Numpy/Scipy is one, then there is enterprise Python, and the ML Python has its own conventions. That's how big and complex Python today is.
agumonkey 5y ago
while dynlang add more syntax and types, static verbose ones are trimming them off, isn't that curious :)

gabythenerd 5y ago

I completely agree, one of the advantages of python is that it reads like pseudo-code for people not familiar with the language. Some of the proposed syntax changes are not that intuitive and require knowing how they work beforehand.

BiteCode_dev 5y ago
There were already a lot of features like that: - context manager - decorators - inline conditions - else keywords in loops, which nobody knows even exist. - raise from (empty, or with params). - yield from (espacially with send()) - comprehension lists - advanced unpacking. This is valid: (a, (b, *c)) = [1, {*range(4)}] - advanced slicing. This is valid: foo[2:8:2] = bar[:4] Most of which existed in Python 2 already ! But it has never been a problem before. Why ? Because the community doesn't abuse features, it's part of the creed. But also because half of the python coders don't even know they exist (they are just trying to solve their problem, but dev is not their job), and are productive without it, so they just don't use it. In fact, a lot of tutorials on the internet never even mention those. Since the walrus came out, I used it once, and never saw it on a client code base. But when the community do use the features, they usually make things better: decorators made flask/click what it is, slicing made numpy/pandas what it is, type hints made fastapi/pydantic what they are. Those worries are mostly that: worries. They don't reflect what happens in practice.
- ahoka 5y ago
  I wanted to joke about still waiting for COME FROM to be added to Python, then I found it that someone already did that...
- popularonion 5y ago
  You are right. Let's be real, if you're teaching Python to kids and bootcampers, you're going to only cover a little bit of what's in Python 2, and that's fine. The other stuff is mostly designed by framework authors to by used by framework authors. And having nice libraries and frameworks is what really makes this language so useful for everyone. It's trendy to claim Python is meant to be some kind of "pure environment" where the source code of Flask or SQLAlchemy or NumPy should just like a tutorial, but Python has never been that in the 10+ years I've been getting paid to use it. I thought that was the aspiration of Go. As far as I could tell, Hacker News commenters hated Go and now it's mostly ignored and forgotten here.

est 5y ago

Also: there used to be one and best way to do a thing. Now there's multiple ways to do a half-assed job.

ciupicri 5y ago
Could you give some examples?
mrtranscendence 5y ago
There's always been more than one effective way to do things in Python. The contention otherwise is just some rosy thinking. Heck, decorators were introduced almost 20 years ago and they're basically just additional syntax for def foo(): return "hi" foo = my_decorator(foo) Similarly for context managers and many other features. We can go back much farther than that even: why have lists and tuples, when they're basically interchangeable in most cases? Why have list comprehensions when a loop does the job just fine and might arguably be clearer?

jerf 5y ago

Python probably passed that point about 10 years ago. I'm not trying to be cynical, I've thought this for a while. At this point, I just wish the best to Python's new features because the language is well past "simple" and it's been many years since that was a thing that was even possible to save. I've watched new and inexperienced programmers trying to learn full, modern Python up close and personal. (That is, they were trying to get into real code bases that were using the many features in Python, not that we were in a teaching space incrementally introducing things.) Anyone who has done that in the last ten years knows it's not simple anymore.

formerly_proven 5y ago
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

alexaholic 5y ago

The walrus operator, the `match` statement, the f-strings etc. these seem like just syntactic sugar. Also note the type hints are optional. So these changes are opt in: you can still write the Python of yesterday. But, if you can afford to take it up a notch, you can write the Python of today. I don't see Python getting harder for the newcomers, instead I find it getting better for the ones who have invested deeply into it, and I quite enjoy it.

chriswarbo 5y ago
> these changes are opt in Only for personal projects, with no outside contributors, no external dependencies, etc. If you want to read someone else's code, e.g. to learn more, or see how one of your dependencies works, etc. then you may need to face these features. If you want to allow external contributions to your project, then you'll have to face these features (even if that just means an informal coding standard that says "don't use XYZ"). If you want to work more closely/collaboratively with others, e.g. in an organisation, then you'll have to face these features (even if it's just a discussion about whether to allow them). If you want to write tooling for the language, e.g. parsers, doc generators, linters, formatters, diffing tool, etc. then you'll need to face them. Finally, if you're writing library code that's intended for use by others, you need to be aware of such language features, in case they break any of your assumptions. For example, a library might rely on the fact that lambdas can't re-bind variables (they can mutate the content of an object, but they can't change the reference, since '=' is a statement rather than an expression); the introduction of ':=' expressions violates that assumption.
- popularonion 5y ago
  In the real world, I'm still nagging people to use docstrings and type hints. It is really not my experience that people read PEPs and try to shoehorn in language tricks they don't need into their random scripts at $DAYJOB. I would actually be thrilled to see a walrus operator show up in a PR from one of my coworkers. But I'd have to shoot it down because we need to be compatible with 3.6.
anhner 5y ago

KptMarchewa 5y ago

>Pythons massive advantage and the reason it’s so successful is it’s simplicity. Yet, if you use it more than few years, you see how it's just a disguise. Underneath superficial simplicity there's ton of leaking abstractions, semantics which designers designed themself into the corner, and gigantic C API that blocks any performance improvements.

N1H1L 5y ago
Yes. And currently it has also split into several sub-languages almost now. Numpy/Scipy is one, then there is enterprise Python, and the ML Python has its own conventions. That's how big and complex Python today is.

agumonkey 5y ago

while dynlang add more syntax and types, static verbose ones are trimming them off, isn't that curious :)