RE: [Python-Dev] Pymalloc and backward compatibility
From: Neil Schemenauer [mailto:nas@python.ca]
The code has survived essentially unchanged through [Python 1.4] to Python 2.2, and still works fine.
This is a great test case. Can you provide a URL to the code?
I'm not sure it's downloadable separately, but it's in the sources for Vim (see www.vim.org), file src/if_python.c. If I can, I'll have a go at testing it against 2.3 once the pymalloc situation settles down. I don't normally build Python from source, and my CVS access is flaky at best, so I won't promise anything until after the first alpha, though... :-)
As long as you don't use free() to deallocate objects then you are safe. Python 1.4 has PyMem_DEL. You can use a macro like this:
#if PY_VERSION_HEX < 0x01060000 #define PyObject_New PyObject_NEW #define PyObject_Del PyMem_DEL #endif
and use PyObject_New and PyObject_Del to manage object memory.
Some form of backward compatibility boilerplate which incorporated this would probably be of use in allowing people to migrate - it might save everyone writing their own. One thing that worries me (probably unnecessarily) is that this alters the code on Python 1.6 - 2.2. While there's no reason this should break anything, I don't have the means to test the change. And if I used a version test for 2.3, that would look strange (as I mentioned) because the APIs have been around since before then. But I'm working from the basis that I would support some form of tidying up which *did* result in breakage - whether this happens now or later is up for debate (personally, I'm from the "get it over with" school). From that POV, I don't mind being forced to use the "right" calls, I just want to avoid breaking the code for versions I no longer have any way of testing (but others do still use) while making the backward compatibility related code very clear (so that when I finally do get fed up of believing I support 1.4, I can strip it out cleanly). I think I've talked myself into something like your code, and taking the chance of causing problems with older versions. A table of which API call appeared in which version would be useful to help with this (the current API documentation doesn't include "historical" information like this). Thanks for the comments, I'll go back to lurking now. Paul.
participants (1)
-
Moore, Paul