Movatterモバイル変換
[0]ホーム
PyMem_* cross-Python-generation recommendation?
Michael Hudsonmwh21 at cam.ac.uk
Thu Apr 19 18:22:24 EDT 2001
"Mike C. Fletcher" <mcfletch at home.com> writes:> From the Memory Interface document for Python 2.0, the following is> described:>> In addition, the following macro sets are provided for calling the Python> memory allocator directly, without involving the C API functions listed> above. However, note that their use does not preserve binary compatibility> accross Python versions and is therefore deprecated in extension modules.>> PyMem_MALLOC(), PyMem_REALLOC(), PyMem_FREE().> PyMem_NEW(), PyMem_RESIZE(), PyMem_DEL().>>> If I attempt to use PyMem_New in Python 1.5.2, I get a not-defined error,> PyMem_NEW is there. Conversely, if I attempt to use PyMem_FREE in 1.5.2, I> get a not defined error but PyMem_Free is there. So, I'm wondering, what> combination should I use for an extension module (PyOpenGL) which requires> compilation for both Python 1.5.2 and 2.x? Currently I'm just using> PyMem_NEW and PyMem_Free. That compiles under both Pythons, but I have _no_> clue what the implications of the choice are.You probably want to use functions rather than macros (they have abetter chance of working across Python versions). PyMem_NEW soundslike a macro and PyMem_Free like a function, but this may not actuallybe the case.Are you talking about binary or source compatibility here? I don'tknow if binary compatibility works between 1.5.2 and 2.0 - I doubt it.For source compatibility you can use #if hackery withPYTHON_CAPI_VERSION to use the right one.The interface is a bit of a mess pre-2.0, I believe. You probablywant to use the 2.0 one if you can.HTH, though I'm not sure it does,M.-- While preceding your entrance with a grenade is a good tactic in Quake, it can lead to problems if attempted at work. -- C Hacking --http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html
More information about the Python-listmailing list
[8]ページ先頭