[Python-Dev] PEP 384: Defining a Stable ABI

["Martin v. Löwis"]

>>>> Functions declared in the following header files are not part
>>>> of the ABI:
>>>> - cellobject.h
>>>> - classobject.h
>>>> - code.h
>>>> - frameobject.h
>>>> - funcobject.h
>>>> - genobject.h
>>>> - pyarena.h
>>>> - pydebug.h
>>>> - symtable.h
>>>> - token.h
>>>> - traceback.h
>>> I don't think that's feasable: you basically remove all introspection
>>> functions that way.
>>>
>>> This will need a more fine-grained approach.
>> What specifically is it that you want to do in a module that you
>> couldn't do anymore?
> 
> See my reply to Nick: some of the functions are needed even
> if you don't want to do introspection, such as Py_FatalError()

Ok. I don't know what Py_FatalError is doing in pydebug.h, so I
now propose to move it to pyerrors.h.

> or PyTraceBack_Print().

Ok; I have removed traceback.h from the list. By the other rules
of the PEP, the only function that becomes available then is
PyTraceBack_Print.

> BTW: Given the headline, I take it that the various type checking
> macros in these header will still be available, right ?

Which headers? The one on the list above? No; my idea would
be to completely hide them as-is.

All other type-checking macros will remain available, and
will remain being macros.

>>> Would creating a Python object in a full-API extension and
>>> free'ing it in a limited-API extension cause problems ?
>> No problem that I can see.
> 
> Can we be sure that the MSVCRT used by python35.dll stays compatible
> to the one used by say python32.dll ? What if the CRT memory
> management changes between MSVCRT versions ?

It doesn't matter. For Python "things", the extension module will
use the pymem.h functions, which get routed through pythonxy.dll
to the CRT that Python was build with.

If the extension uses regular malloc(), it should also invoke
regular free() on the pointer. There is no API where Python
calls malloc directly and the extension calls free, or vice
versa.

> How will this work in the light of having multiple copies of
> Python installed on a Windows machine ?

Interesting question. One solution could be to use SxS, which
would allow multiple concurrent installations of python3.dll,
although we would need to make sure it always binds to the
"right" one in each context.

Another solution could be to keep the various copies of python3.dll
in their respective PYTHONHOMEs, and leave it to python.exe or the
app to load the right one; any subsequent extension modules should
then pick up the one that was already loaded.

> They implementation section suggests that python3.dll would always
> redirect to the python3x.dll for which it was installed, ie. if
> I have Python 3.5 installed, but then need to run some app with
> Python 3.2, the installed python3.dll would then point back to the
> python32.dll.

That depends on where they get installed. If they all go into system32,
only the most recent one would be available, which is probably not
desirable.

> Now, if I start a Python 3.5 application which uses a limited
> API extension, this would try to load python32.dll into the
> Python 3.5 process. AFAIK, that's not possible due to the
> naming conflicts.

I don't see this problem. As long as we manage to install multiple
versions of python3.dll on the system somehow, different processes
could certainly load different such DLLs, and the same extension
module would always use the right one.

Regards,
Martin