It still needs a PEP (or a PEP 484 patch?) but we're definitely not going to withdraw it, and I think it'll be easy enough to keep it mostly backwards compatible.
We should also move it to typing.py, but we should at least support it in typing_extensions so it can be used with Python versions whose stdlib typing.py is hard to update (3.5, 3.6 and 3.7.0).
Changes to mypy itself would be to allow it being imported from either mypy_extensions, typing_extensions, or typing. We can then copy the runtime support into the typing repo (both into typing.py and into typing_extensions.py, which also lives in that repo), and add stubs providing it to typeshed (probably it should be defined in typing.pyi, and imported from there into the other two stubs, for both Py2 and Py3).
It still needs a PEP (or a PEP 484 patch?)
I think we agreed at PyCon that there will be no _new_ things in PEP 484 (clarifying existing things is OK though). So I think it should be a separate one, also it may be not so small if we carefully specify all the aspects:
TypedDict('TD', {'x': int}), TypedDict('TD', x=int).conf: TypedDict(x=int, y=str).get() etc.)** unpacking in function callsdef f(x: int, y: int) -> None: ...
c: TypedDict(x=int, y=str)
f(**c) # Error, because of 'y', IIRC not yet implemented
**kwds in function definitions. The point is that unlike *args that tend to be homogeneous, **kwds tend to be heterogeneous. Moreover, in some frameworks (like matplotlib) there are many functions that share same set of config options. I would like to see a way to write:class Style(TypedDict):
fmt: str
alpha: float
color: Union[Color, str]
marker: Union[Marker, str]
<dozen others skipped>
def plot(x: Array, y: Array, **kwds: Style) -> List[Line2D]: ... # currently does not what expected
I think that this is a significant enough feature to have a new PEP.
Here are couple of things we might want to consider before writing a PEP:
dict(...) (#2739)OK, it's decided we are writing a new PEP.
Can we still move it to typing_extensions and make mypy (perhaps silently) start supporting it from all three locations? Presumably mypy can expect it in typing and the stubs for the other two just import it from there.
Can we still move it to typing_extensions and make mypy (perhaps silently) start supporting it from all three locations?
Yes, but we will need to add TypedDict to typing stubs in typeshed (like we do already for Protocol) so that TypedDict can be used in stubs as directly imported from typing.
This was done a while ago.
@ilevkivskyi Hi! I'm tracking this issue and I wonder how exactly it was done?
The import command still returns error for python3.7 and python3.8:
>>> from types import TypedDict
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name 'TypedDict' from 'types' (/usr/lib/python3.8/types.py)
>>> from types import TypedDict
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: cannot import name 'TypedDict' from 'types' (/usr/lib/python3.7/types.py)
Built-in typing stuff is in typing module. TypedDict is available as built-in type since python 3.8, so you can use from typing import TypedDict there. For version below it however, you have to download typing_extensions and then you'll be able to import TypedDict using from typing_extensions import TypedDict
Most helpful comment
Built-in typing stuff is in
typingmodule.TypedDictis available as built-in type since python 3.8, so you can usefrom typing import TypedDictthere. For version below it however, you have to downloadtyping_extensionsand then you'll be able to importTypedDictusingfrom typing_extensions import TypedDict