Re: [Jython-users] Binary data changed in read

[<bc...@wo...>]

[D-Man]

>Perhaps it would better for Jython to match CPython and C with respect
>to the open() function,

Keep in mind that CPython have two string types (8bit and 16bit), Jython
have only one (16bit). Matching CPython's current ability to write
unicode string to file objects would completely cripple all file I/O in
Jython <0.0 wink>

Python 2.1b1 (#11, Mar  2 2001, 11:23:29) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> f = open("x", "w")
>>> f.write(u"\u20ac")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeError: ASCII encoding error: ordinal not in range(128)

When you think about it, what should the above write into the file? The
CPython developers though (and fought) about this *a lot*, and their
best answer is: You can't! Not all of the 30+ developers on CPython
agree on that decision.

In Jython we can write such a euro-sign to a file. What it write to the
file depends on the binary flag and the encoding for your platform. When
writing in binary the byte 0xAC is always written. In text mode and on
my danish windows it write 0x80, which is Microsoft's position of the
eurosign in the danish codepage.

All in all this have worked remarkably well both during the errata's and
with Jython-2.0. It is not perfect because it overload the meaning of
the 'b' flag. So it is f.ex. not possible to get newline translation
without the encoding.

Guido has on several time said that the unicode support for file objects
is not yet complete. When CPython is improved we will improve Jython as
well.

>but require people to construct the other
>Reader/Writer objects using the Java classes?

You can do that too. It just isn't a requirement.

>I am curious as to why the "format string" style of argument was
>chosen instead of an enum style (for CPython,

Maybe Guido chose a string based mode argument because the C stdio uses
it. I dunno.

>Jython

Because CPython uses it.

>and C).  I think
>that it would be simpler for the libary implementer and easier on the
>client to use an enum type, or even different classes similar to Java
>(but easier to get one that does what you want ;-)).

regards,
finn