I.e. even with the change, it would *still* depend on objimpl.h
(and other) settings what ABI this debug DLL exactly has.
I think it does. My proposal was perhaps not clear: For existing
python versions, always export _PyObject_DebugMalloc et al.
Hmm. That's still not clear. What are "existing Python versions"?
You can't change them anymore; any change can only affect future,
as-of-yet-non-existing Python versions.
Also, what do you mean by "always"? Even in release builds?
Would this really help? You shouldn't be mixing PyObject_DebugMalloc
and PyObject_Malloc in a single process.
On new python versions, remove the
_PyObject_DebugMalloc from the ABI. Make the switch internal to
obmalloc.c, so that you can turn on the debug library by recompiling
pythonxx_d.dll only (currently, you have to recompile the .pyd files
too!)
That sounds fine.
But there are tons of ABI changes that may happen in a debug
build. If you want to cope with all of them, you really need to
recompile the source of all extensions.
Are there? Can you give me an example?
If you define Py_TRACE_REFS, every object has two additional pointers,
which aren't there if you don't. So extensions compiled with it are
incompatible with extensions compiled without it.
If you define COUNT_ALLOCS, every type object will have additional
slots; again, you can't mix extensions that have a different setting
here than the interpreter.
Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
