-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Literal type math #11990
Comments
I presume this is intended to work generally for any expression that involves these types, not only expressions that are used as arguments to a: int
a = 1 + 2
reveal_type(a) # Literal[3] You might want to consider adding For |
Out of curiosity, are you planning to support unions? def func1(a: Literal[1, 2], b: Literal[0, 4], c: Literal[3, 4]):
reveal_type(a * b + c) # Literal[3, 4, 7, 8, 11, 12]?
def func2():
greeting = "Hi " + ("Steve" if random() > 0.5 else "Amy")
reveal_type(greeting) # Literal["Hi Steve", "Hi Amy"]? |
One challenge to consider... If you're evaluating types in a loop, you need to be careful about literal math. def func1(loop_count: int):
x = 1
reveal_type(x) # Literal[1]
x = x + 1
reveal_type(x) # Literal[2]
for _ in range(loop_count):
x = x + 1
reveal_type(x) # int |
I think this is a good feature idea, so I implemented it in pyright. If you haven't already completed your PR for mypy, perhaps I can save you some time by sharing the unit tests I wrote. |
Could |
You of course need to trust the code you run your LSP on, but what is the handling for bad input? Intentionally trying to OOM: from typing import Literal
fifty_primes = Literal[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229]
def func(
a: fifty_primes,
b: fifty_primes,
c: fifty_primes,
d: fifty_primes,
e: fifty_primes,
f: fifty_primes,
g: fifty_primes,
h: fifty_primes,
i: fifty_primes,
j: fifty_primes,
k: fifty_primes,
l: fifty_primes,
):
reveal_type(a * b * c * d * e * f * g * h * i * j * k * l) I'm not sure how possible it is to accidentally create such a situation though. |
Thanks! I haven't touched unary operations right now. But, they are on the list!
Yes, this is a plan. In case of any problems / errors we escape from
Thank you, @erictraut!
Yes, looks like a good unit-test.
They are not supported right now. Probably in the future 🙂
Yes, I also tought about that. But, right now the logic is that type never changes for both operands. |
TODO:
|
Strings explode a bit more easily in similar fashion if they're added a few times. Intended to OOM: from typing import Literal
mode = Literal["a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","z","y","z"]
def func(
a: mode, b: mode, c: mode, d: mode, e: mode, f: mode, g: mode, h: mode, i: mode
):
reveal_type(a + b + c + d + e + f + g + h + i) EDIT: This is far too much unneeded work, but I was thinking you can probably handle these cases without bailing to |
@GBeauregard we don't support union type at the moment, but this is going to be a great corner-case in the future! 🎉 |
@GBeauregard, that test case is evil! I love it. :) |
I am working on feature where
reveal_type(1 + 2)
will revealLiteral[3]
.Types that I want to support:
int
str
bool
And these operations:
So,
True or False
is revealed asLiteral[True]
.I will finish some test later today and send a PR in the morning.
The text was updated successfully, but these errors were encountered: