On Sun, 28 Sep 2008 01:35:11 -0700, est wrote:
>> Because that's how ASCII is defined.
>> Because that's how ASCII is defined. ASCII is a 7-bit code.
>
> Then why can't python use another default encoding internally
> range(256)?
Because that doesn't suffice. Unicode code points can be >255.
> If Python choose another default encoding which handles range(256), 80%
> of python unicode encoding problems are gone.
80% of *your* problems with it *seems* to be gone then.
> It's not HARD to process unicode, it's just python & python community
> refuse to correct it.
It is somewhat hard to deal with unicode because many don't want to think
about it or don't grasp the relationship between encodings, byte values,
and characters. Including you.
>> stop dreaming of a magic solution
>
> It's not 'magic' it's a BUG. Just print 0x7F to 0xFF to console, what's
> wrong????
What do you mean by "just print 0x7F to 0xFF"? For example if I have ``s
= u'Smørebrød™'`` what bytes should ``str(s)`` produce and why those and
not others?
>> Isn't that more or less the same as telling the OP to use unicode()
>> instead of str()?
>
> sockets could handle str() only. If you throw unicode objects to a
> socket, it will automatically call str() and cause an error.
Because *you* have to tell explicitly how the unicode object should be
encoded as bytes. Python can't do this automatically because it has *no
idea* what the process at the other end of the socket expects.
Now you are complaining that Python chooses ASCII. If it is changed to
something else, like MBCS, others start complaining why it is MBCS and
not something different. See: No fix, just moving the problem to someone
else.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
