On 4 November 2017 at 04:24, Guido van Rossum <gu...@python.org> wrote: > A side note (I'm reading all responses but staying out of the discussion): > > No static checker should depend on the *contents* of typing.py, since it's > just a bunch of runtime gymnastics to allow types to be evaluated at runtime > without errors, with a secondary goal of making them introspectable (some > folks don't even agree with the latter, e.g. Mark Shannon). > > Static analyzers should be able to make strong *assumptions* about what > things defined there mean -- in mypy such assumptions are all over the > place, based on the full name of things -- it never reads typing.py. (It > reads typing.pyi from typeshed, but what's there is ignored in many cases > too.)
If I understand correctly, a lot of the complexity in the current typing.py implementation is there to make isinstance and issubclass do something "useful" at runtime, and to allow generics to be used as base classes. If it wasn't for those design goals, then "typing.List[int]" could just return a lightweight instance of a regular class rather than a usable Python class definition. If I'm right about that, then PEP 560's proposal to allow types to implement a hook that says "Replace me with this other object for runtime subclassing purposes" may be enough to let you delete most of the current code in the typing module - you'd just need to have isinstance and issubclass respect that new hook as well, and define the hooks as returning the relevant ABCs. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
