On 5/8/07, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> On 5/7/07, Guido van Rossum <[EMAIL PROTECTED]> 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
