Problem with -3 switch

Steve Holden steve at
Tue Jan 13 07:29:55 CET 2009

Christian Heimes wrote:
>>> Perhaps you also like to hear from a developer who has worked on Python
>>> 3.0 itself and who has done lots of work with internationalized
>>> applications. If you want to get it right you must
>>> * decode incoming text data to unicode as early as possible
>>> * use unicode for all internal text data
>>> * encode outgoing unicode as late as possible.
>>> where incoming data is read from the file system, database, network etc.
>>> This rule applies not only to Python 3.0 but to *any* application
>>> written in *any* languate.
>> The above is a story with which I'm quite familiar. However it is
>> *not* the issue!! The issue is why would anyone propose changing a
>> string constant "foo" in working 2.x code to u"foo"?
> Do I really have to repeat "use unicode for all internal text data"?
You don't have to, but apparently that wasn't sufficient to stop you.

> "foo" and u"foo" are two totally different things. The former is a byte
> sequence "\x66\x6f\x6f" while the latter is the text 'foo'. It just
> happens that "foo" and u"foo" are equal in Python 2.x because
> "foo".decode("ascii") == u"foo". In Python 3.x does it right, b"foo" is
> unequal to "foo".
People, it's really helpful if rather than just disagreeing we make
efforts to isolate the sources of the disagreement then work towards
common understanding. Otherwise we each end up shouting at each other
from our individual islands of knowledge.

For a *really*N good example of this, though one which does (eventually,
and glacially) seem to be moving towards convergence, see the "Why
cannot assign to function call" thread.

Don't try to prove yourself right, or the other person wrong: instead
seek common understanding of the issues, and resolutions thereof.

Christian: please don't regard this post as aimed specifically at your
behavior, which it isn't. It's a general (and hopefully not entirely
useless) attempt to improve the signal-to-noise ratio.

Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC    

More information about the Python-list mailing list