increasing the python requirement

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/6/2011 12:55 PM, Toshio Kuratomi wrote:
> On Thu, Jan 06, 2011 at 10:57:27AM +0100, Vincent Ladeuil wrote:
>>>>>>> John Barstow <jbowtie at amathaine.com> writes:
>>
>> <snip/>
>>
>>     > The recommended transition strategy is, roughly:
>>
>>     > # Port your code to Python 2.6.
>>     > # Make sure all the tests pass using that version.
>>     > # Run your code under Python 2.6 with the -3 flag.
>>     > # Fix any warnings.
>>     > # Run the tests again (still under Python 2.6).
>>     > # Run the 2to3 tool.
>>     > # Run your tests under Python 3.
>>     > # Fix any problems.
>>     > # Repeat until all tests pass.
>>
>>     > The main point for maintenance is to only write Python 2.6 code and
>>     > use 2to3 to generate a 3.x version as part of the build process. You
>>     > don't really need to create a 3.x fork until such time as you decide
>>     > to abandon Python 2.x entirely.
>>
>> That was my understanding (well, mostly based on a gut feeling rather
>> than really informed).
>>
>> Martin and Andrew have good arguments about the apparent low cost of
>> maintaining compatibility with 2.4/2.5, so I think we should just try
>> the -3 flag and 2to3 and see.
>>
> I think this is the first thing to try since my experience packaging python3
> modules from upstream is that most projects have python-2.4 compatible code.
> Then they use distribute (the setuptools fork) to run 2to3 from the setup.py
> if python3 is being used.  Now, I think bzr may be harder since it actually
> does need to work with real bytes a lot but I'm not sure that dropping
> python-2.4 compatibility makes that easier to manage.  It's just something
> someone's going to need to try to port.

At least one issue is that 2to3 doesn't work particularly well with
2.4/5 based code. Stuff like not being able to do b'foo'.

AIUI there is a compatibility shim that someone wrote, which lets you do
something like:

from compat import bytes

mystr = bytes('foo')

And on v3 it translates 'bytes()' to:

  return s.encode('ascii')

And on v2 it translates to

  return s

Sort of thing.

Which means a lot of invasive code changes to be able to support 2.4 +
3.0 via 2to3.


> 
>> This means keeping trunk in 2.x and experiment with a fork based on the
>> 2to3 results.
>>
>> If we decide to target 3 more aggressively later, we can still change
>> our mind and switch to maintaining trunk in 3 and a fork based on the
>> 3to2 results.
>>
> Note that although conceptually this is better, the 3to2 author thinks that
> 3to2 can never do as good of a job as 2to3 because python3's features are
> a superset of python2's.  So, he thinks that you'll always end up doing more
> manual work if you go this route.
> 
> -Toshio

You can always not use features that aren't available in py2.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0mTE4ACgkQJdeBCYSNAAN9IACcCtQstzAduNUbjDlYslqERPsT
zxcAn0rMg76BB0VdvaeHusOT1d7fa1yi
=qSj+
-----END PGP SIGNATURE-----