[Python-ideas] Improving the expressivity of function annotations

Masklinn masklinn at masklinn.net
Mon Apr 4 21:03:33 CEST 2011


On 2011-04-04, at 20:22 , Terry Reedy wrote:
> 
>> ``type`` instances (with e.g. ``list[int]`` yielding a list with some
>> kind of ``generics`` attribute),
> That sounds a lot like array with a typecode.
It's similar, but extended to any arbitrary type, including non-collection types.

> You can use a dict subclass or UserDict to get a mapping with restricted keys and values, with bad inputs ignored, coerced, or error raising as you please. Ditto for lists.
That is not very useful for function annotations, especially when using built-in collections. Users would be restricted to non-built-in types and static systems still would not have any information on what could and could not go into e.g. collections.

>> Sum = (A | B | C)
> > assert issubclass(A, Sum)
> 
> That appears to be exactly the same as
> Sum = (A,B,C)
> assert issubclass(A, Sum)
> 
> Sum2=Sum|D # same as
> Sum2=Sum+(D,)
> 
> so the purpose of the duplication is not obvious.
Again, the issue is function annotations, which was my context. The example was just to give an idea of the operation performed. In function annotations, unless you went with type parameters and ``tuple[A, B, C]``, ``(A, B, C)`` would likely be interpreted as "a triple of instances of types A, B and C".

>> Anyway this is where "structural types" come in: defining a type not
>> by its name but by its shape (a set of methods and properties, and
>> their signatures).
> When it comes to tracebacks, multiple unbound functions with duplicate f.__name__ == '<lambda>' attributes are inferior to functions with, in a particular context, unique names. I would feel the same about multiple stypes with .__name__ == '<stype>'.
I'm not sure what you're getting at here: structural types are static features, the displayed types would be the original concrete types you created, there would be no loss of runtime information compared to current behaviors.


More information about the Python-ideas mailing list