> On Nov 7, 2017, at 9:39 AM, Brett Cannon <br...@python.org> wrote: > > On Tue, 7 Nov 2017 at 03:34 Paul Moore <p.f.mo...@gmail.com > <mailto:p.f.mo...@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:
https://github.com/python/typing/issues/496
<https://github.com/python/typing/issues/496>
- Ł
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
