[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 jimjjewett at gmail.com
Tue May 8 17:09:46 CEST 2007

On 5/8/07, Paul Moore <p.f.moore at gmail.com> wrote:
> On 08/05/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.

> IIUC, the idea is that you should be able to write valid Python 2.6
> code which 2to3 can convert automatically. There is no intention
> that 2to3 should automatically handle arbitrary 2.x code (at
> least, not without the risk of bugs).,

I thought that was indeed the goal.

> and certainly no intention that the
> *output* of 2to3 be runnable in 2.6 (in general).

Agreed that it isn't, but I think it should be.

> Yes, you convert more than once. Until you cut over, your
> 2.6 source is the master, and the output of 2to3 should be
> treated as generated code.

And you can't cut over until you're ready to abandon 2.x.

> > I would be unhappy if 2to3 produced code that I couldn't
> > safely copy; that is too magical.

> Not sure what that means.

Many people learn by example.  Many people don't even bother learning;
they just cut and paste.  If the only example Py3 code they see is
ugly and bloated, that is the idiom they will internalize.

> > I would be unhappy if 2to3 produced code that isn't a good
> > example, unless it also had (at least an option, probably a
> > default) to add comments suggesting a manual verification
> > and what could *probably* be used instead.
> I'd like 2to3 code to be at least maintainable. Surely it's too
> much to assume it's going to be a good example of idiomatic
> 3.x code, though?

Probably -- which is why it should at least be possible to focus your
attention on the parts that need manual changes.

(And, of course, the number of such places should be minimized,
particularly if you can't run the result in 2.6, since it is
effectively a fork.)


More information about the Python-3000 mailing list