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.
B1. On 1/6/21 3:54 AM, Tuukka Mustonen wrote:
> opt1: NotRequired[str] # or whatever we call it
I actually like NotRequired.
It's pretty ugly (though there's a precedent, `NoReturn` for functions that don't return). It's also long and difficult to type due to the camelcase.
If there were a better word I'd be okay with doing it this way around, but NotRequired just doesn't cut it for me. Hence my proposal.
However I can also see some objections:
* It feels a bit odd to bless a term that starts with "not", in negative
form rather than some positive form.
* A one-word term seems preferable over a two-word term like NotRequired.
What I said. :-)
B2. On 1/5/21 12:03 AM, Tuukka Mustonen wrote:
> Droppable
Mmm. The Rustacean in me thinks this means "deallocatable" which isn't
correct here. -1
> Potential
Mmm. Feels too vague. -1
> Open
Mmm. Feels like you could apply "open" to an entire class/structure, but
not to an individual member. -1
B3. I will also contribute a few bikeshed colors:
* OptionalKey
* MissingOk
C1. On 1/5/21 12:03 AM, Tuukka Mustonen wrote:
> So should we instead:
>
> class MyThing(TypedDict):
> Optional[opt1]: str # may not exist, but if exists, value
is string
> opt2: Optional[str] # always exists, but may have null value
>
> That would maybe allow to re-use `Optional` as it would exist in
different context (don't know how confusing that would be). But this
probably doesn't fit the design and the parser?
Interesting. I like how this looks, and it doesn't require us to
introduce a new (key-only) synonym for Optional.
But as you say it's not clear to me how it would be parsed exactly.
Also, we already have precedent from Final[] and Annotated[] that
suggests that properties of a variable (as opposed to properties of the
value shape) still be put into the type hint that wraps the other
component of the type that contains the value shape.
C2. If we *do* wrap the right-hand-side rather than the left-hand-side,
any spelling we have for "the key for this value can be missing" must
also support interacting with the existing Optional spelling without
looking too strange. For example:
class MyThing(TypedDict):
opt: OptionalKey[Optional[str]]
class MyThing(TypedDict):
opt: MissingOk[Optional[str]]
class MyThing(TypedDict):
opt: NotRequired[Optional[str]]
The last example above in particular looks pretty strange to me.
Let's just not put funny syntax before the colon.