On 11/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 11/24/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > On 11/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > On 11/23/06, Tony Lownds <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
