Literal type alternative syntax
Hello all, Why can’t we use the literals directly as types? For example, x: Literal[1, 2, 3] = 3 name: Literal[“John”] | None = “John" Become …. x: 1 | 2 | 3 = 3 name: “John” | None = “John" def open(file: Path | str, mode: “w” | “a” = “w”): … Best Regards, Abdulla
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() @click.option(“--direction”, type=click.Choice((“North”, “South”, “West”, “East”)), default=“North”) def main(direction: “North” | “South” | “West” | “East” = “North”) -> None: print(direction)
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 runtime, we'd have no idea what the alternatives so expressed were. On Sat, Feb 5, 2022, 2:24 PM Abdulla Al Kathiri <alkathiri.abdulla@gmail.com> 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 coat Union? Maybe if integers or strings or any other literal occurs after “:”, we could treat them slightly differently than what their actual __or__ and __ror__ would normally do?
On Sun, Feb 06, 2022 at 02:13:59AM +0400, Abdulla Al Kathiri wrote:
Type objects are objects, and their behaviour is controlled by their metaclass, just as instances are objects and their behaviour is controlled by their class. That means we can do this:
What we can't do is have instances behave differently according to context. There is no way to have the `|` operator behave differently in different contexts: value = 1 | 8 # return 9 T = 1 | 8 # return Literal[1, 8] L = [0, 1 | 8, 2] # what should | do inside a list? arr[:1 | 8] # what about after a colon in a slice?
Fortunately the Steering Council has said that syntax in annotations and syntax outside of annotations will remain the same. So any expression that you can write in an annotation will have the same meaning if you take it out and assign it to a named type. In other words, we can always refactor type hints by moving them out of the annotation: x: expression = value T = expression x: T = value And that is excellent. -- Steve
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 because you are familiar with the CPython internals.
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 +0400, Abdulla Al Kathiri wrote:
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.
`1 | 2 | 3` already has a meaning as the bitwise-or of integers 1, 2, 3 and so it evaluates to `3`. So backwards compatibility rules out changing the | operator meaning. Other types don't support bitwise-or, and we don't want them to. E.g. bitwise-or of a string and None, or two strings, or a string and an int, should remain errors and not suddenly return a type object. The bottom line here is that we cannot use literals as types because they aren't types, they are values, and the semantics of operations on types and operations on values are different. -- Steve
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() @click.option(“--direction”, type=click.Choice((“North”, “South”, “West”, “East”)), default=“North”) def main(direction: “North” | “South” | “West” | “East” = “North”) -> None: print(direction)
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 runtime, we'd have no idea what the alternatives so expressed were. On Sat, Feb 5, 2022, 2:24 PM Abdulla Al Kathiri <alkathiri.abdulla@gmail.com> 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 coat Union? Maybe if integers or strings or any other literal occurs after “:”, we could treat them slightly differently than what their actual __or__ and __ror__ would normally do?
On Sun, Feb 06, 2022 at 02:13:59AM +0400, Abdulla Al Kathiri wrote:
Type objects are objects, and their behaviour is controlled by their metaclass, just as instances are objects and their behaviour is controlled by their class. That means we can do this:
What we can't do is have instances behave differently according to context. There is no way to have the `|` operator behave differently in different contexts: value = 1 | 8 # return 9 T = 1 | 8 # return Literal[1, 8] L = [0, 1 | 8, 2] # what should | do inside a list? arr[:1 | 8] # what about after a colon in a slice?
Fortunately the Steering Council has said that syntax in annotations and syntax outside of annotations will remain the same. So any expression that you can write in an annotation will have the same meaning if you take it out and assign it to a named type. In other words, we can always refactor type hints by moving them out of the annotation: x: expression = value T = expression x: T = value And that is excellent. -- Steve
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 because you are familiar with the CPython internals.
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 +0400, Abdulla Al Kathiri wrote:
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.
`1 | 2 | 3` already has a meaning as the bitwise-or of integers 1, 2, 3 and so it evaluates to `3`. So backwards compatibility rules out changing the | operator meaning. Other types don't support bitwise-or, and we don't want them to. E.g. bitwise-or of a string and None, or two strings, or a string and an int, should remain errors and not suddenly return a type object. The bottom line here is that we cannot use literals as types because they aren't types, they are values, and the semantics of operations on types and operations on values are different. -- Steve
participants (4)
-
Abdulla Al Kathiri -
David Mertz, Ph.D. -
Paul Bryan -
Steven D'Aprano