In early typescript I was too lazy and just set an inital value and then zero the list
Python Type Checker Comparison: Empty Container Inference
21–30 of 59 posts
Re: Python Type Checker Comparison: Empty Container Inference
#22I think it would be worth mentioning that in normal use (strict mode) Pyright simply requires you to add type annotations to the declaration. Occasionally mildly annoying but IMO it's clearly the best option.
It's not "mildly annoying".
I don't enable strict mode on multiple projects because people don't want to type anything outside of function signatures.
Inferring the type from the first use is 100% the correct choice because this is what users want 99% of the time, for the rest you can provide type information.
Re: Python Type Checker Comparison: Empty Container Inference
#23my wishlist for pyrefly: when using decorated functions, show the underlying type hints instead of the decorators
Re: Python Type Checker Comparison: Empty Container Inference
#24Is there a compile-to-Python language with built-in type safety, similar to how TypeScript transpiles to JavaScript? I'm aware of Mojo and mypyc, but those compile to native code/binaries, not Python source.
Python does not need that, as it has built-in type annotation support. The annotation is any expression, so you can in theory express anything a custom type-only language would allow you (although you could make it less verbose and easier to read).
However, the it IMHO just works much worse than TS because: * many libraries still lack decent annotations * other libraries are impossible to type because of too much dynamic stuff * Python semantics are multiple orders of magnitude more complex than JavaScript. Even just the simplest question: Is `1` allowed in parameter typed `float`? What about numpy float64?
Re: Python Type Checker Comparison: Empty Container Inference
#25Earlier quoted context omitted.
> I was reading earlier today about the mess they made of booleans Can you elaborate on that?
Because Python decided that (for the usual New Jersey reason, simplicity of implementation) bool should just be an integer type the Liskov criterion comes into play. If we can X an integer and we've agreed bool is an integer => we can X a bool. That's not what booleans are but hey, it's sorta close and this was easier to implement. So, can we add two bools together? Adding booleans together is nonsense, but we've sai…
> So, can we add two bools together? Adding booleans together is nonsense, but we've said these are a kind of integer so sure, I guess True + True = 2 ? And this cascades into nonsense like ~True being a valid operation in Python and its result is true...
The bitwise negation is indeed janky and inaccurate, but True + True = 2 is absolutely a valid thing to say in boolean algebra. Addition mean "or", and multiplication means "and."
Re: Python Type Checker Comparison: Empty Container Inference
#26My favorite part about the type annotations in python is that it steers you into a sane subset of the language. I feel like it's kind of telling that python is this super dynamic language but the type annotations aren't powerful enough to denote all that craziness.
That's nice if you're starting from scratch, but if you have existing code to deal with, you don't have the privilege of ignoring the insane subset.
Re: Python Type Checker Comparison: Empty Container Inference
#27Earlier quoted context omitted.
> I was reading earlier today about the mess they made of booleans Can you elaborate on that?
Because Python decided that (for the usual New Jersey reason, simplicity of implementation) bool should just be an integer type the Liskov criterion comes into play. If we can X an integer and we've agreed bool is an integer => we can X a bool. That's not what booleans are but hey, it's sorta close and this was easier to implement. So, can we add two bools together? Adding booleans together is nonsense, but we've sai…
This is actually useful in pandas. It enables asking questions like "what percent of cars get greater than 40mph?"
Re: Python Type Checker Comparison: Empty Container Inference
#28Is there a compile-to-Python language with built-in type safety, similar to how TypeScript transpiles to JavaScript? I'm aware of Mojo and mypyc, but those compile to native code/binaries, not Python source.
Python does not need that, as it has built-in type annotation support. The annotation is any expression, so you can in theory express anything a custom type-only language would allow you (although you could make it less verbose and easier to read). However, the it IMHO just works much worse than TS because: * many libraries still lack decent annotations * other libraries are impossible to type because of too much dyn…
Thanks for helping me understand. I wasn't aware of Python's type annotation support. I did some quick research and learned that type annotations don't cause compile errors even when there are type errors. Is that why type checkers like Pyrefly exist?
Re: Python Type Checker Comparison: Empty Container Inference
#29Earlier quoted context omitted.
> I was reading earlier today about the mess they made of booleans Can you elaborate on that?
Because Python decided that (for the usual New Jersey reason, simplicity of implementation) bool should just be an integer type the Liskov criterion comes into play. If we can X an integer and we've agreed bool is an integer => we can X a bool. That's not what booleans are but hey, it's sorta close and this was easier to implement. So, can we add two bools together? Adding booleans together is nonsense, but we've sai…
Out of curiosity, I tried running `~True` in a Python 3.14.2 repl and got this output (the -2 is part of the output):
>>> ~True
:1: DeprecationWarning: Bitwise inversion '~' on bool is deprecated and will be removed in Python 3.16. This returns the bitwise inversion of the underlying int object and is usually not what you expect from negating a bool. Use the 'not' operator for boolean negation or ~int(x) if you really want the bitwise inversion of the underlying int.
-2
Re: Python Type Checker Comparison: Empty Container Inference
#30I think it would be worth mentioning that in normal use (strict mode) Pyright simply requires you to add type annotations to the declaration. Occasionally mildly annoying but IMO it's clearly the best option.
Requiring the annotations on empty containers is the only way to have type safety if the type checker cannot infer the type of the container, like Pyright.
If the type checker can infer a type then the annotation would only be required if the inferred type doesn't match the user's intent, which means one would need to add fewer annotations to an arbitrary working-but-unannotated program to satisfy the type checker.