Re: [Python-Dev] PyObject_New vs PyObject_NEW
Tim Peters <tim.one@comcast.net> writes:
Question: I don't have VC7 and don't know what it does. The traceback ended in MSVCRTD.DLL, which I recognize as MS's debug-mode C runtime DLL for VC6. Does VC7 use the same DLL name, or some other DLL name?
The same one.
If the latter, my theory is that PyObject_New used the MSVC6 malloc, but that PyObject_NEW used the MSCV7 malloc (due to macro expansion in your code).
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.
But the MSVC6 and MSVC7 heaps are distinct, so the debug-mode MSVC6 free() complains because it wasn't the source of the memory getting freed. A missing piece of the puzzle: what was the error msg at the time this thing died?
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]
... 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.
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:
[David Abrahams]
... 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.
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.
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
Thomas Heller <theller@python.net> writes:
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.
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 [].
I'm not in a position to decide which one of these is better. Thomas, maybe you should be submitting the patch? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Thomas Heller <theller@python.net> writes:
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.
Better to explícitely warn about them with a wording similar to that from the section 9.2 Memory Interface:
I'm not in a position to decide which one of these is better. Thomas, maybe you should be submitting the patch?
Nor am I. You can submit a patch as well, and the discussion will show. Sorry, no time. Thomas
Thomas Heller <theller@python.net> writes:
David Abrahams <dave@boost-consulting.com> writes:
Thomas Heller <theller@python.net> writes:
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.
Better to explícitely warn about them with a wording similar to that from the section 9.2 Memory Interface:
I'm not in a position to decide which one of these is better. Thomas, maybe you should be submitting the patch?
Nor am I. You can submit a patch as well, and the discussion will show.
Sorry, no time.
Fair enough; Tim's patch was much easier ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
Tim Peters <tim.one@comcast.net> writes:
[David Abrahams]
... 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.
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.
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