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 them, causing a later hard-to-diagnose exception", rat
+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 [20111024 09:22], Stefan Behnel (stefan...@behnel.de) wrote:>>I agree. Given that the analysis shows that the libc memcmp() is >>particularly fast on many Linux systems, it should be up to the Python >>package maintainers for these systems to set that option extern
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 (
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 and I
consider the problem as a (Python?) bug, I would like your
On Mon, Oct 24, 2011 at 06:17, Antoine Pitrou wrote:
> On Mon, 24 Oct 2011 15:58:11 +0300
> Ezio Melotti wrote:
>>
>> I suggest to follow the following process:
>> 1) deprecate something and add a DeprecationWarning;
>> 2) decide how long the deprecation should last;
>> 3) use the deprec
Is there a reason to check for
if s[:5] == 'pass ' or s[:5] == 'PASS ':
instead of
if s[:5].lower() == 'pass'
?
If so, it should be documented; otherwise, I would rather see the more
inclusive form, that would also allow things like "Pass"
-jJ
On Sun, Oct 23, 2011 at 4:21 PM, florent.xi
On Mon, 24 Oct 2011 15:58:11 +0300
Ezio Melotti wrote:
>
> I suggest to follow the following process:
>1) deprecate something and add a DeprecationWarning;
>2) decide how long the deprecation should last;
>3) use the deprecated-remove[1] directive to document it;
>4) add a test th
Hi,
our current deprecation policy is not so well defined (see e.g. [0]),
and it seems to me that it's something like:
1) deprecate something and add a DeprecationWarning;
2) forget about it after a while;
3) wait a few versions until someone notices it;
4) actually remove it;
I suggest
There are open issues related to plat-XXX.
Le Lundi 24 Octobre 2011 00:03:42 Martin v. Löwis a écrit :
> no, we make no changes to them unless a user actually requests a change
Matthias Klose asked for socket SIO* constants in september 2006 (5 years
ago).
http://bugs.python.org/issue1565071
I
On Mon, 24 Oct 2011 13:17:53 +0200
florent.xicluna wrote:
> @@ -2557,7 +2557,7 @@
> extend() -- extend array by appending multiple elements from an iterable\n\
> fromfile() -- read items from a file object\n\
> fromlist() -- append items from the list\n\
> -fromstring() -- append items from the
-On [20111024 09:22], Stefan Behnel (stefan...@behnel.de) wrote:
>I agree. Given that the analysis shows that the libc memcmp() is
>particularly fast on many Linux systems, it should be up to the Python
>package maintainers for these systems to set that option externally thro
"Martin v. Löwis", 23.10.2011 23:44:
I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ...
(after we put memcmp in unicode_compare)
-1. We shouldn't do anything about this. Python has the tradition of not
working around platform bugs, except if the work-arounds are necessary
13 matches
Mail list logo
