In Python, `x = []` should always have a `list[…]` type inferred. In TypeScript and Ruby, the inferred type needs to account for the fact that `x` is valid to pass to a function which takes the empty tuple (empty array literal type) as well as a function that takes an array. So the Python strategy #1 in the article of defaulting to `list[Any]` does not work because it rejects passing `[]` to a function declared as taking `[]`.
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.
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`.
curiousgal•1h ago
IshKebab•1h ago
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!
tialaramex•55m ago
nubg•34m ago
Can you elaborate on that?
IshKebab•5m ago
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.
wiseowise•42m ago