
On Fri, Jun 25, 2021 at 10:16 AM Steven Troxler <steven.troxler@gmail.com> wrote:
We did intend to allow ``` (int, str = ...) -> float ``` in hybrid syntax, because positional-only arguments *must* be nameless in hybrid as proposed.
No wonder you're not in favor of hybrid syntax. :-)
## Mixed Syntax
I added another option "mixed" to the doc
I tried to capture my understanding of your suggestions: - allows nameless positional-only arguments as long as they don't have default values - optionally lets users specify names as in stub-style, but in that case a `/` is required - forces users to specify a name (possibly just _) for a positional-only argument with default
So in mixed (assuming we allow `_`), the signature above could be written as either ``` (int, _: str = ..., /) -> float ``` or ``` (_: int, _: str = ..., /) -> float ```
I think I like the mixed idea. It has most of the benefits of hybrid syntax: - simple callables are compact - it has a canonical representation without nuisance parameters we can use in type errors - we can mostly avoid `/` (my guess is that positional-with-default args are pretty rare)
It's not that rare, except people typically don't use the / unless they are feeling pedantic. I suspect that many functions exist like this: ``` def func(x, y, z=0): ... ``` where the user's intention is really ``` def func(x, y, z=0, /): ... ``` but their code needs to be compatible with Python 3.7, or perhaps it was written when 3.7 (or earlier) was current and the code wasn't updated to add the /.
There are multiple options for how users can represent a type, which is the big drawback.
Is it though? It doesn't strike me as a big problem. Yes, the Zen of Python says TOOWTDI, but you have to take that with a grain of salt. I also like that there's a nice simple upgrade path for code that currently uses Callable[]: once it can drop support for 3.10 and earlier, Callable[[T, S], R] becomes (T, S) -> R, which is much cleaner than (_: T, _: S, /) -> R. I suspect many, many use cases will be satisfied with this.
But allowing folks to name their positional arguments means they can make callback types much more self-documenting, since a name plus a type can express what a callback is supposed to do much better than a type signature alone.
Agreed, for new code this is a nice option. Then again I suspect there are plenty of Callable types with a single argument whose meaning is obvious from the name of the callback. And it's not possible to insert names when mechanically replacing Callable[] with the new notation.
Obviously library authors tend to put this information in docstrings, but having it as part of the callback type would mean the argument names can be available in type error messages and IDE hovers.
Yes, that would be nice. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>