The language has been literally 'evolving' since the version that many of us have begun (maybe since the initial day, if you are Guido). I'm not talking about any features in specific, but rather the whole language. If you compare a code fragment that you wrote 5 years ago, with the 'refactored' version that you would write if it were today the difference is obvious.
We've seen a lot of new syntax popping into our lives, in just the last 5 years (starting from 3.5):
>>> *range(4), 4
(0, 1, 2, 3, 4)
>>> [*range(4), 4]
[0, 1, 2, 3, 4]
>>> {*range(4), 4}
{0, 1, 2, 3, 4}
>>> {'x': 1, **{'y': 2}}
{'x': 1, 'y': 2}
- PEP 465, a.k.a matrix operator
S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)
- PEP 492, a.k.a native async syntax
async def commit(session, data):
...
async with session.transaction():
...
await session.update(data)
...
- PEP 498, a.k.a f-strings
>>> f'The value is {value}.'
'The value is 80.'
primes: List[int] = []
captain: str # Note: no initial value!
class Starship:
stats: ClassVar[Dict[str, int]] = {}
def add(x, y, /):
return x + y
- PEP 572, a.k.a walrus
# Handle a matched regex
if (match := pattern.search(data)) is not None:
# Do something with match
# A loop that can't be trivially rewritten using 2-arg iter()
while chunk := file.read(8192):
process(chunk)
# Reuse a value that's expensive to compute
[y := f(x), y**2, y**3]
This huge list contains some of the (major~) changes that have been implemented since 3.5, there
are also quite a few minor ones (like _ separator for numbers, 1_000_00 or PEP 530
for async comprehensions or even a new one for 3.9 to extend the decorator syntax, PEP 614.)
Well, since we all refreshed our memories, let's try to imagine a world where these features don't exist. Imagine not having access to f-strings, writing weird stuff to deal with your coroutines, or repeating yourself 2 times whenever you want to read chunks from a file, writing utility functions to merge 2 mappings and more awful cases. Except for maybe PEP 465 (I never needed it, probably because I don't do scientific programming. But from what I saw by looking at the examples in the PEP, it is quite good for people who work with data on a daily basis.) every feature in that list literally changed and actively affected how I write my Python code, right now.
Seems like syntactical additions sounds great, why don't we add everything to the language? Let's start with adding regex literals, and then move forward to call pipeline operator, blah blah blah. If you are subscribed to the Python-ideas, then get ready to see tons of different, redundant new syntax proposals (even I, probably proposed a couple of very obscure and stupid ideas in the past). Though this brings me back to the point of, whether we should stop the syntactical growth at all or not.
In the last 6 month, 3 different major syntax changes were proposed. I guess everyone is somewhat familiar
with the pattern matching PEPs, PEP 622 (PEP 634, PEP 635, PEP 636). Also, there is PEP 637 for allowing keyword arguments
on the subscript syntax [x=y, z=q] and PEP 638, for syntactic macros. I am not going to criticize any of these PEPs, but
I'd like to ask you to think about them. Think of how they could affect you in 5 years. Think about whether your
coding styles would change because of them, think about how good fit they are to the language, and most importantly think about
whether you 'ACTUALLY' need them. Is there any 'ESSENTIAL' case that would be much better when you pass keyword arguments through
slices instead of just making a call to some sort of get() function? Or can't we have syntactical customization without having an
official definition of it? Does the syntax for 'patterns' (described by PEP 634) is a good fit for the Python language?
There are a lot of blog posts, polls and maybe hundreds of emails out there related to these proposals. I won't expect anyone to read them all, but if you want to get a general idea just check some of them out.
Have to say that, I'm extremely overwhelmed by seeing this amount of change proposals every day, in various places. No one is forcing me to read them, though it is just a burden that I am intentionally or unintentionally taking to see what are people looking for in the language that I (myself) probably will be stuck with for the next decade. Trying to comprehend what people are aiming with making language so complex with growing the syntax more and more every day.
Don't forget that adding syntax is much more serious than adding a functionality to the runtime. That syntax will be the face of the language, and you won't be able to alter it even a little bit. We all saw what happened when the syntax was changed in a backwards-incompatible manner, and no one wants to go through that again. This is why I am just asking you to think about whether do you believe these would be good fits for the language, whether they will worth to their imponderable cost.
This is just me, throwing a bunch of questions into the void. If you want to talk more about these, feel free to send me an email (batuhan [at] python [dot] org) or reach me through twitter (open DM for all, @isidentical).