[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