Live data from Hacker News

Python Type Checker Comparison: Empty Container Inference

pyrefly.org

11–20 of 59 posts

Re: Python Type Checker Comparison: Empty Container Inference

#11

I can't help but find type hints in python to be..goofy? I have a colleague who has a substantial C++ background and now working in python, the code is just littered with TypeAlias, Generic, cast, long Unions etc.. this can't be the way..

What is the way in your opinion?

Re: Python Type Checker Comparison: Empty Container Inference

#12

I can't help but find type hints in python to be..goofy? I have a colleague who has a substantial C++ background and now working in python, the code is just littered with TypeAlias, Generic, cast, long Unions etc.. this can't be the way..

Typing is a relatively easy way for the human author and the machine to notice if they disagree about what's going on before problems arise. It is unfortunate that Python doesn't do a good job with types, I was reading earlier today about the mess they made of booleans - their bool type is actually just the integers again.

> I was reading earlier today about the mess they made of booleans

Can you elaborate on that?

Re: Python Type Checker Comparison: Empty Container Inference

#13
post #8

FWIW, Typescript is using Strategy 2: https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABM... I'm a bit confused by the fact that the array starts out typed as `any[]` (e.g. if you hover over the declaration) but then, later on, the type gets refined to `(string | number)[]`. IMO it would be nicer if the declaration already showed the inferred type on hover.

It depends on your tsconfig. An empty array could be typed as never[], forcing you to annotate it.

I don't believe this is correct. There's no settings that correspond to that AFAIK, and it'd actually be quite bad, because you could access the empty array and then get a `never` object, which you're not supposed to be able to do.

https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABM...

`unknown[]` might be more appropriate as a default, but TypeScript does you one better: with OP's settings, although it's typed as `any[]`, it'll error out if you don't do anything to give it more information because of `noImplicitAny`.

Re: Python Type Checker Comparison: Empty Container Inference

#14
post #12

Earlier quoted context omitted.

Typing is a relatively easy way for the human author and the machine to notice if they disagree about what's going on before problems arise. It is unfortunate that Python doesn't do a good job with types, I was reading earlier today about the mess they made of booleans - their bool type is actually just the integers again.

> I was reading earlier today about the mess they made of booleans Can you elaborate on that?

He did - booleans are integers:

  >>> isinstance(False, int)
  True
A related screw-up is implicitly casting everything to bool. A lot of languages made that mistake.

Overall I'd say they didn't do an awful job though. The main problems with Python are the absolutely abysmal tooling (which thankfully uv fixes), the abysmal performance (which sometimes isn't an issue, but it usually becomes an issue eventually), and the community's attitude to type checking.

Actually type checking code you've written yourself with Pyright in strict mode is quite a pleasant experience. But woe betide you if you want to import any third party libraries. There's at least a 50% chance they have no type annotations at all, and often it's deliberate. Typescript used to have a similar problem but the Javascript community realised a lot quicker than the Python community that type hints are a no-brainer.

Re: Python Type Checker Comparison: Empty Container Inference

#15
post #12

Earlier quoted context omitted.

Typing is a relatively easy way for the human author and the machine to notice if they disagree about what's going on before problems arise. It is unfortunate that Python doesn't do a good job with types, I was reading earlier today about the mess they made of booleans - their bool type is actually just the integers again.

> 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 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...

Re: Python Type Checker Comparison: Empty Container Inference

#16
post #8

FWIW, Typescript is using Strategy 2: https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABM... I'm a bit confused by the fact that the array starts out typed as `any[]` (e.g. if you hover over the declaration) but then, later on, the type gets refined to `(string | number)[]`. IMO it would be nicer if the declaration already showed the inferred type on hover.

I agree, it's always been unsettling to see any[] on hover, even though it gets typed in the end.

I think one reason might be to allow the type to be refined differently in different code paths. For example:

    function x () {
        let arr = []
        if (Math.random() 
In each branch, arr is typed as number[] and string[], respectively, and x's return type is number[] | string[]. If it decided to retroactively infer the type of arr at declaration, then I'd imagine x's return type would be the less specific (number | string)[].

Re: Python Type Checker Comparison: Empty Container Inference

#19
post #12

Earlier quoted context omitted.

Typing is a relatively easy way for the human author and the machine to notice if they disagree about what's going on before problems arise. It is unfortunate that Python doesn't do a good job with types, I was reading earlier today about the mess they made of booleans - their bool type is actually just the integers again.

> I was reading earlier today about the mess they made of booleans Can you elaborate on that?

It's not entirely fair.

Prior to 2.3 Python didn't have booleans, just "truthiness". In 2.3 they added the Boolean class as a subclass of int (because of patterns of development it was a pragmatic choice). True and False were introduced, but they were able to be reassigned which could cause all manner of fun. 3.x made them keywords which put a stop to that but the int aspect remained.

Post reply on HN