[Python-3000] [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 (original) (raw)

[Python-3000] [Python-Dev] Byte literals (was Re: [Python-checkins] Changing string constants to byte arrays ( r55119 - in python/branches/py3k-struni/Lib: codecs.py test/test_codecs.py ))

Guido van Rossum guido at python.org
Tue May 8 20:55:31 CEST 2007

On 5/8/07, Jim Jewett <jimjjewett at gmail.com> wrote:

On 5/8/07, Guido van Rossum <guido at python.org> wrote: > On 5/8/07, Jim Jewett <jimjjewett at gmail.com> wrote: > > I will be unhappy if 2to3 produces code that I can't run in (at least) > > 2.6, because then I would need to convert more than once.

> This is the first time I hear of this requirement. It has not so far > been a design goal for the conversions in 2to3. The workflow that I > have in mind (and that others have agreed to be workable) is more like > this: > 1. develop working code under 2.6 > 2. make sure it is warning-free with the special -Wpy3k option > 3. use 2to3 to convert it to 3.0 compatible syntax in a temporary directory > 4. run your unit test suite with 3.0 > 5. for any defects you find, EDIT THE 2.6 SOURCE AND GO BACK TO STEP 2 The problem is what to do after step 5 ... Do you leave your 3 code in the awkward auto-generated format, and suggest (by example) that py3 code is clunky? Do you immediately stop supporting 2.x? Or do you fork the code?

As long as you have to support 2.6, you keep developing for 2.6 and cut distros from the converted code after they pass step 5. Once you are comfortable with dropping support for 2.6 (or when 2.6 support can be relegated to a maintenance branch) you can start developing using the converted code.

I disagree that the converted code is awkward. Have you even tried the 2to3 tool yet?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list