Re: [Python-Dev] PyObject_New vs PyObject_NEW
Tim Peters <tim.one@comcast.net> writes:
The same one.
Brilliant theory!
In both cases the MSVC6 free() gets called.
Ah, correct. I misread "someone's" code; the delete function just calls PyObject_Del(). I think "someone" probably ought to do something more explicit to control where things are allocated/freed. But for now, I think using PyObject_New/PyObject_Del is reasonable.
unhandled exception at 0x10213638 (MSVCRTD.DLL) in python_d.exe: User breakpoint. It seems to me that in light of all this, it's probably worth noting this difference between PyObject_New and PyObject_NEW in the docs. People *will* develop extension modules with different compilers from the one Python was compiled with... I know, submit a patch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
[David Abrahams]
I don't think the macro versions should ever be used outside the core. Inside the core, it's safe. So I think the "doc bug" is that the docs mention PyObject_NEW at all.
People *will* develop extension modules with different compilers from the one Python was compiled with...
Yup.
I know, submit a patch.
That would be a sociable thing.
Tim Peters <tim.one@comcast.net> writes:
Better to explícitely warn about them with a wording similar to that from the section 9.2 Memory Interface: 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. Maybe 'and compilers' should be inserted between the []. Thomas
Tim Peters <tim.one@comcast.net> writes:
What, precisely, does PyObject_NEW save you? From a brief squint at the sources, my best guess is "nothing" -- and it may even be a pessimization due to increased code size. Maybe we could kill it entirely (after the usual round of deprecations, of course). Cheers, M. -- Like most people, I don't always agree with the BDFL (especially when he wants to change things I've just written about in very large books), ... -- Mark Lutz, http://python.oreilly.com/news/python_0501.html
David> But for now, I think using PyObject_New/PyObject_Del is David> reasonable. Or perhaps PyObject_NEW/PyObject_DEL. S
[David Abrahams]
I don't think the macro versions should ever be used outside the core. Inside the core, it's safe. So I think the "doc bug" is that the docs mention PyObject_NEW at all.
People *will* develop extension modules with different compilers from the one Python was compiled with...
Yup.
I know, submit a patch.
That would be a sociable thing.
Tim Peters <tim.one@comcast.net> writes:
Better to explícitely warn about them with a wording similar to that from the section 9.2 Memory Interface: 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. Maybe 'and compilers' should be inserted between the []. Thomas
Tim Peters <tim.one@comcast.net> writes:
What, precisely, does PyObject_NEW save you? From a brief squint at the sources, my best guess is "nothing" -- and it may even be a pessimization due to increased code size. Maybe we could kill it entirely (after the usual round of deprecations, of course). Cheers, M. -- Like most people, I don't always agree with the BDFL (especially when he wants to change things I've just written about in very large books), ... -- Mark Lutz, http://python.oreilly.com/news/python_0501.html
David> But for now, I think using PyObject_New/PyObject_Del is David> reasonable. Or perhaps PyObject_NEW/PyObject_DEL. S
participants (5)
-
David Abrahams -
Michael Hudson -
Skip Montanaro -
Thomas Heller -
Tim Peters