If we want the marker to go on the not-required keys, a possible singe-word positive bikeshed is Excludable

   class MyThing(TypedDict, total=True):
        req1: int
        opt1: Excludable[str]
        req2: float

On Sat, 16 Jan 2021 at 19:48, David Foster <davidfstr@gmail.com> wrote:
Catching up...

On 1/8/21 11:51 AM, Guido van Rossum wrote:> On Thu, Jan 7, 2021 at
11:35 PM David Foster <davidfstr@gmail.com
 > <mailto:davidfstr@gmail.com>> wrote:
 >
 >     A1. On 1/6/21 3:54 AM, Tuukka Mustonen wrote:
 >       > Why I am after something else than your earlier proposal of:
 >       >
 >       >      class MyThing(TypedDict, total=False):
 >       >          req1: Required[int]
 >       >          opt1: str
 >       >          req2: Required[float]
 >       >
 >       > ...is that people _expect_ it to work the other way around.
It feels
 >       > more natural if the stuff you define is expected to exist,
and you then
 >       > mark up what differs from that. That's how ~everything else
already
 >       > works and I would say that's how our brain are already tuned.
 >
 >     Agreed. I would think "required" would be assumed to be the default,
 >     and "not-required" would be the special case that needs marking.
 >
 > But "required" *is* the default -- you have to specify `total=False` to
 > make fields non-required.

I think I've finally wrapped my head around this comment. In long-form:

* If you have a TypedDict with total=True (the default), then all keys
are required.
* If you have a TypedDict with total=False, then all keys become
not-required by default.
* Therefore introducing a Required[...] form is a backward-compatible
way of marking certain keys of a total=False TypedDict as *required*,
which currently isn't possible to do.

It bends my brain a bit: If I want to create an entirely new TypedDict
with some keys required and some keys not-required then I must:
(1) declare a total=False TypedDict and
(2) explicitly mark the keys I want required with Required[...] and
(3) remember that in this context all unmarked keys are NOT-required.

(This is backwards from TypeScript which essentially always declares
TypedDicts as total=True but then only marks certain keys as
NOT-required using the "name?: type" syntax.)

I suppose total=False TypedDicts bend my brain a bit anyway: It strikes
me as odd that a single keyword at the top can flip the default
required-ness of every key in the dictionary. However the total=False
syntax is here now and I don't think it's going away, so we might as
well work with it.

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"

--
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: hauntsaninja@gmail.com