[ python-Bugs-1223937 ] subprocess.py abuse of errno
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
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
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
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