PEP 572: Python assignment expressions has been accepted

I'm a huge Python fanboy and I've been so happy to be able to use it professionally for the last decade or so, but I think the BDFL may have lost his touch. Or he just doesn't care anymore. If I hadn't already decided to stick to Python 2 (likely in the form of the Tauthon project, but there are lots of Python 2 runtimes out there. Lots. (Everybody always forgets about Stackless, for example)), I say, if I hadn't already decided to stick to Python 2, this would be the camel-back-breaking straw. We're trucking in footguns from C now?

These examples in the PEP, they all seem bad to me, written to be too clever by someone who doesn't think well.

E.g.:

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

How about:

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

Or just?

    filtered_data = filter(None, map(f, data))

(If f() can return non-None "Falsey" values then this would require a predicate function. But maybe f() is badly designed?)

Or this:

    if any(len(longline := line) >= 100 for line in lines):
        print("Extremely long line:", longline)

What's wrong with the "old-fashioned" way?

    for line in lines:
        if len(line) >= 100:
            print("Extremely long line:", line)
            break

Of course, in the bad old days when loop variables leaked I think you could just write:

    if any(len(line) >= 100 for line in lines):
        print("Extremely long line:", line)

But I'm not sure, and in any event leaking loop vars was fixed at some point. (Good. It was useful but bug-prone. Just like this PEP!)

To me this is also a mess:

    results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

It should be:

    results = [(x, y, x / y) for x, y in zip(input_data, map(f, input_data)) if y > 0]

Maybe all the examples are just poorly chosen, but I don't believe that. I think this PEP is just a bad idea. Badly bad.

> But I'm not sure, and in any event leaking loop vars was fixed at some point. (Good. It was useful but bug-prone. Just like this PEP!)

So, basically, they have a proposal for an expression that explicitly says "I want to leak this variable into the enclosing scope" and it is less useful than the implicit old way?

Python's variable scoping rules are a mess anyway -- some are function level, some are block level and I usually can't tell which is which until the compiler complains...

Local -> Enclosing -> Global -> Builtin

I use Python the most so maybe I'm just used to it but I always found scoping pretty straightforward.

Do you have an example that you found surprising?

> So, basically, they have a proposal for an expression that explicitly says "I want to leak this variable into the enclosing scope" and it is less useful than the implicit old way?

Goddamnit, I think you just changed my mind. :-)

Mostly I can't remember if a variable escapes from an if-else block, context manager, &etc until I start playing around with the code.

In C it's 100% clear, variables only live inside their respective blocks so if you want to mess with the value in an if-else you have to declare it outside of the block.