[Python-3000] optional argument annotations

[Brett Cannon]

On 11/24/06, Guido van Rossum <guido at python.org> wrote:
> On 11/24/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> > On 11/23/06, Guido van Rossum <guido at python.org> wrote:
> > > On 11/23/06, Tony Lownds <tony at pagedna.com> wrote:
> > > > I have a working optional argument syntax implementation, I'm hoping
> > > > to get some direction on
> > > > the implementation decisions so far.... please see below.
> >
> > I would rather see it integrated into a Signature object (Brett had an
> > implementation), instead of showing up as two separate attributes.
>
> Yes, you're right; I forgot about that.
>

Guess I need to make sure to bug you about pronouncing on the PEP once
I get keyword-only arguments support added before you forget again.
=)

Obviously signature objects would grow support for annotations, but I
still need the information to be carried on the code object to
incorporate into signature objects.

Another option for how to handle annotations is to take the route of
having a tuple listing all of the strings representing the
annotations, using None for arguments that have no annotation.  That
way there is no issue distinguishing whether an annotation exists or
not plus it is a cheap operation since you are then just storing
strings.  This also allows the last value in the tuple to imply the
return annotation and thus only have a single attribute for
annotations.  Then you can have signature objects worry about pulling
out the info to tie into specific parameters to work with the
annotations.

> > > >  >>> f.func_returns
> > > > Traceback (most recent call last):
> > > >    File "<stdin>", line 1, in <module>
> > > > AttributeError: 'function' object has no attribute 'func_returns'
> >
> > > I would prefer this to be None. Attributes that don't always exist are
> > > a pain to use.
> >
> > I suspect he was trying to distinguish "returns None" from "Doesn't
> > say what it returns".  There is no good way to do this, but a separate
> > flag on a Signature object seems the least bad to me.
>
> Hm, I think it would be fine if there *was* no distinction. IOW if
>
>   def foo(a: None) -> None: pass
>
> was indistinguishable from
>
>   def foo(a): pass
>
> In fact I think I'd prefer it that way. Having an explicit way to say
> "no type here, move along" sounds fine. It's different from defaults,
> whose absence translates in different behavior (i.e., requiring that a
> value be passed in).
>

This also mirrors the default way that functions work since they
return None if you don't bother to specify somethng.

> (It does imply that we can't use "-> None" to indicate "returns no
> value". We'd have to spell that as "-> type(None)" or find some other
> way. I think I don't care. Do others? Collin?)
>

I always figured we would return type.

-Brett