I should have brought this up to python-dev before--sorry for being so
slow. It's already in the tracker for a couple of days:
http://bugs.python.org/issue5880
The idea: PyGetSetDef has this "void *closure" field that acts like a
context pointer. You stick it in the PyGetSetDef, and it gets passed
back to you when your getter or setter is called. It's a reasonable API
design, but in practice you almost never need it. Meanwhile, it
clutters up CPython, particularly typeobject.c; there are all these
function calls that end with ", NULL);", just to satisfy the
getter/setter prototype internally.
Most of the time, the "closure" parameter is not only unused, it is
skipped. PyGetSetDef definitions generally skip it, and often getter
and setter implementations omit it. The "closure" was only actually
*used* once in CPython, a silly use in Objects/longobject.c where it was
abused as an integer value. And yes, I said "was": inspired by this
discussion, Mark Dickinson removed this use in r72202 (trunk) and r72203
(py3k). So the "closure" field is now 100% unused in the python and
py3k trunks.
Mr. Dickinson also located an extension using the "closure" pointer,
pyephem, which... *also* uses it to store an integer. Indeed, I have
yet to see a use where someone stores a pointer in "closure".
Anyone who needed functionality like this could roll it themselves with
stub functions:
PyObject *my_getter_with_context(PyObject *self, void *context) {
/* ... */
}
PyObject *my_getter_A(PyObject *self) {
return my_getter_with_context(self, "A");
}
PyObject *my_getter_B(PyObject *self) {
return my_getter_with_context(self, "B");
}
/* etc. */
(Although it'd make my example more realistic if "context" were an int!)
So: you don't need it, it clutters up our code (particularly
typeobject.c), and it adds overhead. The only good reason to keep it is
backwards compatibility, which I admit is a fine reason.
Whaddya think? To be honest I'd be surprised if you guys went for
this. But I thought it was worth suggesting.
/larry/
_______________________________________________
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
