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

[Nick Coghlan]

M.-A. Lemburg wrote:
> * Why can't we have both PyString *and* PyBytes exposed in 2.x,
> with one redirecting to the other ?

We do have that - the PyString_* names still work perfectly fine in 2.x. 
They just won't be used in the Python core codebase anymore - everything 
in the Python core will use either PyBytes_* or PyUnicode_* regardless 
of which branch (2.x or 3.x) you're working on. I think that's a good 
thing for ease of maintenance in the future, even if it takes people a 
while to get their heads around it right now.

> * 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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org