[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 ))
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
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
More information about the Python-3000