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

[M.-A. Lemburg]

On 2008-05-30 00:57, Nick Coghlan wrote:
> 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.

Sorry, I probably wasn't clear enough:

Why can't we have both PyString *and* PyBytes exposed as C
APIs (ie. visible in code and in the linker) in 2.x, with one redirecting
to the other ?

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

Which is what I was suggesting all along; sorry if I wasn't
clear enough on that.

The standard approach is that you provide #define redirects from the
old APIs to the new ones (which are then picked up by the compiler)
*and* add function wrappers to the same affect (to make linkers,
dynamic load APIs such ctypes and debuggers happy).


Example from pythonrun.h|c:
---------------------------

/* Use macros for a bunch of old variants */
#define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)

/* Deprecated C API functions still provided for binary compatiblity */

#undef PyRun_String
PyAPI_FUNC(PyObject *)
PyRun_String(const char *str, int s, PyObject *g, PyObject *l)
{
	return PyRun_StringFlags(str, s, g, l, NULL);
}


I still believe that we should *not* make "easy of merging" the
primary motivation for backporting changes in 3.x to 2.x. Software
design should not be guided by restrictions in the tool chain,
if not absolutely necessary.

The main argument for a backport needs to be general usefulness
to the 2.x users, IMHO... just like any other feature that
makes it into 2.x.

If merging is difficult then this needs to be addressed, but
there are more options to that than always going back to the
original 2.x trunk code. I've given a few suggestions on how
this could be approached in other emails on this thread.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 30 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2008-07-07: EuroPython 2008, Vilnius, Lithuania            37 days to go

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611