[Python-3000] A better way to initialize PyTypeObject

Jim Jewett jimjjewett at gmail.com
Tue Nov 28 17:59:56 CET 2006


On 11/28/06, Talin <talin at acm.org> wrote:
> For example, consider the case for tp_init and tp_new. ... you have
> to put 37 initializer values before them, whether you use them or not.

> Now, you still have the problem that 'tp_methods' itself is something
> like the 28th field in the struct, which means you still have all of
> those empty fields to consider.

> Note that this requires no change to the PyTypeObject struct itself, or
> of any code that currently uses it - the only thing that changes is the
> way that the struct's data fields are filled in.

> What this would give you is a way to construct types that would be
> immune to future revisions of the PyTypeObject struct; You could add,
> remove, rename, or re-order the fields in the struct without breaking
> existing code.

Am I understanding this correctly?

(1)  The change is that instead of a header structure filled in with
zeros, you have a collection of function calls.  (And this secretly
makes that zero-filled structure for you.)  Since they're each a
function call, it may take just as much space to write out, but there
won't be any (source code) place to read the physical layout, and it
won't be as obvious that you've left a method out.

With C99 initializers, you at least get named (rather than
comment-named) fields, but I don't see any advantage to using function
calls if the type slots don't change.

(2)  In theory, it would be easier to add/remove/reorder slots between
major versions, but you wouldn't actually do this because of backwards
compatibility.

So then why make a change at all?

-jJ


More information about the Python-3000 mailing list