Excuse me, what?

No, this is not the 2009 april fool prank. It’s true. Guido van Rossum has stepped down from his leadership role. It’s also true that his name should’ve been in the title, but he hasn’t had the recognition he deserves. I watched many of his interviews and thoroughly enjoyed his insightful anecdotes.

What is the matter with you?!

Why do old people argue? Do they really get grumpy with age? Or are we not yet wise enough to see things the way they do? How do we know? How do you know? I’ll paint the full picture and give you an unbiased corpus of a dataset. And see which way you lean with your deduction in comments.

GvR := Python

Guido van Rossum is one of the world’s most influential programmers. GvR is the author of the programming language Python, which he started working on in December 1989 as a Christmas project. Sweet Christmas!

He left his BDFL title over a PEP. And if you didn’t understand that, welcome to my world. I love discussing essential developments in Artificial Intelligence. Now, let me explain. By the reverence of his humble proponents, Mr. Rossum has been referred to as the Benevolent Dictator For Life.

Right, and what are PEPs?

The development of the Python language itself is managed through a series of documents called Python Enhancement Proposals, or PEPs.

Fun facts about PEPs

• One of the PEPs, called PEP 8, explains how you should format your code. It is PEP 8, which recommends we use 4 spaces for indentation. Top-level functions have two blank lines between them. This is conventional for modern Python code.

Readability counts, clarity matters, so readability makes for valuable code. In time, you’ll come to appreciate Python’s asseveration for whitespace by the elegance it brings to your code and the ease with which you can read others’.

• Documentation in Python uses a facility called docstrings. It helps add a self‑documenting capability to our own module. One Python convention for docstrings is documented in PEP 257, although it is not widely adopted.

• Ever wished you could make a script and trigger by just clicking on it? My favourite, PyLauncher was introduced with PEP 397.

Hence these PEPs are a big deal. They’re very important for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python.

Zen of Python

No, Devansh is not making this up. Zen is the word for Python’s philosophy.

Another one of these PEPs, called PEP 20, is called The Zen of Python. It refers to 20 aphorisms describing the guiding principles of Python, only 19 of which have been written down.

Conveniently, Python interpreter has an easter egg to access it from the REPL by typing:

import this

OK, so… The Dissension

The PEP 572 is a proposal for creating a way to assign a value to a variable and return it in the same line. An expression is something that gets evaluated. And this new construct will allow making an assignment within an expression, in Python 3.8 and later.

What did they name this divisive dilemma?

• Assignment Expressions (official technical term)
• Walrus operator (informal name)
• Named Expressions (wizards at CPython)

How does it work?

Now you can name and reuse the result of an expression in list comprehensions and other expression contexts using the notation NAME := expr.

1. Regular Expression (RegEx) Match

# Python <3.8
res = re.match(...)
if res:
    print(res.group(0))
# Python 3.8+
if (res := re.match(...)):
    print(res.group(0))

2. Reading files

# Python <3.8
with open(...) as f:
    while True:
        chunk = f.read(8192)
        if not chunk:
            break
        process(chunk)
# Python 3.8+
with open(...) as f:
    while chunk := f.read(8192):
        process(chunk)

3. Share a subexpression between a comprehension filter clause and its output

[y for x in data if (y := f(x)) is not None)

4. Reuse a value that’s expensive to compute

[y := f(x), y**2, y**3]

How does it NOT work?

1. Top-level of an expression statement

y := f(x) # INVALID
(y := f(x)) # Valid, though not recommended

2. Top-level of the right-hand side of an assignment statement

y0 = y1 := f(x)  # INVALID
y0 = (y1 := f(x))  # Valid, though discouraged

3. Value of a keyword argument

foo(x = y := f(x))  # INVALID
foo(x=(y := f(x)))  # Valid, though probably confusing

4. Top-level of a function default value

def foo(answer = p := 42):  # INVALID
    ...
def foo(answer=(p := 42)):  # Valid, though not great style
    ...

5. Annotations for arguments, return values and assignments

def foo(answer: p := 42 = 5):  # INVALID
    ...
def foo(answer: (p := 42) = 5):  # Valid, but probably never useful
    ...

6. In lambda functions

(lambda: x := 1) # INVALID
lambda: (x := 1) # Valid, but unlikely to be useful
(x := lambda: 1) # Valid
lambda line: (m := re.match(pattern, line)) and m.group(1) # Valid

7. In f-strings without parentheses

>>> f'{(x:=10)}'  # Valid, uses assignment expression
'10'
>>> x = 10
>>> f'{x:=10}'    # Valid, passes '=10' to formatter
'        10'

