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
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." 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 ex
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
> 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 diffic
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
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 proc
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 refus
On Tue, 25 Oct 2011 00:57:42 +0200
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 unu
> 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. Pe
+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 a
On Tue, Oct 25, 2011 at 8:57 AM, Victor Stinner
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
> unencodable characters (
12 matches
Mail list logo
