[Python-Dev] Making PyInterpreterState an opaque type

[INADA Naoki]

On Tue, Feb 19, 2019 at 7:32 PM Jeroen Demeyer <J.Demeyer at ugent.be> wrote:
>
> On 2019-02-19 04:04, Steve Dower wrote:
> > On 18Feb.2019 1324, Jeroen Demeyer wrote:
> >> For a very concrete example, was it really necessary to put
> >> _PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
> >> given that the very similar PySequence_Fast_ITEMS is in (2), that seems
> >> like a strange and arbitrary limiting choice.
> >
> > The reason to do this is that we can "guarantee" that we've fixed all
> > users when we change the internal representation.
>
> I think that CPython should then at least "eat its own dog food" and
> don't use any of the internal functions/macros when implementing the
> stdlib. As I said before: if a function/macro is useful for implementing
> stdlib functionality like "functools" or "json", it's probably useful
> for external modules too.

If we are perfect and we can design perfect APIs from start, I agree with you.
But we should fix design mistake of new APIs.

stdlibs are updated with Python itself.  So changing internal APIs with micro
version is OK.
If Cython start using such internal APIs, external modules from PyPI
will be broken
when Python is upgraded.  It feels nightmare to me.
So having experimental APIs only for stdlibs makes sense to me.

On the other hand, it makes sense to move _PyTuple_ITEMS to (3) or even (2).
PyTuple_ITEMS(t) seems better than &PyTuple_GET_ITEM(t, 0).

Regards,

-- 
INADA Naoki  <songofacandy at gmail.com>