[Python-3000] [Python-Dev] Stabilizing the C API of 2.6 and 3.0

[Gregory P. Smith]

On Thu, May 29, 2008 at 3:57 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> M.-A. Lemburg wrote:
>> * Why should the 2.x code base turn to hacks, just because 3.x wants
>> to restructure itself ?
>
> With the better explanation from Greg of what the checked in approach
> achieves (i.e. preserving exact ABI compatibility for PyString_*, while
> allowing PyBytes_* to be used at the source code level), I don't see what
> has been done as being any more of a hack than the possibly more common
> "#define <oldname> <newname>" (which *would* break binary compatibility).
>
> The only things that I think would tidy it up further would be to:
> - include an explanation of the approach and its effects on API and ABI
> backward and forward compatibility within 2.x and between 2.x and 3.x in
> stringobject.h
> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0

Yes that is the only complaint I believe I really see left at this
point.  It is easy enough to fix.

Change the current stringobject.h "#define PyBytes_Foo PyString_Foo"
approach into a .c file that defines one line stub functions for all
PyString_Foo() functions to call actual PyBytes_Foo() functions.

I'd even go so far as to put the one line alternate name stubs in the
Objects/bytesobject.c and .h file right next to the PyBytes_Foo()
method definitions so that its clear from reading a single file that
they are the same thing.

The performance implications of this are minor all things considered
(a single absolute jmp given a good compiler) and regardless of what
we do should only apply to extension modules, not the core.

If we do the above in trunk will this thread end?

I'm personally not really clear on why we need PyBytes_Foo to show up
in the -binary- ABI in 2.6.  The #define's are enough for me but I'm
happy to make this compromise.

No 2.x books, documentation or literature will be invalidated by the
changes regardless.

-gps