[Python-3000] Py3k release schedule worries

[Brett Cannon]

On 12/19/06, Guido van Rossum <guido at python.org> wrote:
>
> On 12/18/06, Brett Cannon <brett at python.org> wrote:
> > On 12/18/06, Guido van Rossum <guido at python.org > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061219/9dd09248/attachment.html