Oh neat! And what happens if you say Literal[3]? Please tell me it requires a static proof that that argument is 3 (-: [assuming the actual parameter is not `3`].
Replies
Oh! I’m lost :(
apr 3, 2025, 6:32 pm • 1 0 • view
We’re working on it!! (Or at least, @sharkdp.bsky.social is…) playknot.ruff.rs/122d0dfe-b76...
apr 4, 2025, 12:34 am • 4 0 • view
Wow, that's cute, and fast!
apr 4, 2025, 1:13 am • 2 0 • view
For a second I thought this was a release announcement.
apr 4, 2025, 1:57 am • 1 0 • view
Yes! I try to use ruff on every new Python project I start these days!
apr 4, 2025, 1:26 am • 1 0 • view
uv + ruff is a winning combo
apr 4, 2025, 9:27 am • 1 0 • view
well, seems like it only accepts literally the syntactic literal expression '3'
![import typing def f(x: typing.Literal[3]): print(x) f(3) f(4) x = 3 f(x)](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:j7ri4agbraq6g3dfmyccxep2/bafkreidk4suybpmsx6yqrk6vzukq2d4guxtpny5ru5lndgw7vc2r65l6sq@jpeg)
apr 3, 2025, 3:36 pm • 6 0 • view
For re-assignable names, instead of inferring the type from the union of types of *all* assignments to it, some inferencers only consider assignments that aren't preceded by another assignments and then broaden to a single named type. Maybe that's what's happening here.
![Screenshot of python code in an editor. Text follows: if a: x = 1 # Raised to int else: x = None f(x) if b: x = 2 # Ignored since after assignment # Instead of x inferred as having type # Optional[Literal(1) | Literal(2)], # x has type # Optional[int]](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:xnx52zdoyuf777kntfughiwa/bafkreigzr2f55gh2fa2u3zvjnxwywbazuoz36jnaykamynahwgqp25slo4@jpeg)
apr 3, 2025, 3:51 pm • 3 0 • view
yes but that would still infer type `Literal[3]` for `x` in `x = 3` right? (which mypy infers as `int`)
apr 3, 2025, 4:00 pm • 2 0 • view
Not if the inferencer always broadens to a *named* type. Without an explicit __all__, x is exported from the module, so inferring tight type bounds entails a backwards-compatibility commitment. For VERSION = "1.0" you wouldn't want to infer Literal("1.0") for VERSION.
apr 3, 2025, 4:09 pm • 3 0 • view
Line 10 is accepted by Pyright. Unfortunately, this specific case is not handled by the specification:
apr 4, 2025, 8:43 am • 4 0 • view
Thanks for all the experiments!
apr 3, 2025, 5:41 pm • 3 0 • view
does it work with x: Literal[3] = 3? (I'm too lazy to spin up a Python env to test that myself :P)
apr 3, 2025, 4:06 pm • 4 0 • view
yes! not sure how you would narrow a generic int though (if x == 3 doesn't seem to narrow anything)
apr 3, 2025, 4:09 pm • 5 0 • view
oh i guess it makes sense that it doesn't infer it to Literal[3] without a type signature since variables are mutable
apr 3, 2025, 4:11 pm • 5 0 • view
haha, yeah, I tend to forget about that too :P
apr 3, 2025, 4:57 pm • 4 0 • view
I've already completely solved the actual problem at hand and moved on in the time it's taken to discuss this type issue.
apr 3, 2025, 3:37 pm • 4 0 • view
That's only because you have completely misunderstood the problem, which is that, once a type system is present, the goal is to understand the type system, not to actually write and run code. Don't feel bad, it's a common rookie error. You should take a PL course sometime.
apr 3, 2025, 5:43 pm • 10 1 • view
Bloody hell. I already know regex so what else could it possibly involve?
apr 3, 2025, 6:01 pm • 4 0 • view
regexes can't help us make sense of irregular expressions like `def foo(x: 3):`
apr 3, 2025, 6:03 pm • 1 0 • view
Sure it does. If a regexp can handle HTML it can handle anything.
apr 3, 2025, 9:17 pm • 3 1 • view
Can confirm.
apr 3, 2025, 10:33 pm • 2 0 • view
Why do I feel like a complete pumpkin everytime I talk to you, @shriram.bsky.social??
apr 3, 2025, 11:23 pm • 1 0 • view
Because you're secretly Cinderella?
apr 4, 2025, 12:05 am • 1 0 • view