Expose DataclassInstance

[NeilGirdhar]

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 #9362 (comment), and moved to _typeshed here: #9676.

[AlexWaygood]

I'm not sure we can expose it any more than we already have. _typeshed is where we put our types that may also be useful for external consumers. The reason why _typeshed is prefixed with an underscore is because the folder doesn't exist at runtime, so it's only importable inside an if TYPE_CHECKING block.

After the protocol has been around for long enough to be considered stable, we can maybe consider adding it to typing/typing_extensions. But I don't think we should do that now; and when it has been around for long enough for it to be considered stable, that conversation will need to happen over at the CPython/typing_extensions repos rather than here.

[NeilGirdhar]

After the protocol has been around for long enough to be considered stable, we can maybe consider adding it to typing/typing_extensions. But I don't think we should do that now;

Yes, I understand. This is just for tracking purposes so that if it is exposed one day, I'll know to update my code.

[AlexWaygood]

This is just for tracking purposes so that if it is exposed one day, I'll know to update my code.

Okay, but there's nothing actionable for typeshed here, so I'm going to close this for now — sorry, but it's nice to keep our issue list somewhat under control :)

https://github.com/python/typing might be a better place to open an issue to discuss finding a long-term home for this protocol, whether it's CPython, typing_extensions, or some other place entirely :)

[gandhis1]

I don't know how much visibility my comment here is going to get, but I personally have had multiple instances where I've wanted to accept a DataclassInstance. Typically I do something with the object being passed in, such as call dataclasses.fields on it. I didn't realize this was importable through if TYPE_CHECKING, so I ended up copying the protocol to a local utility module. I suspect I'm not the only one writing code like this, and I imagine it could be useful to others if it was exposed in a simple way that is importable both at type-checking time and at runtime.

While this anecdote doesn't add much to this conversation, I find that frequently in the typing community features are dismissed as lacking sufficient interest when people don't post about them, belying the actual amount of interest in them.

[srittau]

@AlexWaygood I propose we move this to python/typing and reopen, since while there is nothing actionable for typeshed, this is a potential typing feature.

[AlexWaygood]

The protocol is now exposed at runtime via https://github.com/hauntsaninja/useful_types, @gandhis1, which is designed as a minimal third-party package exposing typeshed protocols at runtime that are useful to users, and which are possible candidates for inclusion in the CPython standard library in the future. I'm a maintainer of the package, as is @hauntsaninja and @JelleZijlstra -- all three of us are maintainers of typeshed, typing_extensions and CPython.

python/cpython#102699 is a CPython issue that is already open that discusses potentially adding this protocol to the CPython standard library. (I'm open to the idea, but I'd want it to stew for a while longer in useful_types before doing so, to see if it achieves widespread adoption, and/or to see if there are any issues with it.)

I'm not sure opening another issue at python/typing would be helpful at this point -- I feel like it existing in useful_types + the CPython issue should cover everything important? :)