[Python-ideas] generic code and dependent types

Dennis Brakhane brakhane at googlemail.com
Fri Aug 15 15:06:31 CEST 2014


Am 15.08.2014 12:56, schrieb Neal Becker:
> I wonder if any of the proposals will be able to handle this sort of algebra on 
> types?  I think it's needed to truly support generic code.
>
I hope it won't ;-)

I agree that it is needed for truly generic code, but if Python gains a
truly complete type system, then what's the point of having dynamic
typing at all? At this point,
you might as well program in Scala instead.

What's the point in trying to turn Python into a statically typed
language that can optionally be dynamically typed? There are enough good
static languages out there.

IMHO, the type information in Python should be considered part of the
documentation, if the type system gets too complex and can only be
parsed by the linter, then what's the point?

Is the information: "this function takes an Iterable of T and a
Map[U,Map[U,T]|T|int] and returns the type of the result of foo applied
to parameters of type T and U" really useful
for a programmer anymore?

Does it help me if the linter says that "Map[int,float]" is not
compatible with "T|Map[U,V subtype str]|Map[U subtype str, V]"? I think
if my unit test fails with a "TypeError: float has no method strip"
that's a much more useful information to me.

So I think limiting the power of the type system will actually be a good
thing.




More information about the Python-ideas mailing list