str() should convert ANY object to a string without EXCEPTIONS !

[Marc 'BlackJack' Rintsch]

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