[Distutils] [Distribute] Python 3 porting effort - plans proposal for 0.7/0.8
Lennart Regebro
regebro at gmail.com
Thu Jul 23 17:51:33 CEST 2009
2009/7/23 Tarek Ziadé <ziade.tarek at gmail.com>:
> 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
More information about the Distutils-SIG
mailing list