There is no difference between `object["hello"]` and `object.hello`. So in Typescript, all you need is `interface`, that's it. Everything (except primitives) is just an `interface` with keys or index signatures.
> Of course. With dataclasses that's what Python itself does; that's a pure Python module:
Sorry, I meant that you can't create an equivalent class that typechecks the same way. For example, when you define a dataclass with fields, mypy and pyright are capable of inferring what args and kwargs the constructor supports. But that's because it was implemented as a special case. For example, see the mypy docs [1]. If you just alias `dataclasses`, you lose type support!
Pydantic is a library with similar semantics, and the only way to get typechecking support is to install the pydantic plugin for the typechecker you use. The language simply can't express it.
> There is no difference between `object["hello"]` and `object.hello`.
Ah, ok. Technically I suppose one could unify these in Python; attribute accesses on objects are really dict lookups under the hood, and one could implement a list as a dict whose keys were restricted to be integers. But yes, Python chose not to go that route.
> I meant that you can't create an equivalent class that typechecks the same way.
Well, of course not. If you derive your own class direct from object, even if it's duck type compatible with some other class, it is not a subclass of that other class. That's just how Python's type system works.
> If you just alias `dataclasses`, you lose type support!
You mean you lose some functionality with third party type checking tools. Yes, that's true. (Although that particular limitation, at least, seems odd to me--see below.)
> The language simply can't express it.
No, the language does not have built-in tools that do the things you would like them to do with type checks and type annotations. And the third-party tools apparently don't cover these cases.
The "alias dataclass" case seems odd to me because a simple "is" check ("dataclass_alias is dataclass") should cover it--aliasing the object just means putting a reference to the same object in another namespace, and the "is" operator checks for object identity, not the name it has in any particular namespace.
The "dataclass_wrapper" case would be a good bit more complicated to check for, yes. Although type annotations ought to be able to help, since you can express "this function takes a class as an argument and returns a dataclass derived from that class" in Python type annotations.
> You mean you lose some functionality with third party type checking tools
No, I mean that Python cannot express this relationship with type annotations. That's why plugins are necessary, because the language doesn't support it. I think the same is true for `TypedDict`, which is why the community had to wait for official support before it could be used.
These fundamental limitations of the language prevent the community from effectively building new tools with similar behaviors. You have to either write your own plugin for the n different 3rd party type checking tools, or hope it gets pulled into an official Python version (at which point the n different type checking tools will implement support for you).
Anyways. This started off because of the claim that Python doesn't need typechecking as much because it has a simpler data model than JavaScript (at most, you can claim they are equivalent), but it's turned into gripes about how half-baked the type annotation syntax is. All of this to say: it could have been a contender! It could have been like TypeScript!!
> Python cannot express this relationship with type annotations.
What relationship? That two classes which have no ancestor classes in common happen to be duck type compatible? Yes, Python type annotations can't express that, because there is no type relationship to express.
The way to avoid this problem in Python is to make sure duck type compatible classes have an ancestor class in common. That was a main point of the collections.abc module when it was introduced, to provide actual classes that expressed the duck types that were built into Python (being a subclass of MutableMapping, for example, expresses the fact that a class is duck type compatible with the built-in dict class).
As for "dataclass", it's not a class, it's a function. But the dataclass module provides the "is_dataclass" function that you can call on any class to check whether it's a dataclass. As far as I know, this will detect both your "dataclass_alias" and "dataclass_wrapper" cases. So this function could be used by any tool that wants to check for dataclasses.
> All of this to say: it could have been a contender! It could have been like TypeScript!!
No, it's to say: "I think Python should have done things the way TypeScript does!" But Python is not TypeScript. It's a different language with a different design philosophy. Expecting to use it exactly the way you would use TypeScript is of course not going to work out well, just as expecting to use TypeScript exactly the way you would use Python is not going to work out well.
The typing module is pure Python, so the code for TypedDict in that module could have been implemented by any Python user. The official support is of course nicer, but is not required to extend the functionality of the typing module.
> Of course. With dataclasses that's what Python itself does; that's a pure Python module:
Sorry, I meant that you can't create an equivalent class that typechecks the same way. For example, when you define a dataclass with fields, mypy and pyright are capable of inferring what args and kwargs the constructor supports. But that's because it was implemented as a special case. For example, see the mypy docs [1]. If you just alias `dataclasses`, you lose type support!
Pydantic is a library with similar semantics, and the only way to get typechecking support is to install the pydantic plugin for the typechecker you use. The language simply can't express it.
[1] https://mypy.readthedocs.io/en/stable/additional_features.ht...