[Python-Dev] Pymalloc and backward compatibility

Moore, Paul Paul.Moore@atosorigin.com
Thu, 4 Apr 2002 16:54:59 +0100

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

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.