On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <[EMAIL PROTECTED]> 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/) _______________________________________________ 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
