On 6/2/08, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> I believe those APIs are already there in the existing interface. Why does
> that concern you?
Just because PyBytes_InternXXX are not in Py3K C API. Iff the whole
point of this patch is easier merges, then I believe there is a
problem here. Please note I'm definitely +1 for your patch, but the
string interning API seems to need a bit more of care. Am I wrong?
>
>
> On Mon, Jun 2, 2008 at 9:17 AM, Lisandro Dalcin <[EMAIL PROTECTED]> wrote:
>
> > Are you completelly sure of adding those guys: PyBytes_InternXXX ???
> >
> >
> >
> >
> >
> > On 6/1/08, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > > On Fri, May 30, 2008 at 1:37 AM, M.-A. Lemburg <[EMAIL PROTECTED]> 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
> > > [EMAIL PROTECTED]
> > > 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
> >
>
>
--
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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
