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

[Łukasz Langa]

On Aug 17, 2014, at 3:35 AM, Andrey Vlasovskikh <andrey.vlasovskikh at gmail.com> wrote:

> 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.

That's right. Moreover, arbitrary classes can be register()'ed on an ABC to respond to subclass and instance checks during runtime. Meta-classes and __new__ can do surprising things with returned class objects, too. In all cases Mypy would generate a false-positive type error. That's fine, we can improve on that in multiple ways. [1]

People will put classes with ABCMeta in function annotations whether we design for it or not. Subclassing a MutableMapping is the easiest way to implement the whole protocol. As you say, __instancecheck__ and friends aren't limited to ABCs. People will put classes implementing those in function annotations, too. People will have classes with elaborate metaclasses as well.

Most importantly: often those classes will come from libraries and frameworks that those people didn't write themselves. We can't expect them to open every black box to see if it works with type hinting. Lastly, classes may and will evolve, sometimes to grow more static and sometimes to become more dynamic.

What I'm saying is that the typing module does not shield you from any of it. We need to define type hinting as a best-effort solution to set reasonable expectations. You need to understand the additional cognitive burden a new module like 'typing' this would impose on us and our users.


> 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.



[1] My suggestions:
- ABCMeta is special and we can reasonably improve on the runtime .register() invocations by scanning the source for those
- a redefined __instancecheck__ would generate a warning
- we can define a way for a Python program to say: this module is safe to be imported independently for executing __subclasscheck__ and __subclasshook__ checks on its classes
- failing all of the above, this is a perfectly fine case for optional runtime type checking; I don't think anybody has the expectation that we will statically analyse their highly dynamic codebases

All the above suggestions might be incremental. It's totally fine if we just begin with the last one.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140817/3ffe0b38/attachment-0001.html>