[Python-3000] Type annotations: annotating generators
Nick Coghlan
ncoghlan at gmail.com
Sun May 21 03:59:26 CEST 2006
Collin Winter wrote:
> On 5/19/06, Guido van Rossum <guido at python.org> wrote:
>> OK; for the return value (only) the Function().returns(<type>)
>> notation does look fairly pretty.
>>
>> I presume that return(int, int) is the same as return((int, int))?
>
> It is.
>
>> Weren't we going to write a tuple of two ints as tuple[int, int]
>> though? Is (int, int) now just an alias for that or does it have a
>> different meaing?
>
> I think that returns() is smart enough to know that "returns((int,
> int))" is the same as "returns(int, int)". It will know to do
> something similar for "returns(tuple[int, int])".
Assume the following is true for a type annotation system:
(T,) is equivalent to tuple[T]
(T1, T2) is equivalent to tuple[T1, T2]
(T1, T2, T3) is equivalent to tuple[T1, T2, T3]
This fits in with how tuples are typically intended to be used (small
collections of heterogeneous data), but how do I use this system to spell the
type annotation for a tuple of unknown length containing only T instances?
I'd say "that's what lists are for", except that the CPython core uses tuples
as homogeneous containers of unknown length in several places. For example,
the sequence used to hold the additional arguments to a function is a tuple.
So I would expect the type annotation in "*args : T" to be implicitly
translated to "tuple[T]". Similarly, I would expect the type description for
both __mro__ and __bases__ to be "tuple[type]".
This contradicts the original assumption above, suggesting that a type
description for a tuple and a tuple of type descriptions should not be
considered equivalent.
With such a mechanism, "T1, T2" would be a type description for a 2-tuple,
while "tuple[T1, T2]" would be a type description for an arbitrary length
tuple of 2-tuples.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
More information about the Python-3000
mailing list