[Python-3000] A better way to initialize PyTypeObject

[Brett Cannon]

On 11/28/06, Talin <talin at acm.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20061128/a63e0793/attachment.htm