(original) (raw)
On Nov 7, 2017, at 9:39 AM, Brett Cannon <brett@python.org> wrote:On Tue, 7 Nov 2017 at 03:34 Paul Moore <p.f.moore@gmail.com> wrote:
Because type annotations are a development-time feature, they should
\*not\* require a dependency in the final deployment (apart from Python
itself). However, because they are a language syntax feature they are
of necessity written in the application source. And type specification
of anything more complex than basic types (for example, List\[int\])
requires classes defined in the typing module. Therefore, typing must
be in the stdlib so that use of type annotations by the developer
doesn't impose a runtime dependency on the end user.That's not necessarily true if Lukasz's PEP lands and annotations become strings. The dependency would only need to be installed if someone chose to introspect the annotations and then "instantiate" them into actual objects. And that only comes up if someone does it from outside by a 3rd-party, who would then need to install the type annotation dependencies themselves.
PEP 563 is the first step there but it's not enough. For this idea to work, \`typing.TYPE\_CHECKING\` would need to be moved to the Python runtime, so that you can do
if TYPE\_CHECKING:
from typing import \*
More importantly, you would put type aliases, type variables and new-types in this \`if\` block, too.
But even if all this is true, there's still two remaining features that require runtime availability:
1\. \`cast()\`; and
2\. creating generic classes by subclassing \`Generic\[T\]\` or any of its subclasses. And soon enough, Protocols.
I hope I'm not forgetting any other cases. For \`cast()\` I have an idea how to move it to a variable annotation. For generic classes, there's no magic, you need \`typing\` at runtime. Fortunately, that latter case is (I hope?) relatively unlikely.
All the above is summarized here:
- Ł