[Python-Dev] PEP 572: Assignment Expressions (original) (raw)

Mark Shannon mark at hotpy.org
Mon Apr 30 10:30:54 EDT 2018

Hi,

On 17/04/18 08:46, Chris Angelico wrote:

Having survived four rounds in the boxing ring at python-ideas, PEP 572 is now ready to enter the arena of python-dev.

I'm very strongly opposed to this PEP.

Would Python be better with two subtly different assignment operators? The answer of "no" seems self evident to me.

Do we need an assignment expression at all (regardless of the chosen operator)? I think we do not. Assignment is clear at the moment largely because of the context; it can only occur at the statement level. Consequently, assignment and keyword arguments are never confused despite have the same form name = expr

List comprehensions

The PEP uses the term "simplifying" when it really means "shortening". One example is stuff = [[y := f(x), x/y] for x in range(5)] as a simplification of stuff = [(lambda y: [y,x/y])(f(x)) for x in range(5)]

IMO, the "simplest" form of the above is the named helper function.

def meaningful_name(x): t = f(x) return t, x/t

[meaningful_name(i) for i in range(5)]

Is longer, but much simpler to understand.

I am also concerned that the ability to put assignments anywhere allows weirdnesses like these:

try: ... except (x := Exception) as x: ...

with (x: = open(...)) as x: ...

def do_things(fire_missiles=False, plant_flowers=False): ... do_things(plant_flowers:=True) # whoops!

It is easy to say "don't do that", but why allow it in the first place?

Cheers, Mark.

More information about the Python-Dev mailing list