[Python-3000] Use cases for type annotations? (WAS: Type parameterization)

[Collin Winter]

On 5/20/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 5/20/06, Guido van Rossum <guido at python.org> wrote:
> > Collin Winter's is pretty real, and I believe one other person (Tony
> > Lownds?) has another.
>
> I wandered around
>     http://oakwinter.com/code/typecheck/
> but couldn't find any discussion about the implications of, say,
> requring the type ``{str:Number}`` (which I assume is basically
> equivalent to the dict[str, Number] in this discussion).  Does that
> mean that every access to the dict is checked?

{str: Number} is indeed my syntax for dict[str, Number] (I didn't have
the luxury of messing with the built-ins ; )

http://oakwinter.com/code/typecheck/tutorial/builtintypes.html in
particular discusses what it means to say that an argument should be
{str: Number}: namely, that all keys must be strs and all values
should be Numbers. It also talks about tuples, lists and sets.

The documentation also (frequently) says things like "The following
signature asserts that the function takes a list of Numbers and
returns a single Number", "This [signature] specifies that the
function accepts a 2-tuple", "In this example, the first two arguments
to the function must be Numbers, but 'c' can be anything", "In the
following signature, the 'a' parameter must be either 6 or 7", etc.

Put simply, I'm having trouble imagining where you're getting ideas
about {str: Number} creating wrapping layers around the dict, since
such a thing is never once mentioned in the docs.

> I do like the idea of the TypeClass object, which basically infers an
> interface.  But I'd really like someone to discuss the performance
> implications somewhere.  Maybe it is and I just couldn't find it?

I haven't done any real performance analysis on my system. My focus so
far has been getting things working the way I want, saving the
performance issue for later.

Collin Winter