Red Huang

Red Huang

PEP 572爭議事件,以及個人對PEP 572 (Python 3.8) 的看法

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 also be written 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, like the following code:

if foo := bar(x):
    print(foo)

In short, it is a syntax method of "embedding assignment in an expression."

Conclusion#

With the above introduction, you should be able to 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 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 free-form writing and decreasing readability.

The positive side argues:

  • 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:

  • It does not adhere to the Zen of Python, but 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 see ":=" 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 team. Personally, I think this is unnecessary.

Until 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 feel so good. If everyone in the community can put themselves in the shoes of decision-makers and think about it, maybe they can promote and improve without being so radical, and this kind of consequence can be avoided.

載入中......
此文章數據所有權由區塊鏈加密技術和智能合約保障僅歸創作者所有。