On 10/11/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
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
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
_______________________________________________ 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
