Summary#
PEP 572 is a feature in Python 3.8 (Assignment Expressions).
This Assignment Expressions syntax has recently caused a lot of controversy in the Python community. Let me explain what this change is.
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 restrict 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 also 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 there will definitely be some terrifying code appearing in various projects soon.
As shown in the following code, we can already predict that this kind of writing will emerge in various projects in the near future:
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 can be very 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 this Assignment Expressions.
Because of this, the battle of opinions has begun. Some people express their support for Guido's agreement on this sudden feature, while others criticize Python's syntax for not being strictly controlled, resulting in increasingly loose writing styles and decreasing readability.
The affirmative side argues that:
- Just like the f-string feature, people are not looking far enough. This is helpful for the future, etc.
- Isn't this method commonly used in C++?
The negative side argues that:
- 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 consider ":=" as a definition, not an assignment.
Of course, these comments can all evolve into dissatisfaction from the "benevolent dictator" Guido, leading to his resignation from the Python decision-making level. Personally, I think this is unnecessary.
Up until now, it is not so clear who is right and who is 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 everyone in the community, it doesn't feel so good. If everyone in the community can put themselves in the shoes of the decision-makers and think about it, maybe they can promote and improve without using such radical language, and avoid such consequences.