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