Summary#
PEP 572 is a feature in Python 3.8 called Assignment Expressions.
Recently, this syntax has caused quite a stir in the Python community. Let me explain what this change is about.
First, let's take a look at the introduction in PEP 572:
In most contexts where arbitrary Python expressions can be used, a named expression can appear. This is of the form NAME := expr where expr is any valid Python expression other than an unparenthesized tuple, and NAME is an identifier.
Here are some examples:
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 usage does not limit the position of variables, as shown below:
def foo(answer = p := 42): # INVALID
...
def foo(answer=(p := 42)): # Valid, though not great style
...
So, of course, it can be done like this:
def foo(answer: p := 42 = 5): # INVALID
...
def foo(answer: (p := 42) = 5): # Valid, but probably never useful
This opens up a hole in the code, and we can predict that this kind of writing will soon appear in various projects.
For example:
if foo := bar(x):
print(foo)
In short, it is a syntax method of "embedding assignment in an expression."
Conclusion#
The above introduction should help you understand its purpose. Although I personally support this writing style as it makes things more convenient, the focus is not on convenience but on the "complexity" of the syntax.
For beginners who have just started learning Python, it is highly likely that they will confuse the correct usage of Assignment Expressions.
Because of this, a battle of opinions has begun. Some people agree with Guido's approval of this sudden feature, while others criticize Python's syntax for not being strictly controlled, resulting in increasingly free-form and less readable code.
The affirmative side argues:
- Just like the f-string feature, everyone's vision is not far enough. This is helpful for the future, etc.
- Isn't this method commonly used in C++?
The opposing side argues:
- It does not adhere to the Zen of Python, although the author of the Zen of Python does not consider it a big problem.
- The scope of this syntax should be significantly limited to maintain simplicity.
- The general public tends to view ":=" as a definition, not an assignment.
Of course, these comments can all evolve into dissatisfaction from the "benevolent dictator" Guido, which could lead to his resignation from the Python decision-making team. Personally, I think this is unnecessary.
Up to now, it is not so clear who is right or wrong. It seems that the community has provided some constructive suggestions, but Guido couldn't swallow his pride and stepped down with a bow. Although the Python community is already very large, this will still affect the speed of Python's development.
I think if you are in a position to promote a feature and receive criticism and backlash from every member of the community, it may not be easy. If everyone in the community can put themselves in the shoes of the decision-makers and think about it, perhaps they can promote and improve without using such radical language, thus avoiding such consequences.