3 ms·

> Everything is an object in Python too. Ah yes, true. JavaScript goes one step further though, and has no distinction between get-item accesses and attribute

> Everything is an object in Python too. Ah yes, true. JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. This makes TypeScript's data model much simpler to manage. Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? I know the latter requires custom plugins.

pdonis 4y ago
> JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. Can you explain a bit more about what you mean here? > Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? Of course. With dataclasses that's what Python itself does; that's a pure Python module: https://github.com/python/cpython/blob/3.11/Lib/dataclasses.py https://github.com/python/cpython/blob/3.11/Lib/dataclasses.... For MutableMapping, Python currently implements it as a C class for speed, but you could implement the same functionality in pure Python. That's what earlier versions of the collections.abc module did. > I know the latter requires custom plugins. I don't know what you mean here. See the pure Python module that Python itself provides above.
- phailhaus 4y ago
  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. [1] https://mypy.readthedocs.io/en/stable/additional_features.html#caveats-known-issues https://mypy.readthedocs.io/en/stable/additional_features.ht...
  - pdonis 4y ago
    > 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.
    - phailhaus 4y ago
      > 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!!
- deleted 4y ago
  [deleted]

pdonis 4y ago

> JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. Can you explain a bit more about what you mean here? > Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? Of course. With dataclasses that's what Python itself does; that's a pure Python module: https://github.com/python/cpython/blob/3.11/Lib/dataclasses.py https://github.com/python/cpython/blob/3.11/Lib/dataclasses.... For MutableMapping, Python currently implements it as a C class for speed, but you could implement the same functionality in pure Python. That's what earlier versions of the collections.abc module did. > I know the latter requires custom plugins. I don't know what you mean here. See the pure Python module that Python itself provides above.

phailhaus 4y ago
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. [1] https://mypy.readthedocs.io/en/stable/additional_features.html#caveats-known-issues https://mypy.readthedocs.io/en/stable/additional_features.ht...
- pdonis 4y ago
  > 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.
  - phailhaus 4y ago
    > 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!!
deleted 4y ago
[deleted]