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

[Jim Jewett]

On 5/8/07, Guido van Rossum <guido at python.org> wrote:
> On 5/8/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> > On 5/8/07, Guido van Rossum <guido at python.org> wrote:


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

> I disagree that the converted code is awkward.

On python-dev, there was a recent discussion about changing stdlib
xrange into range.  It was pointed out that this would make conversion
harder, because range will get converted to list(xrange).

Maybe the tool has gotten smart enough to avoid constructions like:

    for k, v in list(dict.items()):

    for i in list(range(10)):

but I can't help feeling there will always be a few cases where it
makes the code longer and worse.

The hand patch for removing tuple parameters from the stdlib was
certainly better than the tool could ever be expected to generate.

I would be satisfied iIf the tool generates something like

    # 2to3:  Did you really *need* a list?
    for k, v in list(dict.items()):

and I can then change it back to

    for k, v in dict.items():

knowing it will run OK in both versions.  I will not be happy if I
have to do this editing more than once.

At the moment, I haven't seen anything that can't be expressed in code
that would run in either version.  (There might be something,
particular in str/unicode or tracebacks; I just don't remember seeing
it, so I think I could choose to avoid it for most code.)

(Note that letting the common code be less efficient in 2.x is an
acceptable tradeoff for me.  Others might prefer a way to annotate a
function or class as already dual.)

-jJ