My immediate response to this is: WTF.

Why not just do `l = len(x) if l is None else l`?

With the new syntax can you define defaults computed from other defaults? What about side effects? Why is computation happening in function args at all?!

Having the default value be None isn't great for documentation, and it isn't great for static typing, because now your argument has to be of type Union[Foo, None]. I've written functions where there are reasonably long chains of stuff like

if foo is None:

    foo = []

and it'd be nice to be done with that.

I see what you're saying about typing. As for the reasonably long chains of default initialization code. Well now its in the definition. You could have functions with more code defining the parameters than in body.

LWN had a good article on this: https://lwn.net/Articles/875441/

Short answer is these downsides were discussed but the proposal went ahead anyway.

Imo I'm with you. This type of syntax has a lot of implicit behavior where it's going to be difficult to find/fix bugs related to it.

That was a great article, thank you for the link!

> Why not just do `l = len(x) if l is None else l`?

Because dev tooling can “see” and present information from the argument list much more easily than analyzing downstream behavior.

> What about side effects?

Those happen whether or not the computation is visible in the signature (though its more obvious to the programmer of the consuming code if it is visible.)

I've never really seen arg1 depend on arg0 like that in Python.

However this comes up a lot for new engineers during programming interviews. It's very common to see recursive algos use empty lists as default/start-case args:

    def traverse(graph, seen_so_far=[]):  # Incorrect
        ....
        seen_so_far.append(node)

Subsequent calls to `traverse` will have state accumulated from earlier calls. The right solution is:

    def traverse(graph, seen_so_far=None):
        if not seen_so_far:
            seen_so_far = []
        .....

This isn't obvious if you're new to Python. This PEP makes this (arguably) clearer with:

    def traverse(graph, seen_so_far=>[]):

But how does => make it more obvious to someone who's new to python?

> This PEP makes this (arguably) clearer

It's more concise when you are familiar with it, and it improves introspection and dev tooling when functions use it, but it is not fundamentally clearer.

Oh my, that’s just terrible. Really hoping this pep wont make it all the way. 100% unreadable.

I’m not sure it’s unreadable to an experienced coder, someone learning the language though will be confused about the difference between = and => in the function argument definition.

Also the “arrow” is clearly pointing the wrong way, it should be “<=“.

It adds up. It's right that we have gotten used to all of the other stuff, but it adds up. It's fair to be very critical of new additions.

It's fair to be critical, but calling this flat out awful and unreadable is way overselling it. Whether it helps add up to something less readable than preferable is arguable, but taken on its own this change is minimally invasive and frankly pretty readable.

It seems perfectly readable to me, honestly. It might be confusing to newcomers, but I don't see a problem with it.