Le Mardi 25 Octobre 2011 10:31:56 Victor Stinner a écrit :
Basically, all functions processing filenames, so most functions of
posixmodule.c. Some examples:
- os.listdir(): FindFirstFileA, FindNextFileA, FindCloseA
- os.lstat(): CreateFileA
- os.getcwdb(): getcwd()
- os.mkdir():
I propose to raise Unicode errors if a filename cannot be decoded on Windows,
instead of creating a bogus filenames with questions marks.
Can you please elaborate what APIs you are talking about exactly?
If it's the byte APIs (i.e. using bytes as file names), then I'm -1 on
this proposal.
On Tue, 25 Oct 2011 00:57:42 +0200
Victor Stinner victor.stin...@haypocalc.com wrote:
Hi,
I propose to raise Unicode errors if a filename cannot be decoded on Windows,
instead of creating a bogus filenames with questions marks. Because this
change
is incompatible with Python 3.2, even if
Le Mardi 25 Octobre 2011 13:20:12 vous avez écrit :
Victor Stinner writes:
I propose to raise Unicode errors if a filename cannot be decoded
on Windows, instead of creating a bogus filenames with questions
marks.
By bogus you mean sometimes (?) invalid and the OS will refuse to
use
Le Mardi 25 Octobre 2011 09:09:56 vous avez écrit :
I propose to raise Unicode errors if a filename cannot be decoded on
Windows, instead of creating a bogus filenames with questions marks.
Can you please elaborate what APIs you are talking about exactly?
Basically, all functions
Le Mardi 25 Octobre 2011 09:09:56 vous avez écrit :
If it's the byte APIs (i.e. using bytes as file names), then I'm -1 on
this proposal. People that explicitly use bytes for file names deserve
to get whatever exact platform semantics the platform has to offer. This
is true on Unix, and it is
My proposition is a fix to user reported by a user:
http://bugs.python.org/issue13247
So your proposal is that abspath(b.) shall raise a UnicodeError in
this case?
Are you serious???
In practice, characters not encodable to the ANSI code page are very rare.
For
example: it's difficult to
Le mardi 25 octobre 2011 00:57:42, Victor Stinner a écrit :
I propose to raise Unicode errors if a filename cannot be decoded on
Windows, instead of creating a bogus filenames with questions marks.
Because this change is incompatible with Python 3.2, even if such
filenames are unusable and I
On 10/25/2011 4:31 AM, Victor Stinner wrote:
Le Mardi 25 Octobre 2011 09:09:56 vous avez écrit :
I propose to raise Unicode errors if a filename cannot be decoded on
Windows, instead of creating a bogus filenames with questions marks.
Can you please elaborate what APIs you are talking about
In general I agree with what you write, Terry. One clarification and
one comment, though.
Terry Reedy writes:
The doc says All functions accepting path or file names accept both
bytes and string objects, and result in an object of the same type, if a
path or file name is returned. It
On Tue, Oct 25, 2011 at 8:57 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
The ANSI API uses MultiByteToWideChar (decode) and WideCharToMultiByte
(encode) functions in the default mode (flags=0): MultiByteToWideChar()
replaces undecodable bytes by '?' and WideCharToMultiByte() ignores
+1 from me!
Mark
On 25/10/2011 9:57 AM, Victor Stinner wrote:
Hi,
I propose to raise Unicode errors if a filename cannot be decoded on Windows,
instead of creating a bogus filenames with questions marks. Because this change
is incompatible with Python 3.2, even if such filenames are unusable
12 matches
Mail list logo
