On 12/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 12/18/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 12/18/06, Guido van Rossum <[EMAIL PROTECTED] > wrote:
> > When you say "just store strings" do you mean that the implementation
> > would be limited to strings or just that you would only use it to
> > store per-argument docstrings? The latter is fine with me; the former
> > seems an unnecessary restriction.
>
> So code objects would grow a co_annotations that would be a tuple of
strings
> that stored what the annotations were as strings, with the last slot
> reserved for returns. Any parameter that didn't have an annotation
would
> have None assigned to it. This means that this code::
>
> def fxn(a:int, b, c:str='hi') -> float: pass
>
> would have a co_annotations of ``('int', None, 'str', float)``. Keeping
> everything as strings keeps it simple and minimizes any performance
impact
> from them being declared. People can then easily write decorators that
read
> the tuple (or use signature objects) to type-check as desired.
Sorry, that's not at all how I am envisioning it. Apart from being
stored in a different place I want these to work exactly the same way
as defaults -- they can be expressions with any value and whatever
value they evaluate to at def time will be stored there.
(Another reason is that it's far from trivial for the parser to get
the actual text as a string, unless you very severely limit the
syntax, which I also don't want to see -- I want to be able to use
List[int] for example.
Ah, OK. Then I will stay out of Tony's way since he seems to be doing it
the way you want.
Tony's implementation seems to actually fetch from globals what the
> annotation specifies and I just don't think that is necessary and
unneeded
> overhead.
Why? I think it's the right thing to do. I'll have to look at his patch.
Because I was viewing the whole thing from a different perspective than
you. =)
-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
