<div class="gmail_quote">On Thu, Apr 30, 2009 at 10:21, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Thomas Breuel wrote:<br>
> Given the stated rationale of PEP 383, I was wondering what Windows<br>
> actually does. So, I created some ISO8859-15 and ISO8859-8 encoded file<br>
> names on a device, plugged them into my Windows Vista machine, and fired<br>
> up Python 3.0.<br>
<br>
</div>How did you do that, and what were the specific names that you<br>
had chosen?</blockquote><div><br>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.<br>
</div><div> </div><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I think you misinterpreted what you saw. To find out what way you<br>
misinterpreted it, we would have to know what it is that you saw.</blockquote><div><br>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.<br>
<br>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.<br>
</div><div><br>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.<br><br>Tom<br>
<br></div></div>