[Python-ideas] Optional static typing -- the crossroads

[Andrey Vlasovskikh]

2014-08-17, 13:41, Łukasz Langa <lukasz at langa.pl> wrote:

> On Aug 16, 2014, at 10:03 PM, Guido van Rossum <guido at python.org> wrote:
> 
>> All in all I prefer the mypy syntax, despite being somewhat more verbose and requiring an import, with one caveat: I agree that it would be nicer if the mypy abstract collection types were the same objects as the ABCs exported by collections.abc.
> 
> Good :) If the functionality will be implemented in the ABCs, what is the purpose of the typing module?
> 
> My suggestion: if the functionality will be implemented in the ABCs, there's no need to introduce the "typing" module. We can back-port the new ABCs, for sure, but for Python 3.5 `collections` is enough (already has aliases to collections.abc0.

-1 for collections.abc classes, +1 for mypy's typing classes.

There is a problem in static analysis of current types that are instances of abc.ABCMeta or types that just define their own __instancecheck__ / __subclasscheck__. Static analyzers cannot infer in general case what attributes of an instance / subclass do these methods check, because their body can be arbitrarily complex.

Mypy's typing.Protocol subclasses are much easier to analyze statically, since they are required to explicitly define abstract methods as function defintions inside the class body.

Current collectoins.abc classes do define their methods explicitly too, so it seems that at least these classes are fine. But their inheritors don't have to do it, they may just override __subclasshook__. And promoting abc.ABCMeta-based ABCs would mean that not all ABCs can be used as static type annotations.

-- 
Andrey Vlasovskikh

Web: http://pirx.ru/