(original) (raw)
On Thu, Apr 30, 2009 at 10:21, "Martin v. L�wis" <martin@v.loewis.de> wrote:
There are several different ways I tried it.� The easiest was to mount a vfat file system with various encodings on Linux and use the Python byte interface to write file names, then plug that flash drive into Windows.
I didn't interpret it much at all.� I'm just saying that the PEP 383 assumption that these problems can't occur on Windows isn't true.
My point remains that I think PEP 383 shouldn't be rushed through, and one should look more carefully first at what the Windows kernel does in these situations, and what Mono and Java do.
Tom
Thomas Breuel wrote:How did you do that, and what were the specific names that you
> Given the stated rationale of PEP 383, I was wondering what Windows
> actually does. �So, I created some ISO8859-15 and ISO8859-8 encoded file
> names on a device, plugged them into my Windows Vista machine, and fired
> up Python 3.0.
had chosen?
There are several different ways I tried it.� The easiest was to mount a vfat file system with various encodings on Linux and use the Python byte interface to write file names, then plug that flash drive into Windows.
�
I think you misinterpreted what you saw. To find out what way you
misinterpreted it, we would have to know what it is that you saw.
I didn't interpret it much at all.� I'm just saying that the PEP 383 assumption that these problems can't occur on Windows isn't true.
I can plug in a flash drive with malformed strings, and somewhere between the disk and Python, something maps those strings onto unicode in some way, and it's done in a way that's different from PEP 383.� Mono and Java must have their own solutions that are different from PEP 383.
My point remains that I think PEP 383 shouldn't be rushed through, and one should look more carefully first at what the Windows kernel does in these situations, and what Mono and Java do.
Tom