This is a work-in-progress repository for the draft of the Type Hinting PEP for Python 3.5.
- Guido van Rossum
- Jukka Lehtosalo
- Łukasz Langa
An explanation of the theory is here: https://quip.com/r69HA9GhGa7J
Putting new things in
collections.abcseems fine as long as those new elements are actual abstract base classes that are collections. I (Łukasz) lessened this latter requirement since there's non-collection precedent inabc, namelyCallable, andHashable. However, attempts at implementing reasonable runtime behavior suggests that it may be better to leavecollections.abcalone. Proposed resolution: Leavecollections.abcalone.Var('T')is put incollections.abcas a helper with generics and covariance/contravariance in ABCs. May be renamed toTypeVar. The co-/contravariance behavior requires more thinking. Proposed resolution: UseTypeVar, with mypy's semantics mapped:typevar('T', values=(str, bytes)becomesTypeVar('T', str, bytes).AnyStr(and consequentlyIO) smells like basestring in disguise, what is the use case for Python 3? Answer: There are lots of things in the stdlib that are essentially overloaded as str-in-str-out and bytes-in-bytes-out;AnyStrhas exactly the right behavior for this (unlikeUnion[str, bytes]). Proposed resolution: KeepAnyStr,IOand its subclasses, in typing.py.Undefinedsmells like JavaScript, I (Łukasz) left it out for now. However, mypy needs it. See #20 Help???The addition of
MatchandPatternseems arbitrary and should rather be fixed inredirectly, with the types just imported intyping. If so, are there any other potentially useful types we'd like? See #23 Proposed resolution: Keep these two in typing.py for convenience.I (Łukasz) left out
overloadbecause I don't understand its purpose. If we need generic dispatch, we should add it tofunctools. Perhapsoverloadshould only be allowed in stub modules? See #14 Proposed resolution: support the syntax but only in stub files.I (Łukasz) left out specifying protocols as they are an ABC implementation detail from the perspective of this PEP. However, they should be defined in a separate PEP because making
__subclasshook__less dynamic when possible (which is often) would make ABCs much better behaved in static analysis contexts. See #11 Help???Having the last thing in mind,
IO,BinaryIOandTextIOwould simply be new abstract base classes, usable with or without type hinting. Proposed resolution:IOis generic overAnyStr, the other two are concrete (subclassingIO[bytes]andIO[str]respectively).The current implementation of
*IOis quite un-ducktyped (specifies both reading and writing as one protocol) Help???I (Łukasz) left out
castbecause it can be more consistently expressed as:bad_typed_list = [1, 2, 3] # type: list ... well_typed_list = bad_typed_list # type: List[int]
See #15 Proposed resolution: Add
cast(type, value)back in.I (Łukasz) removed
mypyfrom the listed "existing approaches" since we basically describe what mypy is. Proposed resolution: Fine.I (Łukasz) thought if introducing optional contravariance/invariance to
Varhas merit but I'm undecided; definitely complicates the type checker. See #2 Help???
typevarbecomesVar('T')and its semantics support specifying base type constraints. If we decide to add optional invariance or contravariance, this will be the place, too. Or perhapsTypeVar('T'). See python/mypy#539 and #1 and #2 and maybe others. Proposed resolution:TypeVar(see above).Unionbehaves differently, it holds the defined types in order to be able to actually respond to issubclass. Proposed resolution: This doesn't affect mypy; I do want this for typing.py (also for generic types).typing.Functionbecomestyping.Callable, which is equivalent tocollections.abc.Callable. (Has now been implemented in mypy.)
- How to make the union type land in __annotations__ for the
x: str = Nonecase? - State of the art: should we list decorator-based approaches (PyContracts?) and docstring-based approaches?
- Should we recommend the use of ABCs over builtin types when possible?
- Should we provide type shortcuts so that MutableMapping is not 3.5x longer to type than dict?
- Is multiple dispatch using type hints in scope for this PEP? Proposed resolution: let's wait, allow @overload only in stubs.
- Should we mention platform- or version-specific typing? Guido mentioned Windows vs. POSIX during the Skype meeting. Proposed resolution: Let typing.py export a few specific constants; PY3, PY2, PY3_x (for x in 2, 3, 4, 5).
- It would be useful to have a
Subclass[]factory that would be equivalent to "any class that has the all the following classes in its MRO". Maybe we'd want to rename union toAny[]and this new proposed type toAll[]? See #18 Proposed resolution: Let's just haveUnion[T1, T2, ...]andAny. - Callable signature definition should be explained and support all
valid function signatures.
Proposed resolution:
Callable[[T1, T2, ...], Tr]. - What about all other collections available in the
collectionsmodule? Proposed resolution: Make Generic types retain their argument type(s).