Who told str() to round my int()'s!!!

[Chris Mellon]

On 8/16/07, John Nagle <nagle at animats.com> wrote:
> A.T.Hofkamp wrote:
> > On 2007-08-15, Larry Bates <larry.bates at websafe.com> wrote:
> >
> >>or the mildy
> >>amusing "how do I write bytes not characters to a file" questions at least once
> >>a week on this forum.
>
>     Actually, that's a reasonable question, and one that Python didn't do
> quite right.
>

No it isn't. You can't write anything except bytes to a file (or to a
socket, or, in fact, to any form of IO) and anyone who thinks they can
do anything different is confused.

>     Remember, in the beginning, Python had only ASCII strings, which
> were equivalent to arrays of bytes.  Then came Unicode strings.  Then
> came the restriction of ASCII chars to 0..127.  Except that you can
> still store binary bytes in ASCII strings, subject to some limitations.
>

I agree that the name of the string object is a misnomer, because it's
actually a sequence of bytes.

There's no limitation to anything you can stick it - a python 2.x
string object can contain any arbitrary sequence of bytes.

Where you may believe that you see a limitation is in the default
implicit unicode conversion, which assumes non-extended ascii and
errors on values over 127. This is a pragmatic decision which assumes
that being able to print unicode objects without hoop-jumping is
preferable to preventing the errors and confusion caused by implicit
conversion. I am not 100% certain the correct decision was made -
there's a lot of confusion on this list that would be easier to
explain if any attempt to convert unicode to bytes or vice versa
required an explicit encoding.

>     The next logical step is a complete separation of binary data handling
> from text string handling, probably using some type in "numarray" for
> arrays of bytes.
>

There are still lots of cases where it's convenient to work with
binary data as if it were ascii text, and overlap between "real"
binary data work and textual data work.

>                                         John Nagle
> --
> http://mail.python.org/mailman/listinfo/python-list
>