Comments inline: On Fri, 2022-08-05 at 00:19 +0000, Buck Evan wrote:
When I first stubbed my toe on dataclass typing the code I tried was this:
``` def mydataclass(...): ... return dataclasses.dataclass(...)
mydataclass = typing.cast('dataclasses.dataclass', mydataclass) ```
I see now that this was wrong and naive, but perhaps you can see my intent there. I was trying to hint the type system that it should treat mydataclass exactly as it treats `@dataclass`.
You can in fact define your own `mydataclass` function that wraps the `dataclass` decorator function, and then decorate your own classes with `@mydataclass`. This is probably not your intent here though. In your example, I also do not understand why you're trying to cast your `mydataclass` function as the `dataclass` decorator; `dataclass` is not a type, it's a function.
Do any of you see value in making such a thing work? It would solve a address a good deal more problems than PEP-681, in that it could help with custom properties, custom Enum, and the list goes on.
I don't yet precisely understand what you're trying to make work. Are you trying to provide a hinting system for (static) type checkers that says, "pretend my X here is in fact a Y"?
More concretely, I propose a `typing.cast_by_value` (naming is hard) that will have the semantics of replacing itself with its first argument, as far as typechecking is concerned. This adds missing and needed functionality, because it's currently impossible to create anything other than `__builtins__.property` that is treated exactly like `__builtins__.property` by typechecking, especially in a standards-based way that will reliably work across type checking implementations. If my `property` example is a bad one, please use the strongest of these examples: `enum.Enum`, `dataclasses.dataclass`, `namedtuple`, `NamedTuple`.
Paul