"Martin v. Loewis" wrote:
The discussion on SF doesn't really answer my question. What Nick did is fascinating: he reused the type object implementation to mimic a sequence ! That's cool, but looks like an awfully tricky way of doing something straight forward such as sub-classing the tuple type to extend it with an additional dictionary. So the question remains: why did Nick *have* to implement this as meta-type ?
For one thing, you'll see from the discussion that extending the tuple type with an additional dict is non-trivial: You cannot define a C data type that does this. You'll also see that there was a version that did it, and that it was rejected precisely because of this problem.
Ok, now we're getting somewhere... you're saying that Python types using the PyObject struct itself to store variable size data cannot be subclassed in C. Even though it's not trivial as you indicate, this should well be possible by appending new object data to the end of the allocated data field -- not very elegant, but still a way to cope with the problem.
However, Nick's approach of creating a new type from a template by using the fact that the list of known name-to-index mappings is not going to change for instances of the type makes things a lot cleaner, since now the mapping can live in the type definition rather than the instance (which may very well be a varying length PyObject type).
Hmm, this makes me wonder: perhaps we should start thinking about phasing out varying length PyObjects in the interpreter... esp. the inability to subclass strings looks like a bummer for future extensions of this particular type. Unicode doesn't have this problem, BTW.
Or we need to come up with a fairly nice way of making subclassing varying length types a lot easier, e.g. by adding a special pointer ob_ext to PyObject_VAR_HEAD which then allows declaring type extensions in an malloced buffer.