On 2009-01-02 08:26, Adam Olsen wrote: > On Thu, Jan 1, 2009 at 11:24 PM, Alexander Belopolsky > <alexander.belopol...@gmail.com> wrote: >> On Fri, Jan 2, 2009 at 12:58 AM, Adam Olsen <rha...@gmail.com> wrote: >> .. >>> As C++ has more specific ways of allocating memory, they impose this >>> restriction to annoy you into using them. >> And so does Python API: see PyMem_NEW and PyMem_RESIZE macros. > > An optional second API provides convenience, not annoyance. Besides, > they're not used much anymore. I am curious what their history is > though.
See Include/pymem.h and objimpl.h for details. PyMem_MALLOC() et al. provide an abstraction layer on top of the system's malloc() implementation. PyObject_MALLOC() et al. use the Python memory allocator instead. >>> We won't be using them, and the extra casts and nothing but noise. >> A quick grep through the sources shows that these casts are not just nose: >> >> Objects/stringobject.c: op = (PyStringObject *)PyObject_MALLOC(.. >> Objects/typeobject.c: remain = (int *)PyMem_MALLOC(.. >> Objects/unicodeobject.c: unicode->str = (Py_UNICODE*) >> PyObject_MALLOC(.. >> >> in many cases the type of object being allocated is not obvious from >> the l.h.s. name. Redundant cast improves readability in these cases. > > 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. > 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. 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. >>> Figure out a way to turn off the warnings instead. >>> >> These are not warnings: these are compile errors in C++. A compiler >> which allows to suppress them would not be a standard compliant C++ >> compiler. > > So long as the major compilers allow it I don't particularly care. > Compiling as C++ is too obscure of a feature to warrant uglifying the > code. > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 02 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