guido wrote:
> > > I have patches for both these modules. However, I wonder if a =
more
> > > pragmatic option is to expose this core function. It would allow
> > > PyObject_NEW to continue to work as before.
> >
> > That would break lots of code... basically all code using
> > the macros instead of the functions, I guess.
>=20
> Hm, I thought it was explicitly the case that only (the statically
> linked part of) the core would ever use these macros. So why would
> there be 3rd party code breakage?
because module implementors read the fine manual?
http://www.python.org/doc/current/api/allocating-objects.html
"TYPE* PyObject_NEW(TYPE, PyTypeObject *type)=20
"Return value: New reference.=20
"Macro version of PyObject_New(), to gain performance
at the expense of safety. This does not check type for
a NULL value. "
and given that most calls to PyObject_New (at least in our code)
passes in the address of a statically allocated Type object, there's
little reason to use a null-checking version...
(a quick grep indicates that we have about 100 PyObject_NEW for
each call to PyObject_New...)
</F>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4