[Python-3000] A better way to initialize PyTypeObject

[Talin]

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.

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.

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.

Now, I tend to prefer using a static table vs. the 
function-call-per-method simply because of my habits, which tend to be 
overly parsimonious with code size and such (It's a side-effect of 
working on embedded systems, which is what game consoles effectively 
are.) I wouldn't have strong objections to doing it the other way.

-- Talin