On 11/28/06, Talin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Some comments:
>
> - Talin's solution seems to require the definition of an awful lot of
> new constants -- one per slot. And a lot of special-casing in the type
> initialization code to handle them because there are so many different
> signatures.
Actually, I was thinking more on this, and I have a couple ideas on how
to avoid this, at least the part about the number of constants.
The first idea is that instead of having a constant per special method,
simply use the regular name of the method, but have a method flag that
indicates that the method is "special":
static PyMethodDef Noddy_methods[] = {
{ "new", (PyCFunction)Noddy_new,
METH_VARARGS | METH_SPECIAL, "..." },
{ "__init__", (PyCFunction)Noddy_init,
METH_VARARGS | METH_SPECIAL, "..." },
{ NULL } /* Sentinel */
};
One drawback here is that not all of the fields in PyTypeObject have
equivalent names; But there's no reason why we couldn't give them names,
especially if the names were not valid Python identifiers.
Coming up with equivalent names should definitely not be difficult. I
honestly can't think of any that don't have a matching name off the top of
my head short of tp_free/tp_dealloc.
One issue with this, though, will be the shifting of list and dict
interfaces. They both have a __getitem__ method, but one expects only
integers and one expects anything. Are you not going to optimize for that
and just force lists to handle the type check and cast for every call?
The other drawback is that there's a greater chance of a misspelling,
but I don't see that as a serious problem - even the most cursory
testing of the class should discover this, it's not like the resulting
bugs will be subtle and hard to find, IMHO.
You could go even further, and drop the "special" flag entirely, and
there's a compelling reason why you might want to do this: It means that
now the VM gets to decide what methods are special and what methods
aren't. So if, for example, we decide in the future that '__unicode__'
needs to be sped up by putting it directly in the PyTypeObject, we can
add a slot for it, and have all existing code magically work.
That does help minimize backwards-compatibility issues. But it does make
things implicit.
It does mean that the interpretation of the method table is a bit more
complex, but as long as you have a fast way of looking up the method
names, and determining whether to put each method into the class dict or
to fill in a PyTypeObject slot, I don't think it would be too bad.
This is what Fredrik is saying about the advantage over C99
initialization, which only allows us to change the order of
initializers, not their names or meanings.
Ah, that is what you guys are getting at ! That makes sense and is a
compelling argument.
I think with this cleanup and a standardization on calling conventions
(caller or callee checks for NULL arguments, who handles conversion to
specific types, error return values, specifying ref stealing, etc.) this
should go a long way to make extension modules much easier to work with.
-Brett
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
