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

[Lisandro Dalcin]

Are you completelly sure of adding those guys:  PyBytes_InternXXX ???


On 6/1/08, Gregory P. Smith <greg at krypto.org> wrote:
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>  > 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);
>  > }
>  >
>
>
> Okay, how about this?  http://codereview.appspot.com/1521
>
>  Using that patch, both PyString_ and PyBytes_ APIs are available using
>  function stubs similar to the above.  I opted to define the stub
>  functions right next to the ones they were stubbing rather than
>  putting them all at the end of the file or in another file but they
>  could be moved if someone doesn't like them that way.
>
>
>  > 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.
>
>
> I am not the one doing the merging or working on merge tools so I'll
>  leave this up to those that are.
>
>  -gps
>  _______________________________________________
>  Python-Dev mailing list
>  Python-Dev at python.org
>  http://mail.python.org/mailman/listinfo/python-dev
>  Unsubscribe: http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594