[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, Jason Orendorff <jason.orendorff at gmail.com> wrote:
> On 5/7/07, Guido van Rossum <guido at python.org> wrote:

> > daunting to get rid of 8-bit strings even at the Python level let
> > alone at the C level.

> Guido, if 3.x had an immutable bytes type, could 2to3 provide a
> better guarantee?  Namely, "Set your default encoding to None
> in your 2.x code today, and 2to3 will not introduce bugs around
> str/unicode."

Presumably b"  " would be the immutable version.

In some sense, this would mean that the string/unicode unification
(assuming interning; so that I can use "is" for something stronger
than __eq__) would boil down to:

    Py2.6    b"str" is "str"  == u"str"
    Py3.X    b"str" == "str"  is u"str"

with a few details like 2.5 didn't have the b"str" spelling, and 3.x
might not support the u"str" spelling.

> This might be worth doing even if you decide an immutable 8-bit
> type is wrong for the core language.  The type could be hidden
> away in an "upgradelib" module somewhere.  Surely people will
> prefer correctness over "producing nice, idiomatic 3.x code"
> in the 2to3 tool.

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.

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

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.

-jJ