On 2009-01-03 04:15, Adam Olsen wrote: > On Fri, Jan 2, 2009 at 9:05 AM, M.-A. Lemburg <m...@egenix.com> wrote: >> On 2009-01-02 08:26, Adam Olsen wrote: >>> Python's malloc wrappers are pretty messy. Of your examples, only >>> unicode->str isn't obvious what the result is, as the rest are local >>> to that function. Even that is obvious when you glance at the line >>> above, where the size is calculated using sizeof(Py_UNICODE). >>> >>> If you're concerned about correctness then you'd do better eliminating >>> the redundant malloc wrappers and giving them names that directly >>> match what they can be used for. >> ??? Please read the comments in pymem.h and objimpl.h. > > I count 7 versions of malloc. Despite the names, none of them are > specific to PyObjects. It's pretty much impossible to know what > different ones do without a great deal of experience.
Is it ? I suggest you read up on the Python memory management and the comments in the header files. The APIs are pretty straight forward... http://docs.python.org/c-api/allocation.html http://docs.python.org/c-api/memory.html > Only very specialized uses need to allocate PyObjects directly anyway. > Normally PyObject_{New,NewVar,GC_New,GC_NewVar} are better. Better for what ? The APIs you referenced are only used to allocate Python objects. The malloc() wrappers provide a sane interface not only for allocating Python objects, but also for arbitrary memory chunks, e.g. ones referenced by Python objects. >>> If the size calculation bothers you you could include the semantics of >>> the PyMem_New() API, which includes the cast you want. I've no >>> opposition to including casts in a single place like that (and it >>> would catch errors even with C compilation). >> You should always use PyMem_NEW() (capital letters), if you ever >> intend to benefit from the memory allocation debug facilities >> in the Python memory allocation interfaces. > > I don't see why such debugging should require a full recompile, rather > than having a hook inside the PyMem_Malloc (or even providing a > different PyMem_Malloc). Of course it does: you don't want the debug overhead in a production build. >> The difference between using the _NEW() macros and the _MALLOC() >> macros is that the first apply overflow checking for you. However, >> the added overhead only makes sense if these overflow haven't >> already been applied elsewhere. > > They provide assertions. There's no overflow checking in release builds. See above. Assertions are not meant to be checked in a production build. You use debug builds for debugging such low-level things. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 05 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com