Thank you Steven for the explanation. I like that the behaviors in annotation
or outside it are the same. It makes sense and it’s easier to teach and learn.
Maybe it’s not a good idea after all even though visually it makes sense to me
as a normal python user. You guys see things differently
On Sun, Feb 06, 2022 at 02:13:59AM +0400, Abdulla Al Kathiri wrote:
> The “|” operator is another way of doing Union[Literal[“John], None]
> which is already supported in the new versions of Python. Correct me
> if I am wrong please. Maybe the types already use __or__ and __ror__
> to sugar
Why do we have Literal type in the typing module? I sure can use them as types
to indicate to the user "these are your only options”?
> On 6 Feb 2022, at 2:18 AM, Steven D'Aprano wrote:
>
> he bottom line here is that we cannot use literals as types because
> they aren't types, they are
On Sat, Feb 05, 2022 at 11:21:48PM +0400, Abdulla Al Kathiri wrote:
> Hello all,
>
> Why can’t we use the literals directly as types? For example,
Before suggesting a new feature, you should try it to see what it
currently does.
>>> x: 1 | 2 | 3 = 4
>>> __annotations__
{'x': 3}
`1 | 2 | 3`
The “|” operator is another way of doing Union[Literal[“John], None] which is
already supported in the new versions of Python. Correct me if I am wrong
please. Maybe the types already use __or__ and __ror__ to sugar coat Union?
Maybe if integers or strings or any other literal occurs after “:”,
I thought since we now can forward reference types in the new parser, there is
no need to stringify forward types but as you and the rest mentioned this might
introduce compatibility issues with the older versions.
> On 6 Feb 2022, at 1:18 AM, Paul Bryan wrote:
>
> I like the idea, quite a
I like the idea, quite a bit. Unfortunately, string annotations are
currently reserved for type annotations (particularly for forward
references), so`x: str` and `x: "str"` are currently equivalent. This
would rule-out using string literals in the manner you suggest.
On Sat, 2022-02-05 at 23:21
To do this EVERY object that you might list as alternatives would have to
support `__or__()` and `__ror__()`.
Moreover, for many types, `|` is defined with conflicting meaning. E.g. `3
| 5 | 11 == 15`. But of course 3, 5, 11 aren't the unique collection of
numbers that bitwise or to 15. At
I was trying to write a click option argument with type=click.Choice((“North”,
“South”, “West”, “East”)) and I also like to annotate the function itself for
documentation (even though I call it without passing arguments). Something like
the the following..
@click.command()
