Guido on Permanent Vacation from BDFL

[ichabod801]

python.org/msg05628.html" target="_blank" rel="noopener" class="mycode_url">https://www.mail-archive.com/python-comm...05628.html

[metulburr]

interesting

[ichabod801]

But here's the catch. I'm going to try and let you all (the current committers) figure it out for yourselves.

This could get very interesting indeed.

[micseydel]

Wow. Interesting PEP as well.

[snippsat]

Thank you Guido

I have followed/looked at some of the mails reading PEP,and it's a long grinding process.
Have to spend a lot time argument back and forth.
So steeping back from this prosess is understandably.

Python will be fine as the Bus factor is no longer problem for Python.

[DeaD_EyE]

I understand him.
Thank you for your time. :-)

I read the PEP 572. My first reaction was that this looks like assignment in Pascal.
But as I saw the examples, I was impressed.

if pid := os.fork():
    # Parent code
else:
    # Child code

So with this code, the return value of os.fork() is first assigned to the name pid, then the if-statement will be executed with pid.
Doing evaluation and branching with one line code is very handy.

[Larz60+]

I am looking forward to seeing what you invent next!
Python has been a gift to the world, Thank You

[nilamo]

I understand him.
Thank you for your time. :-)

I read the PEP 572. My first reaction was that this looks like assignment in Pascal.
But as I saw the examples, I was impressed.

if pid := os.fork():
    # Parent code
else:
    # Child code

So with this code, the return value of os.fork() is first assigned to the name pid, then the if-statement will be executed with pid.
Doing evaluation and branching with one line code is very handy.

I looked at the pep, and was surprised that GvR was in support of it. I was under the impression that the rule about assignment not possible in expressions was one of his original purposes in Python, as having too many things in one line can get convoluted quickly.

[micseydel]

I looked at the pep, and was surprised that GvR was in support of it. I was under the impression that the rule about assignment not possible in expressions was one of his original purposes in Python, as having too many things in one line can get convoluted quickly.

Yeah, I was surprised too. I think having the assignment expression use a different operator from assignment statements helps, as do examples like this

if reductor := dispatch_table.get(cls):
    rv = reductor(x)
elif reductor := getattr(x, "__reduce_ex__", None):
    rv = reductor(4)
elif reductor := getattr(x, "__reduce__", None):
    rv = reductor()
else:
    raise Error("un(deep)copyable object of type %s" % cls)

[DeaD_EyE]

I looked at the pep, and was surprised that GvR was in support of it. I was under the impression that the rule about assignment not possible in expressions was one of his original purposes in Python, as having too many things in one line can get convoluted quickly.

Oh yes. Opinions can change. Language design is very opinionated.
My first surprise was, as he came with Type Hinting.
But if you use them at the right place, you'll benefit.
Using Type Hints everywhere doesn't look nice.