One thing to note I suppose is that `name?` does not mean `T | null` in TS; it means something akin to `T | undefined`. `Required[T?]` might appear contradictory to someone coming from TS and I would personally prefer that the community converges on `T | None` - it's short and clear enough.
Best
D
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 18, 2021 6:30 PM, David Foster
On 1/16/21 7:48 PM, David Foster wrote:
Long story short: I think Required[...] on a total=False TypedDict would be reasonable, given that the total=False syntax already exists. +0.5 Also, Required[...] satisfies: ✅ Single word. Easy to type. ✅ Is in positive form, rather than a "not X" or "no X" negative form. ✅ Does not "put funny syntax before the colon"
Let me play devil's advocate against myself for a moment here...
Let's say we use the form Required[...] only on total=False TypedDict definitions. You could encounter code like:
class MyTypedDict(TypedDict, total=False): foo: Required[str] bar: Required[Optional[int]] baz: Optional[float] qed: bool
Now to someone not intimately familiar with the differences between Required[...] and Optional[...], what kinds of questions or confusion could arise here?
- "It looks like `foo` and `bar` are required keys, and `baz` is an optional key, but what is the `qed` key at the end? Is it required? Is it optional?"
- "But wait a minute! The `bar` key is marked as both required AND as optional! What's going on here?"
A big problem you can see here is that it's very easy to conflate the concept of an "optional key" (no explicit spelling) with the concept of "nullable" (currently spelled Optional[...]).
It seems to me that any great spelling for "optional key" or "required key" (like Required[...]) is going to be significantly confusing so long as the current Optional[...] spelling (1) exists and (2) means "nullable" instead of "optional key".
So let me open a new can of worms: What if we deprecated the spelling Optional[...], replacing it with something like Nullable[...] instead?
My expectation is that PEP 645 ("Allow writing optional types as x?") will eventually phase out in-practice use of Optional[...] anyway, so deprecating the long-form spelling Optional[...] might not be so disruptive.
Now, if Optional[...] is deprecated it is less likely to show up in new user code, so my original code example would become:
class MyTypedDict(TypedDict, total=False): foo: Required[str] bar: Required[int?] baz: float? qed: bool
Here I think the user confusion in the original example goes away. "Required[...]" and "TYPE?" don't even look like the same kind of thing and therefore I expect would be hard to (mistakenly) see as opposites of each other.
(In case folks are wondering, after Optional[...] is deprecated and maybe even removed, I'm NOT presently advocating for eventually bringing it back with the new meaning of "optional key" rather than its current meaning of "nullable". There's probably a lot of content on the internet that already assigns the old meaning to Optional[...], so we can't change it's interpretation without potentially confusing a lot of people who are reading old help resources.)
-- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy
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: layday@protonmail.com