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

[Alex Martelli]

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.


Alex