[Python-Dev] 2.6 and 3.0 tasks

Guido van Rossum guido at python.org
Sat Mar 22 01:18:04 CET 2008


On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum schrieb:
>
> > Even though the more popular PyInt_ APIs are still available (even if
>  > only as macros).
>
>  THe PyInt_* macros are only available when Include/intobject.h is
>  included explicitly. It's not in Python.h any more.
>
>
>  > I disagree. Bad merges are already a frequent cause of instability in
>  > 3.0. This could easily double the problems. And while I want to reduce
>  > the instability (I really wish you would no commit until all unittests
>  > pass), I also don't want the merges to cost more of your time!
>
>  I'm trying my best but sometimes I don't spot the cause of a failing
>  unit test. I got a slightly faster laptop so I'm now able to run the
>  full unit test suite every time I do a svnmerge.py.

:-)

>  > It doesn't have to be so black and white. Using the macro approach you
>  > propose we can fix the situation at any time later.
>  >
>  > We could also make the changes in 2.6, so that the 2.6 code looks the
>  > same as 3.0. (However for binary compatibility I think it would be
>  > better if in 2.6 the linker sees PyString where in 3.0 it sees
>  > PyBytes.)
>
>  Let me get this straight. You propose that we replace PyString_ with
>  PyBytes_ in both Python 2.6 and 3.0 core code. In Python 2.6 some macros
>  replace the PyBytes_* functions with PyString_ so the linker sees
>  PyString_*? Mmh, it sounds like an interesting idea :]

Right. We've done this 2-stage rename before, during the great
(sometimes known as grand) renaming, in the 1.x days.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list