[Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?

[Brett Cannon]

On 10/11/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>
> Martin v. Löwis wrote:
>
> > Of course, if everybody would always recompile all extension modules
> > for a new Python feature release, those flags weren't necessary.
>
> a dynamic registration approach would be even better, with a single entry
> point
> used to register all methods and hooks your C extension has implemented,
> and
> code on the other side that builds a properly initialized type descriptor
> from that
> set, using fallback functions and error stubs where needed.
>
> e.g. the impossible-to-write-from-scratch NoddyType struct initialization
> in
>
>     http://docs.python.org/ext/node24.html
>
> would collapse to
>
>     static PyTypeObject NoddyType;
>
>     ...
>
>     NoddyType = PyType_Setup("noddy.Noddy", sizeof(Noddy));
>     PyType_Register(NoddyType, PY_TP_DEALLOC, Noddy_dealloc);
>     PyType_Register(NoddyType, PY_TP_DOC, "Noddy objects");
>     PyType_Register(NoddyType, PY_TP_TRAVERSE, Noddy_traverse);
>     PyType_Register(NoddyType, PY_TP_CLEAR, Noddy_clear);
>     PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods);
>     PyType_Register(NoddyType, PY_TP_MEMBERS, Noddy_members);
>     PyType_Register(NoddyType, PY_TP_INIT, Noddy_init);
>     PyType_Register(NoddyType, PY_TP_NEW, Noddy_new);
>     if (PyType_Ready(&NoddyType) < 0)
>         return;
>
> (a preprocessor that generated this based on suitable "macro decorators"
> could
> be implemented in just over 8 lines of Python...)
>
> with this in place, we could simply remove all those silly NULL checks
> from the
> interpreter.



This is also has the benefit of making it really easy to grep for the
function used for the tp_init field since there is no guarantee someone will
keep the traditional field comments in their file (I usually grep for
PyTypeObject until I find the type I want).

If we went with C99 this wouldn't be an issue, but since I don't think that
is necessarily in the cards I am very happy to go with this solution.  It
ends up feeling more like how Ruby does C extensions, and I have to admit I
think they may have made it simpler than we have.

And of course with the change Raymond put in for checking the PyMethodDef
slots can also easily allow people to name methods based on what the slots
would be named had it been defined in Python (which we might want to do
anyway with the C constants to make it more readable and less obtuse to new
extension writers; e.g. change PY_TP_NEW to PY__NEW__).

And lastly, this approach makes sure that the basic requirement of what a
type must have defined can be enforced in the PyType_Setup() method /F's
proposing.


+1 from me.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20061011/6a564753/attachment-0001.htm