[Python-3000] Py3k release schedule worries

[Guido van Rossum]

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.

> 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.

> Then again, functions are only created once and extra overhead
> could help discourage too much usage.  But using strings and None like this
> cleanly solves the ambiguity issue of what value represents when no
> annotation was set (object, type?).

I think None is fine.

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