PyGetSetDef has a "void *context" field.  This field is passed in to the
get and set functions implementing the property.  The field is almost
never used, so it adds unnecessary complexity.  Clearly, YAGNI.

There are two places in CPython where it got used: both in PyLongObject,
both using long_getN(), where it's used to store an integer constant
(not a pointer!) that is converted to a Long object and returned.  Since
there are only two of these, this was easy to fix: split long_getN()
into two functions returning a hard-coded number, long_get0() and
long_get1().

The attached patch removes the "void *context" field of PyGetSetDef,
removes the almost universally ignored context arguments to the getters
and setters, and removes the data declarations for the context pointer
in static PyGetSetDef structs.  With the patch applied py3k/trunk passes
all expected regression tests.

Martin: I added you to the nosy list 'cause we looked in to this at the
sprints, so I figured you'd be interested.

Whoops, forgot to categorize the issue before submitting it.

I haven't looked at this patch in detail, but I'd be delighted to see 
those uses of the context in longobject.c disappear.

Doesn't it also break binary compatibility with extension modules?
Perhaps this should be quickly discussed on python-dev, although I agree
that it looks sensible.

I've removed those gratuitous context uses in Objects/longobject.c
in r72202 (trunk) and r72203 (py3k).

I'm not sure it's a good idea to remove the context field completely.  
Apart from the compatibility issues that Antoine pointed out, it
doesn't seem improbable that some getters and setters might need it.

A Google code search for PyGetSetDef turned up at least one non-null
use of the context field (in something called pyephem).  I didn't
look at it closely, though.

Mark Dickinson: no extension module would ever *need* it.  One could
reproduce the functionality with stub intermediary functions, as follows:

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. */

The body of Python extension code shows that this facility is rarely
needed.  And folks that need it can roll their own.

It's a minor thing, but I think it's worth doing, if we're willing to
break compatibility in this way.

Anyway, I'm gonna float it on python-dev.

Oh, and, I looked at pyephem.  It uses the context field to... store an
integer.  In this case, the offset in a structure where it's going to
pull out a value (float or double).  This code would probably be clearer
if forced to make do without the "closure".