[Python-3000] Type annotations: annotating generators

[Guido van Rossum]

On 5/19/06, Collin Winter <collinw at gmail.com> wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
> > On 5/18/06, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> > > I have a question to the audience. How do you represent higher order
> > > functions using this syntax?
> >
> > I think Collin and I both (independently) proposed the pragmatic
> > Function(<type>, <type>, ..., returns=<type>) for this.
>
> Based on a suggestion from Nick Coghlan [1], I'm now favoring
> something like this:
>
> Function(<type>, <type>, required_keyword=<type>, ...).returns(<type>)

I do like the Function().returns(int) notation but would like to push
back on keywords.

> The idea would be that you can use keyword arguments to Function to
> assert that the passed-in function object supports being called with
> certain keyword arguments.
> That is, if you were planning to call a passed-in function like so:
>
> func(5, 6, abc=7)
>
> you'd want to assert that func actually has a parameter named 'abc'.
> The corresponding Function would be Function(Number, Number,
> abc=Number).
>
> Using a 'returns' keyword argument to Function would effectively
> prohibit you from making sure that a function has a parameter named
> 'returns'. Hence, the returns() method.

(Not a big loss unless you wanted to talk about the signature of
Function itself. :-)

> As I mentioned [2], you can play around with this model using the
> trunk/ version of typecheck [3] (with docs for Function() [4]). This
> is by no means set in stone, so comment away. The main point I'm not
> entirely happy with: the use of star() and double_star() methods to
> indicate types for *vargs and **kwargs, respectively.
>
> If you like this general approach to handling Function(), I'll sketch
> out a version of Generator along the same lines.

I think it's overkill and still not enough. When I write "def foo(a,
b=2): ..." all of the following call signatures are valid: foo(1),
foo(a=1), foo(1, 2), foo(1, b=2), foo(a=1, b=2), foo(b=2, a=1). Do we
really want a notation that lets us describe that?

I would like to push back and *only* support fixed-number positional
parameters and a return value for signature declarations.

Think about it: when's the last time you had a callback parameter that
was called with keyword arguments?

Keyword arguments, varargs, etc. are nice when calling specific known
functions/methods. But I'm not sure that they are all that interesting
when coding higher-order functions.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)