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 <jelle.zijlstra@gmail.com> wrote:


El lun, 11 ene 2021 a las 10:32, Daniel Moisset (<dfmoisset@gmail.com>) 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 <tuukka.mustonen@gmail.com> 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?)