On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <lists@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/)