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

Jim Jewett jimjjewett at gmail.com
Tue May 8 16:34:26 CEST 2007

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

More information about the Python-3000 mailing list