[Python-Dev] what Windows and Linux really do Re: PEP 383 (again)
"Martin v. Löwis"
martin at v.loewis.de
Thu Apr 30 11:35:02 CEST 2009
> 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.
So can you share precisely what you have done, to allow others to
> 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.
What are "these problems", and where does PEP 383 say they can't occur
on Windows? What could Python do differently on Windows?
> 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.
Of course it is. The Windows FAT driver has chosen some mapping for the
file names to Unicode, and most likely not the encoding that you meant
it to use.
There is now no way for a Win32 application to find out how the file
name is actually represented on disk, short of implementing the FAT
file system itself.
So what Python does is the best possible solution already - report the
file names as-is, with no interpretation.
> 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.
These questions really have been studied on this list for the last eight
years, over and over again. It's not being rushed.
More information about the Python-Dev