[Python-3000] A better way to initialize PyTypeObject

[Talin]

Guido van Rossum wrote:
> My preference is for a table-based version over a "lots-of-calls"
> approach. I think the idea of using predefined (integer) constants
> instead of string constants fits fine into the table-based approach.
> However I'm not sure that a string-based approach is necessarily bad
> -- we use that now for everything that's not a special method after
> all. I do get the point that the string-based approach uses more
> memory and needs more processing time.

OK. Its easy to implement either way. I coded up a string-based version, 
but if you guys want integer constants that's fine with me; probably 
best to let Fredrik & Larry tweak their patch rather than me continuing 
along this path since their stuff is further along.

The two reasons why I thought strings might be good is:

1) I wanted to use the PyMethodDef table to store both special and 
regular methods; in other words, instead of having a special table for 
initializing PyTypeObject, I was going to re-use one of the already 
existing tables, and PyMethodDef already identifies methods via string 
(although you can type-pun an integer into the same slot.)

2) I wanted regular methods and special methods to be treated uniformly, 
at least at the API level, and let the runtime decide whether or not a 
given method should be "special" (in other words, have a dedicated slot 
in PyTypeObject.) If regular methods are registered by string, and 
special methods are registered by integer, then you can't really mix 
them; whereas if they are both registered via the same mechanism, then 
you can later go back and decide that a given special method doesn't 
really need to be special and vice versa. So for example, there's no 
dedicated slot for __unicode__, but if in the future performance 
measurement should indicate that creating such a slot would be of 
benefit, you could simply add a new slot for it and all existing 
modules, when recompiled, would automatically use the new slot.

However, all that being said I recognize that string lookups aren't 
cheap. This is especially true in this case where almost all of the 
names in the table start with "__", so you have to look at the 3rd 
character before you detect a mismatch.

What I am aiming at is for PyTypeObject to be as opaque as possible in 
practice, in other words initialization code shouldn't need to know much 
about the ordering or types of fields. This gives the developers of the 
Python runtime a great deal of freedom in their ability to refactor the 
internals of the runtime without breaking existing extension modules.

> On 12/2/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>> Talin wrote:
>>
>>> So I don't think it's the case that nobody's even bothered to look at
>>> Larry's patch
>> so are you basing your patch on his work?
>>
>>  > People have looked at the patch and suggested taking a different
>>  > approach.
>>
>> really?  I haven't seen much of a consensus for the string-literals
>> instead of constants approach, especially not from experienced extension
>> writers.  personally, I think it's butt-ugly, a lot more error-prone
>> than any alternative, and I also doubt that it'll save much space in
>> practice.  it also ignores history; the Xt developers tried the same
>> thing, and ended up adding #define's for all their string literals to
>> get a least a little help from the compiler...
>>
>> </F>