On Thu, Jan 7, 2021 at 11:35 PM David Foster firstname.lastname@example.org 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.
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:
Mmm. The Rustacean in me thinks this means "deallocatable" which isn't correct here. -1
Mmm. Feels too vague. -1
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:
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
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.