On Sun, Mar 16, 2008 at 1:04 PM, Christian Heimes
Guido van Rossum wrote:
So this doesn't address merges at all. Suppose we have some C code that's shared between 2.6 and 3.0 and manipulates binary data (e.g. the gzip codec). It currently uses PyString on both branches, so any changes to the trunk merge smoothly into the py3k branch. But if you change PyString -> PyBytes in the py3k branch, every change you make in the 2.6 code will cause a merge conflict. Is that really what you want? I worry that it will effectively separate the trunk and the py3k branch, losing the advantage of doing development that effects both at once.
I'm fully aware of the extra burden. The removal of the PyInt_* functions is already causing merge conflicts and compile errors.
Even though the more popular PyInt_ APIs are still available (even if only as macros).
Nearly every C code merge contains at least one place that requires manual intervention. The PyInt merge conflicts are trivial to fix - so would errors caused PyString -> PyBytes rename.
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 not worried about the extra work since it's usually trivial and fast to fix. I'm more worried about the API names. Do you *really* want to drag down dead bodies along the road for the next ten years? The dead bodies are going to rot and stink sooner than later. By Python 3.2 everybody surely regrets the confusing names. ;)
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.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)