… And that is not even all of it. There are so many exceptions and ambiguous cases. I have read the whole PEP as well as code improvements in the standard library; even the essay from Tim Peters. I realised how nasty this must have been for Lord G.

Zen conflicts

1. There should be only one obvious way to do something

Now you have two or more ways to do all the things mentioned earlier that are technically valid, but discouraged because they can cause confusion, and make code less readable

2. Simple is better than complex

This new operator adds complexity in the name of reducing whitespace. We keep this up and one can end up with code so obfuscated that it will look encrypted cyber graphics like in the depiction of hacking in old movies.

My take on Over Engineering and feature overload

Python is loved for its simplicity and readability. I can’t imagine learning this operator and all its exceptions in a course when learning Python for the first time. Granted, it helps in some cases. Like removing the need of refactoring code when debugging those Heisenbugs. But would you consider this an essential feature?

This is no different than boilerplate “hello world” of Java or C++, being so complicated that you give up; or as Guido likes to put it, get damaged for life.

I’m afraid this will be the case when we need to learn one more operator before being able to read someone’s code. And next thing you know, Python is PHP. And if you didn’t understand that, welcome to my app. This is not where I explain to you why PHP is a fractal of bad design. But to put it in perspective, Perl is “some assembly required”. Python is “batteries included”. PHP is “kitchen sink, but it’s from Canada and both faucets are labelled C.”

The Culinary Analogy

Is the walrus operator a banana slicer?

When I was starting to learn cooking, I started, of course, at the Wiki page of kitchen utensils. And I came across the case of “Labour-saving” utensils generating more labour. The start of the 20th century saw an explosion in patented “labour-saving” devices for the modern kitchen.

The best way for the housewife to peel a potato, for example, is in the old-fashioned way, with a knife, and not with a patented potato peeler.

James Frank Breazeale

The “labour-saving” devices raised expectations of what families would eat. So even though the food got easier to cook, ordinary householders were expected to cook harder-to-prepare meals on a regular basis. The labour-saving effect of the tools was cancelled out by the increased labour required for what came to be expected as the culinary norm in the average household.

The most useful kitchen utensils were the simple little inexpensive conveniences that work themselves into everyday use.

What now?

To me, the walrus operator represents more than just assignment expressions. It represents the power of leadership to break through a toxic stalemate. To me, it represents the importance of leadership in a community of smart people that disagree.

Lex Fridman

The walrus operator (:=) is probably the most controversial feature in Python. It can polarize developers. One of the teams I have worked with sticks with 3.7. Will there be a divide like a hard fork? Will there be debates? Sure. But you’re in a safe haven from that cold war, lest you comment on this post.

If you must seek refuge, however, the form presented in Google’s Python Style Guide is amenable to being machine parsed while still remaining readable at the console.

Python is at the centre of a cultural movement. Its community has core values, best practices and philosophy. And you should stay in the known by keeping tabs on the PEPs.

Governance as a Situation

I connected the dots, recalling a talk by Linus Torvalds (creator of Linux) and realised that I admired him and his efforts a lot. So I started researching their code of conduct and the attitude of Linus for leading in the middle of such contentious situations, only to realize that – that house has trouble in paradise much worse than the Python Asgard here.

To quote the benevolent boomer, Democracy? Anarchy? Dictatorship? Federation?

He is right. This walrus wrangle is nothing compared to the numerous governance models mulled over a million times in the following proposals.

• PyPA Governance (different from the Python Language Governance Model)
• The Steering Council Model (after elections of 2019 January and December)
• The Technical Leader Governance Model (Rejected)
• Python Governance Model Lead by Trio of Pythonistas (Rejected)
• The Community Governance Model (Rejected)
• The External Council Governance Model (Rejected)
• The Commons Governance Model (Rejected)
• Organization of the Python community (Rejected)

You can understand the voting process and check out the Open Source Governance Survey that details approaches of Rust, OpenStack, Jupyter, Django, TypeScript, AstroPy; even Microsoft!

This goes deeper. But feel free to participate in the conversation here.

Summary by a CPython core developer

One of the key points is that it has been proven you can’t have a voting system that doesn’t have at least one of these properties:

• The system is dictatorial
• The system is rigged against one of the candidates
• The system is not strategy-proof

Since the first two properties are highly-undesirable, we are left to choose between systems that minimize the amount of strategy (i.e. minimize insincere voting). The 3-2-1 system has been specifically designed to minimize strategic voting and according to vote simulations does a good job at it.

Neil Schemenauer

The End?

This has been a long read, and if you got until here, I’ll see you in the comments. Let me know if you liked the decision. And definitely call me if your heart broke over the beginning of the end of King G’s reign.