[Types-sig] Keyword arg declarations

[Tim Peters]

[Guido van Rossum]
> I just realized that Tim's decl syntax that's currently being
> bandied around doesn't declare the names of arguments.  That's
> fine for a language like C, but in Python, any argument with a
> name (*args excluded) can be used as a keyword argument.

I never specified the full syntax, and partly because regurgitating the full
arglist syntax at this point would lose the idea to the details!  Arglists
in Python are complex beasts.

> I think it will be useful for the decl syntax to allow leaving out or
> supplying argument names -- that tells whether keyword arguments are
> allowed for this particular function.  And that is part of a
> function's signature.

Definitely part of the signature.  Optional arguments too!  Are default
*values* also part of the signature?

    def increment(x, bump=1): ...

If this got declared via e.g.

    decl increment: def(Int, Int=1) -> Int

then *call* sites could generate code to build the full argument list
appropriately, and invoke a leaner entry point to the eval loop that didn't
have to deduce the correct arglist at runtime via an all-purpose algorithm.
This could be a valuable time-saving (albeit code-bloating) optimization.

OTOH, I have too much abusive code that looks like:

    def whatever(arg1, arg2, _int=int, _ord=ord):

and I've been secretly hoping I could abuse the declaration mechanism to
"export" this as

    decl whatever: def(Any, Any) -> Any

This addresses the rare but real errors wherein a caller inadvertently
passes "too many" arguments, overwriting one of the speed-hack default args.

Then there's also

    decl yadda: def(Int, =Int) -> None

for the case where the 2nd argument is optional but the user doesn't want it
treated as a keyword argument.  My idea on that one was to say "tough
luck -- you need to give the name here".  What do (the generic) you say?

> (Note that not all builtins support keyword arguments; in fact most
> don't.)

So fix that <wink>.

> (Un)related: I think it makes sense to be able to restrict the types
> of *varargs arguments.  E.g. eons ago (last week in the types-sig)
> someone proposed an extension to isinstance() allowing one to write
> isinstance(x, type1, type2, type3, ...).  Clearly the varargs are all
> type objects here.
>
> Not so sure about **kwargs, but these should probably be treated the
> same way.

Coincidentally addressed that in an earlier msg.  Don't think it's a
problem.

    decl isinstance: def(Any, Type) | def(Any, Type, *: (Type))

although the use of "(thing)" to mean "tuple of things of arbitrary length"
does look like a syntax awaiting regret <0.9 wink>, and more than one of us
has stuck "extra" parens in declaration examples for clarity.

unicode-will-supply-many-more-matching-brackets<wink>-ly y'rs  - tim