Python Type Checker Comparison: Empty Container Inference (opens in new tab)

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.

The type hints are not even enforced at runtime. They are mostly documentation.

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() < 0.5) {
            arr.push(0)
            return arr
        } else {
            arr.push('0')
            return arr
        }
    }

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)[].

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

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.

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.

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.

> TypeAlias, Generic

This is mitigated by modern (3.12+) generic and `type` syntax, which just looks like any other static language.

I strongly disagree. Python has actually done a decent job of adding type annotations into the language IMO.

If you ignore the bit where they don't actually specify their semantics anyway.

> this can't be the way..

The alternative is fragile and unmaintainable code. I know which I prefer!

What is the way in your opinion?

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?

The only language I'm aware of that's a bit like that is rpython, but it's the other way round: designed for python to compile to it. If you think about it, you get more benefit from the typed language being the base one, as the compiler or JIT can make more assumptions, producing faster code . Typescript had no alternative but to do it the other way, since it's a lot harder to get things adopted into the browser than to ship them independently.

You can compile F# to Python with Fable https://github.com/fable-compiler/Fable.Python

It's actually a fairly frequent fact of programming language development that type resolution can change across versions. Haskell famously has a ton of extensions that enhance the type system in various, potentially incompatible ways.

In fact the question of whether a code type-checks is itself undecidable.

If you're referring to the `first_three_lines` example in strategy 3, Mypy would give the same error even if we changed the return value to something unrelated like `return ["something"]`.