El mié, 16 jun 2021 a las 12:26, Guido van Rossum (<guido@python.org>) escribió:
On Wed, Jun 16, 2021 at 12:13 PM Shannon Zhu <szhu@fb.com> wrote:

In practice, I’m not as concerned with the potential pitfall of confusion between a type annotation and an argument name.

 

I think it may look similar when we’re using lowercase variable placeholders in hypothetical examples, but in practice if someone wrote `(a, b) -> bool` where `a` and `b` are parameter names, they’ll get an UndefinedType error complaining that `a` and `b` aren’t valid types. Even before that, I think it would be somewhat unintuitive for someone decide to specify a callable type, then want to put parameters in without types, and go fetch names for those parameters instead of just using “…”. Or if there’s a mix of typed/Any params, that would mean they’re actively alternating between types and param names. 

 

If we want to support either all-or-nothing named params that seems reasonable to me, ie., what Guido mentioned about either fully shorthand or fully spelled out.

 

  • In this form a "bare" name represents an argument name and has the implicit type Any, like it has in function definitions

 

What are your thoughts on erroring on this and mandating an explicit Any if you’re using the full form syntax – so all parameters must both have a name and a type if you aren’t using the shorthand version?


That sounds reasonable. The one case where it would be a bit verbose is if you have a bunch of mandatory positional parameters and one optional keyword. Without this restriction you could write this as

f: (int, int, str, str, mode: str = "r") -> bool

whereas in your version it would have to become

f: (a1: int, a2: int, a3: str, a4: str, mode: str = "r") -> bool
That's actually subtly different, because it would require positional-or-keyword arguments, so a callable with differently named arguments would not be compatible. The unambiguous equivalent would need `/,`. Though of course we could decide that the rules should be more lenient here.
 

--
--Guido van Rossum (python.org/~guido)