On Sun, Mar 16, 2008 at 11:57 AM, Benjamin Peterson <musiccomposition@gmail.com> wrote: [Guido]
That's a rather long thread. Was any conclusion reached? I'm not sure how introducing a set of aliases will help merging 2.6 code to 3.0. Can you or Christian describe the proposed approach in more detail?
As far as I can see, no objections were raised in that thread.
Hm. I had wanted to register a complaint, but I guess I was too busy.
Christian explained the probable approach: http://mail.python.org/pipermail/python-dev/2008-March/077362.html
That's not much of a plan. It doesn't discuss any of the effects of the proposed change on merging code from the 2.6 trunk to the py3k branch. On Sun, Mar 16, 2008 at 12:09 PM, Christian Heimes <lists@cheimes.de> wrote:
Guido van Rossum wrote:
-1. This will make merging code from 2.6 harder, and causes more work for porting C extensions.
I'm happy to pay the price for the sake of a clean and easy-to-recall C API.
The for the C extension problem I already proposed a solution in the thread Benjamin mentioned before.
#include "Python.h" #if PY_VERSION_HEX > 0x03000000 #include "python2_compat.h" #endif
Where python2_compat provides aliases for PyInt and PyString:
#define PyInt_Spam PyLong_Spam ... #define PyString_Egg PyBytes_Egg
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. -- --Guido van Rossum (home page: http://www.python.org/~guido/)