2009/7/23 Tarek Ziadé <[email protected]>: > you don't seem to understand what backporting changes from a pure 3.x branch > to a 2.x compatible branch means. That's just a backport maintenance > work once the Py3K branch > has started + forwardport of part of the work done in 0.6. So there's > no "duplicate work".
You want to reimplement each feature in 0.8 for Python3 in 0.7 for Python 2. That *is* duplicate work. > As a developer, I am ok to have a mixed-code branch for a 0.7 version > that will not last, > but I don't want to work in a 2.x/3.x code soup for the future 0.8 branch. There is no 2.x/3.x code soup. > I gave you the list of benefits and I don't see any benefits in what > you are describing. I explained why your benefits do not exist. If you can't see the benefit of having one code set for one version of one software instead of two, then I'm stumped. > I'd be curious to see how "clean" your 2.x/3.x code could be. You can look at it now. It exists. http://code.google.com/p/python-incompatibility/source/browse/#svn/ports/setuptools/trunk > How do you intend for instance to have a module with named exceptions that > works in both versions, > without duplicating the code. Perhaps if you explained why you think it would be necessary to duplicate the code, I could answer. But OK, fine. I don't want to have stupid fights over stupid things. The code exists on the link above. Do whatever you want with it. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
