Honestly I'm not keen on this type of solution. No matter what we do,
unless we introduce new *syntax* (e.g. `age?: int`) we're already making a
statement about the *variable* in the form of a statement about the *type*.
We have precedents for that, but they are things like `Final[...]` and
`ClassVar[...]`, and I think it would be better to continue along that
line. We can make a simple rule that "Required" (for example) may only
appear at the top level in a typed dict -- this seems simpler than a rule
that says "one branch of a union can be a magic cookie, but only at the top
level".
In terms of perceived economy, regardless of whether we reuse an existing
keyword or add a new one, the behavior for this particular case has to be
learned and implemented separately, so I don't think we're saving much by
avoiding a new keyword. (If we could reuse it would be a little different,
but we clearly can't.)
On Mon, Jan 11, 2021 at 10:40 AM Jelle Zijlstra
El lun, 11 ene 2021 a las 10:32, Daniel Moisset (
) escribió: Sorry if I add to bikeshedding, but would it make sense to have `Missing` special value that's used by Union? i.e. you'd write:
class Person(TypeDict): name: str date_birth: date date_death: date|Missing
Even from an internal typechecker standpoint I think it would make formal sense to say that {"name": "Alex"}["not_a_name"] has type Missing, and many rules on unions would work seamlessly and coherently.
Perhaps `typing.NoReturn` could be used for this purpose too.
On Sat, 9 Jan 2021 at 16:49, Tuukka Mustonen
wrote: But "required" is the default -- you have to specify total=False to make fields non-required.
Yeah, required is the default. But the convenience syntax that we're discussing here wouldn't work with that. Having to specify `total=False` and then `Required` for required fields is not intuitive. It would be a good addition and a workaround, but it doesn't fulfill the need here.
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.
I also think most proposals look ugly. However, I'm not sure if it makes sense to reject a feature just because perfect wording cannot be found? People who can't live with the name could create an alias anyway, like:
O = NotRequired
That's probably what I would do - not to avoid ugliness but simply to make the syntax less verbose.
Sure, I could do the same with `R = Required` but it doesn't fix the problem of having to think about it "the other way around".
Let's just not put funny syntax before the colon.
Is it silly? If we consider typescript-like syntax again:
interface Data { opt?: str opt: str? }
The first one reads as "opt may be there?" while the second one reads as "type may be string?". Doing `NotRequired[str]` reads as "type may be string but doesn't have to be" or perhaps as "type is not required but may be string". _______________________________________________ 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: dfmoisset@gmail.com
_______________________________________________ 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: jelle.zijlstra@gmail.com
_______________________________________________ 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
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...