[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