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 :] Christian _______________________________________________ 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
