Repository navigation
Expose DataclassInstance #115
Description
Just wanted to track this so that I can update my code if it happens.
There are various times when it's necessary to annotate something as a dataclass including
- functions that accept dataclasses only, and
- and dataclass-makers that return subclasses of dataclass.
Therefore, it would be very convenient to eventually expose DataclassInstance. Suggested here python/typeshed#9362 (comment), and moved to _typeshed here: python/typeshed#9676.
Activity
henryiii commentedon Mar 14, 2023
I'd like it exposed too, as with the latest mypy I'm getting things like:
objecttoAnyisn't bad, but not being able to bindTtoDataclassInstanceis painful!For reference here from the linked issue, it seems there's currently some differences in how this is handled between type checkers (pyright specifically), which is why it's not exposed yet.
AlexWaygood commentedon Mar 14, 2023
There's always the good-old
TYPE_CHECKINGhack (though I appreciate it's ugly):Also it's still pretty new, and new things in the
_typesheddirectory tend to change and/or get removed if we change our minds or think of something better. So it can't really be considered stable yet.JelleZijlstra commentedon Mar 14, 2023
Our general principle is to only add things that are in
typingor in an active PEP. So if you want this, first convince us to add it totypingfor Python 3.12, then we'll also add it here.NeilGirdhar commentedon Mar 14, 2023
One solution would be for
Dataclassto be a class exposed indataclassesthatdataclasses.is_dataclass,__dataclass_fields__, anddataclasses.dataclassin__init_subclass__.What do you think?
JelleZijlstra commentedon Mar 14, 2023
That would mean people can write
class Foo(Dataclass): ..., right? Not sure if I like that; it goes against "there is only one way to do it". It would certainly be a much harder sell than a typing-only protocol.AlexWaygood commentedon Mar 14, 2023
I agree with Jelle -- that sounds like an odd approach to me. I would just do the same thing as we did for
os.PathLike. Just add an ABC todataclasses.py(with a custom__subclasshook__method) at runtime, which in the stubs we say is a runtime-checkable protocol. That way it's in the right module (dataclasses, nottyping), butdataclasses.pydoesn't have its import time slowed down by having to importtyping.Anyway, that whole discussion seems pretty off-topic for this issue tracker, and should probably be discussed over at python/typing (or the CPython issue tracker) rather than here.
NeilGirdhar commentedon Mar 14, 2023
Yes, but that's already baked into the dataclass-maker standard (
typing.dataclass_transform). A dataclass-maker is either a decorator or a class that you can inherit from.Right, that's basically what I'm suggesting, but once you have the ABC, you may as well make directly inheriting from it work as well, no? Also, you don't really need toe
abc.ABCregistration machinery.Sure, where would you like me to post it?
AlexWaygood commentedon Mar 14, 2023
I'd probably suggest adding an
__init_subclass__to make it unsubclassable tbh. It's a conscious design decision that dataclasses uses decorator-based semantics rather than inheritance-based semantics. I agree with Jelle that it would be pretty confusing to make it possible to inherit from adataclasses.DataclassInstanceclass and have this one thing in the module that you can inherit from, whereas everything else works via decorators.CPython works I guess, since the concrete proposal is to add something to the standard library.
JelleZijlstra commentedon Jun 2, 2023
Closing this following the policy to only include things that are in CPython or in a PEP. Let's get it into CPython first.