On Sunday 02 March 2008, Alex Martelli wrote: > On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > On 3/2/08, Christian Heimes <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
