[Python-3000] A better way to initialize PyTypeObject

Guido van Rossum guido at python.org
Tue Nov 28 19:12:51 CET 2006


On 11/28/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
> Guido van Rossum wrote:
>
> >>> Can't we require a C99 compiler and use C99 struct initialization?
> >> that won't address the binary compatibility and optimization issues that
> >> are the main rationales for my proposal, though.
> >
> > Why not? This is the Py3k list -- there is no hope for binary
> > compatibility with 2.x. AFAIU the C99 approach can be easily binary
> > compatible between 3.0, 3.1 and beyond -- please explain if this is
> > not so.
>
> how can it be?  isn't the C99 syntax just a way to avoid filling all the
> zeros?  you'll still end up with a fixed-size structure in memory, with
> no way to move things around, and nowhere to put any auxiliary data.

We can use the same approach to extending the structure in a binary
compatible way as today. You don't need to move things around since
the initialization order doesn't need to match the order of the
members in the struct, so strictly adding to the end isn't a problem.

> > And what's the optimization issue? Do you mean the ccasional NULL
> > poitner check? Once we make PyType_Ready() obligatory, it can do the
> > same thing. Or whatever else you are thinking of.
>
> null pointer checks, using different structures depending on object
> types, different ways to represent method lists (linear lists for short
> method lists, custom dictionaries for longer lists), and what else we
> might come with during our next trip to Reykjavik.

That could all be handled by PyType_Ready(), once we allow for some
moderate extensibility in the 3.0 base struct.

> "naked structures" are a lot more limiting than data structures hidden
> behind simple API:s.

OTOH I like a data-driven approach for initialization better than a
code-driven approach. Perhaps Talin's way is a reasonable compromise?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list