[Python-Dev] PEP 384: Defining a Stable ABI (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue May 26 20:54:35 CEST 2009

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 PyFatalError()

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

or PyTraceBackPrint().

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

More information about the Python-Dev mailing list