Hi.

Sorry for the misunderstanding. I understand that keep track of the value of
each instance can be cumbersone (and it's not exactly in the scope of a *type*
checker).
Let me focus on the "type definition" of a TypedDict.
Currently with TypedDict you can define all the 'required' or, with
`total=False`, 'possible' keys a dict can have.

I can understand how can be difficult to deal with current "non total" TypedDict,
and how the simple flag takes to a "too coarse" definition, exacerbated in "non
total" TypedDict with a lot of keys that can take to a lot of false positives.

Still, now we are talking about giving a more "precise" definition of what keys
are required, what are possible, and what are simply not present.
How are the implementors suppose to use this additional information?

What I mean is: let's say that now we use the `Required` annotation:

    from typing import TypedDict, Required

    class C(TypedDict, total=False):
        required: Required[int]
        optional: int

    def h(c: C, fallback: int) -> None:
        getitem_required = c['required']
        getitem_optional = c['optional']
        getitem_nonexistent = c['nonexistent']

        get_required = c.get('required, fallback)
        get_optional = c.get('optional', fallback)
        get_existent = c.get('nonexistent', fallback)


I think it's a "waste" to not use the additional explicit annotation and mark as
error, in addition to the `getitem_nonexistent` and `get_existent` examples,
also the `getitem_optional` and the `get_required` rows.

Both the cases are code smell: in the first case is an hidden bug; the second
one is basically dead code.
_______________________________________________
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: guido@python.org