[Distutils] [Distribute] Python 3 porting effort - plans proposal for 0.7/0.8

[Tarek Ziadé]

On Thu, Jul 23, 2009 at 5:51 PM, Lennart Regebro<regebro at gmail.com> wrote:
>
> You want to reimplement each feature in 0.8 for Python3 in 0.7 for
> Python 2. That *is* duplicate work.

No, I want to backport it in 2.x syntax. Not reimplement it. That's
not code duplication.
For example if you make a change in 0.8, I'll backport it but make
sure its syntax is correct under 2.x,
because 0.7 would be Python 2.x

That's all.

>> 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

I am not sure what to look at in there, do you have a place in there
that is based on setuptools trunk ?
Does it work with 2.x and 3.x at the same time ?

>
>> 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.

For all the backwards incompatibility Python 3 introduced.
Here's a small and incomplete list of points :

1/ import statements like this :

try:
  import something # python 2
except ImportError:
   import somethingelse # python 3

2/ named exceptions (I don't think setuptools have some, but we might
need them at some point)

except Something, e:

vs

except Something as e:


3/ bytes vs string issues

If we use for instance subprocess.Popen, it return bytes, no strings,
which has side effects on the consumers.
If we use regular expressions we have to make a difference between
string matching and byte matching
etc..


4/ etc...

So I am not sure : do you want to share the same code base for 2.x and
3.x and have in the code things like:
(in pseudo code)

if python 2:
   python 2. code
if python 3:
   python 3 code

I don't want that. What I am calling a "clean" code is a code base that doesn't
deal with two incompatible versions of Python

eg having a branch for 2.x and one for 3.x instead.
And when something is done on 3.x, it's backported wrt the 2.X syntax.

So I think the best strategy is to run 2to3 and finish the work on the
code to make it pure Python3,
then to split the code in several distributions and release it for
Python 3 usage.

>
> 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.
>

That's not stupid things, and that's not a fight. I don't understand
why you are over-reacting like that.
I won't do anything with this existing code if you're not helping ;)

But It's quite important imho to have the best strategy for next
releases, and I can't picture
the same branch with bits of 2.x and 3.x syntax in it.

I've been backporting and forwardporting distutils between python 2
and 3 for 6+ months
now, and I can tell it's not a lot of work, and both sides are clean
and concise because they don't try to work for
2.x and 3.x at the same time.


Regards
Tarek