Types module doesn't have a type for _abc_data

It's implementation detail of abc.  I don't want expose it in public.
(Note that we maintain pure Python version of abc module too.)

Why you need it in types module?
I don't think all types exposed via types module.  Only useful types should be exposed.

I'm working on a project that is a custom byte code interpreter for some
extended types. I needed ABCData there and i thought types module already
has that, but i was wrong so i added.

Isn't types module exposing some types that are implementation detail such
as cells?

On Wed, May 1, 2019, 12:17 PM Inada Naoki <report@bugs.python.org> wrote:

>
> Inada Naoki <songofacandy@gmail.com> added the comment:
>
> It's implementation detail of abc.  I don't want expose it in public.
> (Note that we maintain pure Python version of abc module too.)
>
> Why you need it in types module?
> I don't think all types exposed via types module.  Only useful types
> should be exposed.
>
> ----------
> nosy: +inada.naoki
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue36764>
> _______________________________________
>

> I'm working on a project that is a custom byte code interpreter for some
extended types.  I needed ABCData there

I still don't understand why you need _abc_data.


> Isn't types module exposing some types that are implementation detail such as cells?

cell object is implementation detail of CPython core.
While other Python implementations will not have it, it is long lived in CPython and it is stable.

On the other hand, _abc_data is implementation detail of extension module, not interpreter.

For example, _json.Encoder is not exposed in types module.
If it is really needed, type of _abc_data can be exposed via _abc module.
But I prefer keep internal data opaque unless there are reasonable reason.

> I still don't understand why you need _abc_data.
I'm using it both for comparisons which needed to build an abstract base class and typing. Currently there are 2 ways, i need to create a dummy abc and put type() calls everywhere or i need to set a constant to my module and _abc_data is totally irrelevant with this. I dont think users want that.

> On the other hand, _abc_data is implementation detail of extension module, not interpreter.
Abstract base classes can be called a core part of python too and when someone needs to obtain type of the struct that holds state of ABCs it shouldnt be hard, types module should expose it.

> I'm using it both for comparisons which needed to build an abstract base class and typing. Currently there are 2 ways, i need to create a dummy abc and put type() calls everywhere or i need to set a constant to my module and _abc_data is totally irrelevant with this. I dont think users want that.

It doesn't make sense to me.  Could you elaborate?


> Abstract base classes can be called a core part of python too

abc is core part.  But note that _py_abc can be used instead of _abc.
_abc_data is used only when _abc is used as backend of abc.
At least, your pull request doesn't work correctly when _py_abc is used.


>  and when someone needs to obtain type of the struct that holds state of ABCs it shouldnt be hard, types module should expose it.

I think it is bad idea and we don't support such usage officially at all.
Such code doesn't work when _py_abc is used.

It is based on default behavior of cpython. It tries to import _abc first instead of _py_abc and this type targets c implementation.

We can try to obtain the type of ABCData and if we can't (if py_abc is
used) we can set ABCData to NotImplemented.

On Wed, May 1, 2019, 2:56 PM Batuhan <report@bugs.python.org> wrote:

>
> Batuhan <batuhanosmantaskaya@gmail.com> added the comment:
>
> It is based on default behavior of cpython. It tries to import _abc first
> instead of _py_abc and this type targets c implementation.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue36764>
> _______________________________________
>

You didn't explain why people not only you need it.
"Could you elaborate?"

Unless clear use cases, I'm strong -1 on adding it in typing module.

I concur with Inada. This is a deep implementation detail. Instances of this type are not even exposed to users. And the types module should not contain all types used in CPython.