RetroSearch Browse

Sun Mar 2 20:33:41 CET 2008 · https://mail.python.org/pipermail/python-dev/2008-March/077367.html

On Sunday 02 March 2008, Alex Martelli wrote:
> On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <greg at krypto.org> wrote:
> > On 3/2/08, Christian Heimes <lists at cheimes.de> wrote:
> > > Alex Martelli wrote:
> > > > Yep, but please do keep the PyUnicode for str and PyString for bytes
> > > > (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the
> > > > task of porting existing extensions... the bytearray functions should
> > > > no doubt be PyBytearray, though.
> > >
> > > Yeah, we've already planed to keep PyUnicode as prefix for str type
> > > functions. It makes perfectly sense, not only from the historical point
> > > of view.
> > >
> > > But for PyString I planed to rename the prefix to PyBytes. In my
> > > opinion we are going to regret it, when we keep too many legacy names
> > > from 2.x. In order to make the migration process easier I can add a
> > > header file that provides PyString_* functions as aliases for PyBytes_*
> >
> > +1 on only doing this via a header that must be explicitly included by
> > modules wanting the compatibility names.
>
> OK, as long as it's also supplied (and presumably empty) for 2.6 -- my
> key concern is faciitating the maintenance of a single codebase for
> C-coded Python extensions that can be compiled for both 2.6 and 3.0.
> (I'm also thinking of SWIG and similar utilities, but those can
> probably best be tweaked to emit rather different C code for the two
> cases; still, that C code will also include some C snippets hand-coded
> by the extension author/maintainer, e.g. via SWIG typemaps &c, so
> easing the "single codebase" approach may help there too).
>
> I don't think we want to go the route of code translators/generators
> for C-coded Python extensions (the way we do for Python code via
> 2to3), and the fewer #if's and #define's C extension
> authors/maintainers are required to devise (in order to support both
> 2.6 and 3.0), the likelier it is that we'll see 3.0 support in popular
> C-coded Python extensions sooner rather than later.

Speaking for myself, this isn't going to make any difference as pre-2.6 
versions of Python still need to be supported.

More of a pain is if 2.6 introduces source level incompatibilities with 2.5 
(as 2.5 did with 2.4).

Phil

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-March/077367.html below:

[Python-Dev] C-API status of Python 3?