-cc: python-3000<br><br>I believe those APIs are already there in the existing interface. Why does that concern you?<br><br><div class="gmail_quote">On Mon, Jun 2, 2008 at 9:17 AM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Are you completelly sure of adding those guys: PyBytes_InternXXX ???<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On 6/1/08, Gregory P. Smith <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
> On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:<br>
> > On 2008-05-30 00:57, Nick Coghlan wrote:<br>
> >><br>
> >> M.-A. Lemburg wrote:<br>
> >>><br>
> >>> * Why can't we have both PyString *and* PyBytes exposed in 2.x,<br>
> >>> with one redirecting to the other ?<br>
> >><br>
> >> We do have that - the PyString_* names still work perfectly fine in 2.x.<br>
> >> They just won't be used in the Python core codebase anymore - everything in<br>
> >> the Python core will use either PyBytes_* or PyUnicode_* regardless of which<br>
> >> branch (2.x or 3.x) you're working on. I think that's a good thing for ease<br>
> >> of maintenance in the future, even if it takes people a while to get their<br>
> >> heads around it right now.<br>
> ><br>
> > Sorry, I probably wasn't clear enough:<br>
> ><br>
> > Why can't we have both PyString *and* PyBytes exposed as C<br>
> > APIs (ie. visible in code and in the linker) in 2.x, with one redirecting<br>
> > to the other ?<br>
> ><br>
> >>> * Why should the 2.x code base turn to hacks, just because 3.x wants<br>
> >>> to restructure itself ?<br>
> >><br>
> >> With the better explanation from Greg of what the checked in approach<br>
> >> achieves (i.e. preserving exact ABI compatibility for PyString_*, while<br>
> >> allowing PyBytes_* to be used at the source code level), I don't see what<br>
> >> has been done as being any more of a hack than the possibly more common<br>
> >> "#define <oldname> <newname>" (which *would* break binary compatibility).<br>
> >><br>
> >> The only things that I think would tidy it up further would be to:<br>
> >> - include an explanation of the approach and its effects on API and ABI<br>
> >> backward and forward compatibility within 2.x and between 2.x and 3.x in<br>
> >> stringobject.h<br>
> >> - expose the PyBytes_* functions to the linker in 2.6 as well as 3.0<br>
> ><br>
> > Which is what I was suggesting all along; sorry if I wasn't<br>
> > clear enough on that.<br>
> ><br>
> > The standard approach is that you provide #define redirects from the<br>
> > old APIs to the new ones (which are then picked up by the compiler)<br>
> > *and* add function wrappers to the same affect (to make linkers,<br>
> > dynamic load APIs such ctypes and debuggers happy).<br>
> ><br>
> ><br>
> > Example from pythonrun.h|c:<br>
> > ---------------------------<br>
> ><br>
> > /* Use macros for a bunch of old variants */<br>
> > #define PyRun_String(str, s, g, l) PyRun_StringFlags(str, s, g, l, NULL)<br>
> ><br>
> > /* Deprecated C API functions still provided for binary compatiblity */<br>
> ><br>
> > #undef PyRun_String<br>
> > PyAPI_FUNC(PyObject *)<br>
> > PyRun_String(const char *str, int s, PyObject *g, PyObject *l)<br>
> > {<br>
> > return PyRun_StringFlags(str, s, g, l, NULL);<br>
> > }<br>
> ><br>
><br>
><br>
> Okay, how about this? <a href="http://codereview.appspot.com/1521" target="_blank">http://codereview.appspot.com/1521</a><br>
><br>
> Using that patch, both PyString_ and PyBytes_ APIs are available using<br>
> function stubs similar to the above. I opted to define the stub<br>
> functions right next to the ones they were stubbing rather than<br>
> putting them all at the end of the file or in another file but they<br>
> could be moved if someone doesn't like them that way.<br>
><br>
><br>
> > I still believe that we should *not* make "easy of merging" the<br>
> > primary motivation for backporting changes in 3.x to 2.x. Software<br>
> > design should not be guided by restrictions in the tool chain,<br>
> > if not absolutely necessary.<br>
> ><br>
> > The main argument for a backport needs to be general usefulness<br>
> > to the 2.x users, IMHO... just like any other feature that<br>
> > makes it into 2.x.<br>
> ><br>
> > If merging is difficult then this needs to be addressed, but<br>
> > there are more options to that than always going back to the<br>
> > original 2.x trunk code. I've given a few suggestions on how<br>
> > this could be approached in other emails on this thread.<br>
><br>
><br>
> I am not the one doing the merging or working on merge tools so I'll<br>
> leave this up to those that are.<br>
><br>
> -gps<br>
</div></div>> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com</a><br>
<div><div></div><div class="Wj3C7c">><br>
<br>
<br>
--<br>
Lisandro Dalcín<br>
---------------<br>
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)<br>
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)<br>
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)<br>
PTLC - Güemes 3450, (3000) Santa Fe, Argentina<br>
Tel/Fax: +54-(0)342-451.1594<br>
</div></div></blockquote></div><br>