Help with explaining the value of typing.TypedDict
I hope you're all well. I am writing the 2nd edition of Fluent Python and right now I am trying to wrap up a section on typing.TypedDict, but I am having a very hard time understanding its value in real world scenarios. PEP 589 acknowledges that JSON is a "canonical use case" for dicts used as records. But since the whole point of a TypedDict is to provide syntax for type hints, I can't find a connection or any benefit of using TypedDict with code that deals with JSON—where all the action is at runtime. All the examples in the PEP use literal dicts as values when assigning to variables annotated with a TypedDict type. If I annotate a function parameter with a TypedDict, and I am forced to spell out all the keys to provide a dict argument that can be type checked, I don't see why not use keyword arguments in the function definition in the first place... My testing shows that Mypy is unable to do much validation beyond assignment from dict displays or dict constructor calls with keyword arguments. More realistic use cases that I was able to imagine often need casts and don't perform any useful static checking. My future readers and I could really use more insight about real world use cases where TypedDict adds value. Thanks for any help! Cheers, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg
I use TypedDict with JSON so I get good hints in my IDE when dealing with complex JSON structures coming in from web APIs. This includes hints of key names as well as methods to use with the types of data in the structure. from typing import List, TypedDict class SubDataTypedDict(TypedDict): id: int name: str widgets: List[int] class DataTypedDict(TypedDict): id: int subDatas: List[SubDataTypedDict] foo: str def data_doer(data: DataTypedDict): # using `data` in this function will give me completion on key names # as well as being aware of the types of the values and giving me # completion on relevant methods. On Wed, May 20, 2020 at 2:52 PM Luciano Ramalho <luciano@ramalho.org> wrote:
I hope you're all well.
I am writing the 2nd edition of Fluent Python and right now I am trying to wrap up a section on typing.TypedDict, but I am having a very hard time understanding its value in real world scenarios.
PEP 589 acknowledges that JSON is a "canonical use case" for dicts used as records. But since the whole point of a TypedDict is to provide syntax for type hints, I can't find a connection or any benefit of using TypedDict with code that deals with JSON—where all the action is at runtime.
All the examples in the PEP use literal dicts as values when assigning to variables annotated with a TypedDict type.
If I annotate a function parameter with a TypedDict, and I am forced to spell out all the keys to provide a dict argument that can be type checked, I don't see why not use keyword arguments in the function definition in the first place...
My testing shows that Mypy is unable to do much validation beyond assignment from dict displays or dict constructor calls with keyword arguments.
More realistic use cases that I was able to imagine often need casts and don't perform any useful static checking.
My future readers and I could really use more insight about real world use cases where TypedDict adds value.
Thanks for any help!
Cheers,
Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dustin.wyatt@gmail.com
I think we can categorize people who use PEP 484 types into broadly two groups: people who use types from the start on new codebases, and people who want to start adding types to an existing (and often large) codebase. Typing tries to accommodate both groups, which means there'll sometimes be features that are more useful for one group than another. For example, I think TypedDict is one example of a construct that's particularly useful for people trying to add type hints to existing code bases. For better or for worse, some of these kinds of codebases really like using dicts instead of objects to pass around data, which means it'll sometimes be easier to type the dicts instead of migrating everything in one shot to use objects. Typing (and mypy) tries to make it easy to make these sorts of incremental changes. I also want to point out that casting isn't necessarily a bad thing: PEP 484 is designed to be a gradual type system and lets you pick and chose to what degree you want to validate vs trust incoming external data. You can do anything between defining a full (or partial) schema for incoming data and validating + deserializing it into objects using something like Pydantic to just trusting that the input is stable and using a cast. (The latter option would be less ceremony -- and if the input data is large, let you skip a potentially expensive validation/deserialization step). But regardless of whether you choose to trust vs verify, it's still useful if the type checkers and IDEs can help you *use* the data correctly, as Dustin said. So, TypedDicts. -- Michael On Wed, May 20, 2020 at 1:32 PM Dustin Wyatt <dustin.wyatt@gmail.com> wrote:
I use TypedDict with JSON so I get good hints in my IDE when dealing with complex JSON structures coming in from web APIs.
This includes hints of key names as well as methods to use with the types of data in the structure.
from typing import List, TypedDict
class SubDataTypedDict(TypedDict): id: int name: str widgets: List[int]
class DataTypedDict(TypedDict): id: int subDatas: List[SubDataTypedDict] foo: str
def data_doer(data: DataTypedDict): # using `data` in this function will give me completion on key names # as well as being aware of the types of the values and giving me # completion on relevant methods.
On Wed, May 20, 2020 at 2:52 PM Luciano Ramalho <luciano@ramalho.org> wrote:
I hope you're all well.
I am writing the 2nd edition of Fluent Python and right now I am trying to wrap up a section on typing.TypedDict, but I am having a very hard time understanding its value in real world scenarios.
PEP 589 acknowledges that JSON is a "canonical use case" for dicts used as records. But since the whole point of a TypedDict is to provide syntax for type hints, I can't find a connection or any benefit of using TypedDict with code that deals with JSON—where all the action is at runtime.
All the examples in the PEP use literal dicts as values when assigning to variables annotated with a TypedDict type.
If I annotate a function parameter with a TypedDict, and I am forced to spell out all the keys to provide a dict argument that can be type checked, I don't see why not use keyword arguments in the function definition in the first place...
My testing shows that Mypy is unable to do much validation beyond assignment from dict displays or dict constructor calls with keyword arguments.
More realistic use cases that I was able to imagine often need casts and don't perform any useful static checking.
My future readers and I could really use more insight about real world use cases where TypedDict adds value.
Thanks for any help!
Cheers,
Luciano
-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: dustin.wyatt@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: michael.lee.0x2a@gmail.com
participants (3)
-
Dustin Wyatt
-
Luciano Ramalho
-
Michael Lee