[Pyrex] C-API implementation in Pyrex 0.9.6

[Greg Ewing]

Stefan Behnel wrote:
> the complete layout (or rather struct size) of extension types
> is only relevant to external code when subclassing.

That's not true. If B subclasses from A, and you add a field to A,
the fields of B move, which affects all users of B even if they
don't subclass it themselves.

> I'm pretty sure no user would mind
> having to recompile code that subclasses a C type when the internal
> representation of that type changes

It's not the need for recompiling that concerns me, it's knowing
*when* you have to do it, and knowing when you're making a change
that will require it.

The rules are currently very clear and simple: If you import a
.pxd, you are affected by changes to that .pxd. You are never
affected by changes to another .pyx.

Your proposal would change it to something like: "You are usually
not affected by changes to another .pyx, unless a field is added
to an extension type that you subclass or that is subclassed
by another extension type that you use."

I would hate to have to write a Makefile rule to deal with that!

> Note that people who provide a public C-level API for their modules can
> usually be expected to care about binary compatibility themselves

You're thinking about dependencies across projects, but I'm
thinking about dependencies within a project made up of a number
of modules, as well. I don't want to have to recompile all of
the modules in my project every time anything changes in one
of them, just on the offchance.

> And note that this only applies to Pyrex code, C code will always depend on
> the generated .h file anyway.

But you can think of it as depending directly on the .pxd
that it was generated from.

--
Greg