Guido on Permanent Vacation from BDFL

[micseydel]

One of the things I like about type hinting is that you can add the hints, do a bunch of refactoring, and then remove them. They can give you a very nice guard rail. Haven't seen it yet, but I also suspect they'll be great when publishing libraries.

[nilamo]

Does type hinting still count as type hinting if you put arbitrary descriptions in?

def do_stuff_with(things: ["list of strings"]) -> "bool or None, depending on args":
    return True if things else None

[micseydel]

Not sure how much that was tongue-in-cheek buuut... annotations were a feature before core Python was considering type hinting. So you could totally do that, but I wouldn't call it type hinting, since it's not programmatically readable. But you could do

from typing import List, Option

def do_stuff_with(things: List[str]) -> Option[bool]:

with a docstring explaining the relationships between the args and the return value.

[Skaperen]

were people more upset over an assignment as an expression or the use of := which the lack of in Python was one of my many reasons for choosing Python?

---

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)

it's probably := to make people want to avoid it. i know i will avoid it.

[metulburr]

I had to google what the hell := operator was. From that i determine its just =. Apparently in Golanguage its initialization and assignment. But I dont know why you would need that in python? Unless its suppose to be used with the new annotations?

Apparently i am getting behind not fluently using python on the new features...lol

[buran]

Unless its suppose to be used with the new annotations?

actually, assignment expressions - PEP572 and it was officially accepted
https://www.python.org/dev/peps/pep-0572/
https://www.reddit.com/r/Python/comments...fficially/

[Skaperen]

by having assignment expressions use a different operator, it avoids the confusion Guido was originally trying to avoid. the idea as i see it is that this distinguishes the different uses by which operator is chosen, allowing it to be known the explicit intentions of the coder. that it be := would discourage people from routinely using it for ordinary assignment (where the expression value can be ignored). perhaps such (mis)uses can then be flagged and rejected.

[nilamo]

I'm ok with a different operator for assignment in expressions. The main problem with just using =, is that it doesn't look all that different from == at a glance, which means you don't know there's something being assigned unless you look carefully. And the whole point of python, is that you shouldn't have to look carefully.

[ichabod801]

After looking over it, I like it and I don't like it. I agree that it's a problem that would be good to solve, I've been running into it a lot lately. However, I would have preferred 'as' to a new operator.

[nilamo]

Do you think the new operator will replace as in with blocks?

with my_file := open("spam.txt"):
    # read file