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

[Brett Cannon]

On Sun Aug 17 2014 at 6:36:43 AM Andrey Vlasovskikh <
andrey.vlasovskikh at gmail.com> wrote:

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

That's only an issue if the type-checking code chooses to care about
__instancecheck__/__subclasscheck__. The tool could choose to simply ignore
those methods and treat them as a run-time only benefit for
isinstance/issubclass checks but not for type checking. This is especially
true if the check is being done on the AST instead of imported code. People
can simply be told that their linter tool will not pick up magical
__instancecheck__/__subclasscheck__ implementations.

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