[ python-Bugs-1223937 ] subprocess.py abuse of errno

2006-07-14 Thread SourceForge.net
Bugs item #1223937, was opened at 2005-06-20 08:56
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess.py abuse of errno

Initial Comment:
The CalledProcessError exception's .errno attribute is
set to a child process return code which is not an
errno. Any attempt to look up this number with
os.strerror() or errno.errorcode[] will result in
meaningless output. This can break existing code that
catches OSError and does not expect CalledProcessError.

Possible resolutions:

1. Don't make CalledProcessError a subclass of OSError
2. If CalledProcessError stays a subclass of OSError
.errno should be set to some specific meaningful value
(which one? add new value to errnomodule.c?) and use a
separate attribute for the child process return code.


--

>Comment By: Peter Åstrand (astrand)
Date: 2006-07-14 16:05

Message:
Logged In: YES 
user_id=344921

Fixed in revision 50638.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-14 05:48

Message:
Logged In: YES 
user_id=29957

Sounds fine. Please make sure to add a NEWS entry!


--

Comment By: Michael Hoffman (hoffmanm)
Date: 2006-07-11 10:16

Message:
Logged In: YES 
user_id=987664

+1 from me. Thanks.

--

Comment By: Peter Åstrand (astrand)
Date: 2006-07-11 00:53

Message:
Logged In: YES 
user_id=344921

If we fix this before Python 2.5, I guess we don't need to
think about backwards compatibility. See the attached patch
for a suggested solution. 

--

Comment By: Peter Åstrand (astrand)
Date: 2006-07-10 22:34

Message:
Logged In: YES 
user_id=344921

Bug 1376309 has been marked as a duplicate of this bug. 

--

Comment By: Peter Åstrand (astrand)
Date: 2005-06-21 22:13

Message:
Logged In: YES 
user_id=344921

I've changed my mind, since CalledProcessError is only in
the development version of Python. Perhaps it's acceptable
to change the API after all, then. Re-opening. 

--

Comment By: Peter Åstrand (astrand)
Date: 2005-06-21 17:52

Message:
Logged In: YES 
user_id=344921

In hindsight, CalledProcessError should perhaps have been
designed some other way. But now when we have it, it's not
easy to change it. 

It all comes down to what is the documented behaviour and
not. As far as I understand, there's no requirement that the
errno number or an OSError should be possible to look up
with os.strerror(). I cannot find anything about this at
http://docs.python.org/lib/module-exceptions.html, at least.
All it says is "[errno is] assumed to be an error number". 

In my opinion, code should be prepared for "unknown" error
numbers. So currently, I'm not prepared to make any changes
to CalledProcessError. (If you disagree with me, post to
python-dev and see what others think.)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223937&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows

2006-07-14 Thread SourceForge.net
Bugs item #1519069, was opened at 2006-07-08 05:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-07-14 17:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

--

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

--

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-08 05:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1522771 ] Patch #1388073 is not mentioned in NEWS

2006-07-14 Thread SourceForge.net
Bugs item #1522771, was opened at 2006-07-14 16:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Collin Winter (collinwinter)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch #1388073 is not mentioned in NEWS

Initial Comment:
This patch adds a mention of patch #1388073 (which
changed the names of several attributes on
unittest.TestCase) to the "Library" subsection of
Misc/NEWS for Python 2.5 alpha 1 (since the patch was
applied before 2.5a1 was released).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522771&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1519069 ] incorrect locale.strcoll() return in Windows

2006-07-14 Thread SourceForge.net
Bugs item #1519069, was opened at 2006-07-07 22:04
Message generated for change (Comment added) made by pez4brian
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Matherly (pez4brian)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect locale.strcoll() return in Windows

Initial Comment:
Python 2.4.2 in Windows (English locale):

>>> import locale
>>> locale.setlocale(locale.LC_ALL,'C')
'C'
>>> locale.setlocale(locale.LC_ALL,'')
'English_United States.1252'
>>> locale.strcoll("M","m")
1
>>> locale.strcoll("Ma","mz")
-1

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one string,
"M" is equal to "m"

--

>Comment By: Brian Matherly (pez4brian)
Date: 2006-07-14 22:14

Message:
Logged In: YES 
user_id=726294

Thanks for your response. That is simply unacceptable. Who
at Microsoft needs to be flogged? More likely, this shows my
lack of understanding of strings and locale in general.

Your explanation does explain the results I get, but
wouldn't you admit that the results *seem* wrong?

By the definition given, the strings "Ma", "mb", "Mc", "md"
would actually sort in that order! So the list of sorted
strings would have alternating capitalization!

However, the list of strings "M", "m", "M", "m" would sort
as "M", "M", "m", "m" - no alternating capitalization - as I
would expect.

Would there happen to be some way to sort the strings using
the locale, but also using the case earlier in the
computation order? Basically, I want the sort to be case
sensitive.

Thanks again for your response. If you have any suggestions
that might help me achieve what I want, it would be greatly
appreciated.

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-07-14 10:55

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug? We pass the string as-is to
the C library, which passes it nearly as-is to
CompareStringW. This function then decides how they collate;
in Microsoft's definition of the English_United States
locale, these strings do have the order you get.

In case you wonder how the order is computed: essentially,
the strings are compared case insensitive, without
diacritics. If they then compare equal, the diacritics are
considered. If this still compares equal, Case weights are
considered. If this still compares equal, Special weights
are considered.

(Note: I obtained this indirectly by looking at the
LCMapString documentation, assuming that CompareString uses
LCMapString with LCMAP_SORTKEY|SORT_STRINGSORT).

--

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:35

Message:
Logged In: YES 
user_id=726294

I see the same problem in python 2.4.3

--

Comment By: Brian Matherly (pez4brian)
Date: 2006-07-07 22:08

Message:
Logged In: YES 
user_id=726294

Correction:

It appears that when a string has one character, "M" is
greater than "m", but when it has more than one character,
"M" is equal to "m"

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519069&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com