[ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Bugs item #1459808, was opened at 2006-03-28 07:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&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: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Neal Norwitz (nnorwitz) Summary: test suite should pass with -Qnew ? Initial Comment: Even though we're not going to change the default for -Q in Python 2.x, I feel that the testsuite and the stdlib should demonstrate best practices, and pass with -Qnew, at least. The following fail under 2.5-HEAD: test_builtin test_coercion test_decimal test_doctest -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 10:37 Message: Logged In: YES user_id=849994 Made test_decimal pass in rev 43385. Made test_coercion pass in revs 43385 and 43393. Fixed xdrlib and made test_xdrlib pass in rev 43394. Made test_augassign pass in rev 43395. Fixed uu, which made test_email pass in rev 43396. -- Comment By: Tim Peters (tim_one) Date: 2006-03-28 07:39 Message: Logged In: YES user_id=31435 FYI, test_builtin passes w/ or w/o -Qnew now, and I'm going to sleep :-). -- Comment By: Tim Peters (tim_one) Date: 2006-03-28 07:29 Message: Logged In: YES user_id=31435 FYI, test_doctest works w/ -Qnew now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Bugs item #1459808, was opened at 2006-03-28 07:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&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: Anthony Baxter (anthonybaxter) Assigned to: Neal Norwitz (nnorwitz) Summary: test suite should pass with -Qnew ? Initial Comment: Even though we're not going to change the default for -Q in Python 2.x, I feel that the testsuite and the stdlib should demonstrate best practices, and pass with -Qnew, at least. The following fail under 2.5-HEAD: test_builtin test_coercion test_decimal test_doctest -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 11:02 Message: Logged In: YES user_id=849994 Thomas fixed test_ctypes in rev 43397. Closing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 10:37 Message: Logged In: YES user_id=849994 Made test_decimal pass in rev 43385. Made test_coercion pass in revs 43385 and 43393. Fixed xdrlib and made test_xdrlib pass in rev 43394. Made test_augassign pass in rev 43395. Fixed uu, which made test_email pass in rev 43396. -- Comment By: Tim Peters (tim_one) Date: 2006-03-28 07:39 Message: Logged In: YES user_id=31435 FYI, test_builtin passes w/ or w/o -Qnew now, and I'm going to sleep :-). -- Comment By: Tim Peters (tim_one) Date: 2006-03-28 07:29 Message: Logged In: YES user_id=31435 FYI, test_doctest works w/ -Qnew now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459963 ] urllib2 changes header names
Bugs item #1459963, was opened at 2006-03-28 14:02 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=1459963&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Vert (vimico) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 changes header names Initial Comment: It seems that urllib2 changes the writing of any additional supplied headers, i.e. "User-Agent" becomes "User-agent", "TEST-HEADER" becomes "Test-header". A few sites do not recognize "User-agent" and insist on "User-Agent". Fix: remove all occurences of capitalize() in urllib2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459103 ] missing links beetween strftime()'s...
Bugs item #1459103, was opened at 2006-03-27 09:03 Message generated for change (Comment added) made by pylucid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&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.4 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: missing links beetween strftime()'s... Initial Comment: Ther are a few strftime(): strftime() (date method) strftime() (datetime method) strftime() (in module time) strftime() (time method) http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current But only in time.strftime() is the directives table: http://docs.python.org/lib/module-time.html#l2h-1955 That's ok, if there is a Link directly to this table, in the other modules. I suggest: set Links in the other modules to the directives table in module time. -- >Comment By: Jens Diemer (pylucid) Date: 2006-03-28 14:10 Message: Logged In: YES user_id=1330780 Yes, there is the comment "See the section on strftime() behavior." But that helps not much. I find it should be called in such a way: "See strftime() in module time" or similarly. And there are no links! Not in the CHM version and not in the online version... In the online Version the link should go to this page: http://docs.python.org/lib/module-time.html#l2h-1955 -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 00:14 Message: Logged In: YES user_id=849994 All the datetime methods refer to the "section of strftime() behavior" which is important to know. From there, there is a link to time.strftime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459963 ] urllib2 changes header names
Bugs item #1459963, was opened at 2006-03-28 14:02 Message generated for change (Comment added) made by pylucid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Vert (vimico) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 changes header names Initial Comment: It seems that urllib2 changes the writing of any additional supplied headers, i.e. "User-Agent" becomes "User-agent", "TEST-HEADER" becomes "Test-header". A few sites do not recognize "User-agent" and insist on "User-Agent". Fix: remove all occurences of capitalize() in urllib2. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 14:16 Message: Logged In: YES user_id=1330780 There are old, closed Bug-Reports: https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101 ?!?!? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-994101 ] urllib2: improper capitalization of headers
Bugs item #994101, was opened at 2004-07-19 23:22 Message generated for change (Comment added) made by pylucid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Sayre (franklinmint) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: improper capitalization of headers Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". This causes HTTP 400 errors on some servers when the request has a body, because there are two content length headers placed in the request: "Content-Length" (inserted by httplib) "Content-length" (inserted by Request.add_unredirected_header) The capitalization is incorrect, and httplib inserts Content-Length anyway, so I'm not sure why urllib2 is bothering. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 14:18 Message: Logged In: YES user_id=1330780 This isn't fixed: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 15:56 Message: Logged In: YES user_id=469548 This was fixed by the new patch jjlee provided (#997626). -- Comment By: John J Lee (jjlee) Date: 2004-07-25 20:06 Message: Logged In: YES user_id=261020 I've added a comment to 996159 which explains what's wrong and points to a new patch. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-22 22:48 Message: Logged In: YES user_id=469548 Patch is available at http://python.org/sf/996159. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-994101 ] urllib2: improper capitalization of headers
Bugs item #994101, was opened at 2004-07-19 21:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Sayre (franklinmint) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: improper capitalization of headers Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". This causes HTTP 400 errors on some servers when the request has a body, because there are two content length headers placed in the request: "Content-Length" (inserted by httplib) "Content-length" (inserted by Request.add_unredirected_header) The capitalization is incorrect, and httplib inserts Content-Length anyway, so I'm not sure why urllib2 is bothering. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 12:23 Message: Logged In: YES user_id=849994 It is. This bug report was about duplicate headers in the request, while the one you mention is about the capitalization per se. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 12:18 Message: Logged In: YES user_id=1330780 This isn't fixed: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 14:56 Message: Logged In: YES user_id=469548 This was fixed by the new patch jjlee provided (#997626). -- Comment By: John J Lee (jjlee) Date: 2004-07-25 18:06 Message: Logged In: YES user_id=261020 I've added a comment to 996159 which explains what's wrong and points to a new patch. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-22 20:48 Message: Logged In: YES user_id=469548 Patch is available at http://python.org/sf/996159. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-994101 ] urllib2: improper capitalization of headers
Bugs item #994101, was opened at 2004-07-19 23:22 Message generated for change (Comment added) made by pylucid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Sayre (franklinmint) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: improper capitalization of headers Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". This causes HTTP 400 errors on some servers when the request has a body, because there are two content length headers placed in the request: "Content-Length" (inserted by httplib) "Content-length" (inserted by Request.add_unredirected_header) The capitalization is incorrect, and httplib inserts Content-Length anyway, so I'm not sure why urllib2 is bothering. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 14:24 Message: Logged In: YES user_id=1330780 Ah, OK... Sorry ;) -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 14:23 Message: Logged In: YES user_id=849994 It is. This bug report was about duplicate headers in the request, while the one you mention is about the capitalization per se. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 14:18 Message: Logged In: YES user_id=1330780 This isn't fixed: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 15:56 Message: Logged In: YES user_id=469548 This was fixed by the new patch jjlee provided (#997626). -- Comment By: John J Lee (jjlee) Date: 2004-07-25 20:06 Message: Logged In: YES user_id=261020 I've added a comment to 996159 which explains what's wrong and points to a new patch. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-22 22:48 Message: Logged In: YES user_id=469548 Patch is available at http://python.org/sf/996159. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459963 ] urllib2 changes header names
Bugs item #1459963, was opened at 2006-03-28 12:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Vert (vimico) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 changes header names Initial Comment: It seems that urllib2 changes the writing of any additional supplied headers, i.e. "User-Agent" becomes "User-agent", "TEST-HEADER" becomes "Test-header". A few sites do not recognize "User-agent" and insist on "User-Agent". Fix: remove all occurences of capitalize() in urllib2. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 12:40 Message: Logged In: YES user_id=849994 Some normalizing is important to prevent duplicate headers. Changed capitalize() to title() to match the default casing (now user-agent becomes User-Agent) in rev. 43399. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 12:16 Message: Logged In: YES user_id=1330780 There are old, closed Bug-Reports: https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101 ?!?!? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459103 ] missing links beetween strftime()'s...
Bugs item #1459103, was opened at 2006-03-27 07:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&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.4 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: missing links beetween strftime()'s... Initial Comment: Ther are a few strftime(): strftime() (date method) strftime() (datetime method) strftime() (in module time) strftime() (time method) http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current But only in time.strftime() is the directives table: http://docs.python.org/lib/module-time.html#l2h-1955 That's ok, if there is a Link directly to this table, in the other modules. I suggest: set Links in the other modules to the directives table in module time. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 12:49 Message: Logged In: YES user_id=849994 Added inter-section links in rev. 43400. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 12:10 Message: Logged In: YES user_id=1330780 Yes, there is the comment "See the section on strftime() behavior." But that helps not much. I find it should be called in such a way: "See strftime() in module time" or similarly. And there are no links! Not in the CHM version and not in the online version... In the online Version the link should go to this page: http://docs.python.org/lib/module-time.html#l2h-1955 -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 22:14 Message: Logged In: YES user_id=849994 All the datetime methods refer to the "section of strftime() behavior" which is important to know. From there, there is a link to time.strftime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459963 ] urllib2 changes header names
Bugs item #1459963, was opened at 2006-03-28 14:02 Message generated for change (Comment added) made by vimico You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&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.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Vert (vimico) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 changes header names Initial Comment: It seems that urllib2 changes the writing of any additional supplied headers, i.e. "User-Agent" becomes "User-agent", "TEST-HEADER" becomes "Test-header". A few sites do not recognize "User-agent" and insist on "User-Agent". Fix: remove all occurences of capitalize() in urllib2. -- >Comment By: Michael Vert (vimico) Date: 2006-03-28 17:32 Message: Logged In: YES user_id=928834 I checked the database before submitting... I admit, I haven't gone back 2 years. :-) It seems to be the same bug. But it was still present in 2.4.2 (version used in Ubuntu Breezy). -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 14:40 Message: Logged In: YES user_id=849994 Some normalizing is important to prevent duplicate headers. Changed capitalize() to title() to match the default casing (now user-agent becomes User-Agent) in rev. 43399. -- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 14:16 Message: Logged In: YES user_id=1330780 There are old, closed Bug-Reports: https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101 ?!?!? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Bugs item #1458017, was opened at 2006-03-24 21:17 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log._log needs to be more forgiving... Initial Comment: The _log method of distutils' Log class executes print msg % args where args might be an empty tuple (the methods that call _log all have varargs signatures). If that's the case and msg happens to contain a % sign, it barfs. It should be more forgiving, for instance: def _log(self, level, msg, args): if level >= self.threshold: try: print msg % args except TypeError: if not args: print msg else: raise sys.stdout.flush() I just corrected this locally for our 2.3 and 2.4 installations. The above is a bit ugly, but it does allow the common case (msg contains a % but an empty args list) to pass while still catching most programmer errors. Distutils is trying to log this message (wrapped): gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/app/mysql-5.0.19/include -I/opt/app/mysql-5.0.19/include -I/opt/lang/python/include/python2.3 -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=generic I suppose it would be better if all the places in distutils which log compiler commands without extra args escaped their % signs. This seems like an acceptable compromise though. Skip -- Comment By: splitscreen (splitscreen) Date: 2006-03-28 17:45 Message: Logged In: YES user_id=1126061 Oh right, I understand now. Yeah the fix seems fine to me. Although, would it be more appropriate to check if not args: is True? So the _log() function would be something more like this: def _log(self, level, msg, args): if level >= self.threshold: if not args: print msg else: print msg % args sys.stdout.flush() Just thinking out-loud really.. not sure the check for the raised exception is really necessary. Thanks, Matt -- Comment By: Skip Montanaro (montanaro) Date: 2006-03-28 03:58 Message: Logged In: YES user_id=44345 It barfs if you pass an empty tuple and the msg argument contains a % escape. For example, try: print "%s" % () In the particular case that tripped me up, it's trying to print a (bogus) gcc command which contains % escapes while passing no args to map them. -- Comment By: splitscreen (splitscreen) Date: 2006-03-27 21:27 Message: Logged In: YES user_id=1126061 I can't reproduce on 2.4.2. Although maybe I misunderstood... Are you saying that _log() barfs when you pass an empty tuple? Passing an empty tuple to _log() works fine here.. I can understand it breaking when you pass some format string to args and the msg contains an '%', that's the developer's fault for not escaping the precentage sign. Could you clarify? Or am I totally wrong? Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458220 ] sys.maxint should be mentioned in explanation of int type
Bugs item #1458220, was opened at 2006-03-25 10:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&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.4 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: sys.maxint should be mentioned in explanation of int type Initial Comment: The Lib Reference says in section 2.3.4 (Numeric Types -- int, float, long, complex): "Plain integers (also just called integers) are implemented using long in C, which gives them at least 32 bits of precision." I think it would be helpful to insert the following sentence here: "The maximum value on your platform is sys.maxint." -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 18:03 Message: Logged In: YES user_id=849994 Added a clause in r43404. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458220&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1442493 ] IDLE shell window gets very slow when displaying long lines
Bugs item #1442493, was opened at 2006-03-03 09:45 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&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: IDLE Group: Python 2.4 Status: Open >Resolution: Wont Fix Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell window gets very slow when displaying long lines Initial Comment: I wrote a little python script that prints a large dictionary to stdout (simply using 'print mydictionary'). In fact, the type is irrelevant, what matters is that the resulting output had approx. 200,000 characters. The shell prints the dictionary into a single line, which causes the window to be almost non-responding, e.g. when I try to scroll the window. Even on a high-end PC it takes a minute or even longer to react to anything. I use Python 2.4.2 on Windows XP SP2. I am aware that it is not exactly wise to print such large objects, but I usually print return values to stdout when I debug a script, and I do not always expect an object to be that large. The average text editor handles such long lines much better. A quick workaround might be to break very long lines automagically (perhaps at around column 1000). PS: I already observed the bug some years ago. I think I even submitted it to python or idlefork a long time ago but I was unable to find it in the buglist. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-03-28 18:08 Message: Logged In: YES user_id=149084 This is a known problem with Tk/Tcl/tkinter - large output scrolls slowly. It's not something that can be fixed in IDLE. I tried it on Arch Linux - IDLE 2.5a0 - Tk 8.4. 250,000 character output not too bad , 25 sec, but 10,000 lines of 25 char takes over twice that long, so breaking the lines doesn't help. I don't see any response problem once the output completes. The situation is exponentially worse at 500,000 char. What is your use case? IDLE is designed to be an IDE. Why output such massive data? You may be interested in Squeezer, a Noam Raphael extension to IDLEfork. http://sourceforge.net/tracker/index.php? func=detail&aid=704316&group_id=9579&atid=309579 I haven't tried it myself, but it might be what you're looking for. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-10 15:18 Message: Logged In: YES user_id=341410 Generally speaking, most wrapping text controls have issues with wrapping long lines. It would seem reasonable to get the width of the text control in characters, and manually wrap all incoming lines regardless. If the existance or not of real line endings are important, one could mark which lines are manually wrapped and remove the line endings on copy (edit->copy, ctrl+c, etc.). -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-09 18:45 Message: Logged In: YES user_id=593130 I verified this with print 10*'a', also XP (home) sp2. The sluggishness continued after getting the prompt back and trying to do something simple, like 2+2, taking maybe 1/2 minute to print 4 and then the >>> prompt again. The sluggishness *also* continued after restarting the shell (^F6). This indicates that the problem is with the window, not with IDLE. Hope someone can try same on *nix system to see if general with TKinter or specific to Win systems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1442493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by tfaujour
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Ã
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 01:17
Message:
Logged In: YES
user_id=1488657
I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.
It has never appened (yet) on a Linux plateform.
I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 09:10
Message:
Logged In: YES
user_id=1434251
Wouldn't it be best to completely remove any references
to "_active" and "_cleanup"?
--
Comment By: cheops (atila-cheops)
Date: 2006-01-25 08:08
Message:
Logged In: YES
user_id=1276121
As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.
try:
list.remove(x)
except:
pass
I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:34
Message:
Logged In: YES
user_id=1434251
BTW: In my case, I call python.exe from a Windows service.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:30
Message:
Logged In: YES
user_id=1434251
I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).
In my case the same error occurs during _cleanup called
from __init__ :
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
creationflags = creationflags
File "C:\Python24\lib\subprocess.py", line 506, in
__init__
_cleanup()
File "C:\Python24\lib\subprocess.py", line 414, in
_cleanup
inst.poll()
File "C:\Python24\lib\subprocess.py", line 755, in poll
_active.remove(self)
ValueError: list.remove(x): x not in list
Is there a work-around?
--
Comment By: cheops (atila-cheops)
Date: 2005-09-19 11:29
Message:
Logged In: YES
user_id=1276121
I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this
needs input, I tried with a simpler example (pinging a number
of host concurrently) but that did not cause the bug.
--
Comment By: Peter Ã
strand (astrand)
Date: 2005-06-23 18:03
Message:
Logged In: YES
user_id=344921
I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or both platforms?
--
Comment By: cheops (atila-cheops)
Date: 2005-05-12 12:17
Message:
Logged In: YES
user_id=1276121
this might be related to bug 1183780
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.py
[ python-Bugs-1460340 ] random.sample can raise KeyError
Bugs item #1460340, was opened at 2006-03-29 00:05
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=1460340&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.sample can raise KeyError
Initial Comment:
I have only tested this in 2.3 and the relevant code in
random.py has changed in the current svn branch, but
from inspection it looks to me like the bug may still
be there.
If you initialize a dictionary as follows:
a={}.fromkeys(range(10)+range(10,100,2)+range(100,110))
then
random.sample(a,3)
raises KeyError most times that you call it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460340&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active
Bugs item #1199282, was opened at 2005-05-10 20:24
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1199282&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Ã
strand (astrand)
Summary: subprocess _active.remove(self) self not in list _active
Initial Comment:
I start a subprocess in a seperate thread (25 concurrent
threads)
in some of the threads the following error occurs
Exception in thread Thread-4:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "upgrade.py", line 45, in run
returncode = p.wait()
File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
this is the code that starts the subprocess and where I
wait for the result
p = subprocess.Popen('command', \
stdin=None,
stdout=subprocess.PIPE, \
stderr=subprocess.STDOUT,
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()
--
>Comment By: Peter Ã
strand (astrand)
Date: 2006-03-29 07:11
Message:
Logged In: YES
user_id=344921
>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example
Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2.
--
Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 01:17
Message:
Logged In: YES
user_id=1488657
I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.
It has never appened (yet) on a Linux plateform.
I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 09:10
Message:
Logged In: YES
user_id=1434251
Wouldn't it be best to completely remove any references
to "_active" and "_cleanup"?
--
Comment By: cheops (atila-cheops)
Date: 2006-01-25 08:08
Message:
Logged In: YES
user_id=1276121
As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.
try:
list.remove(x)
except:
pass
I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:34
Message:
Logged In: YES
user_id=1434251
BTW: In my case, I call python.exe from a Windows service.
--
Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 17:30
Message:
Logged In: YES
user_id=1434251
I have a similar problem.
Python 2.4.1 under MS Windows 2003,
Multi-Threaded application (about concurrent 10 threads).
In my case the same error occurs during _cleanup called
from __init__ :
File "E:\lisa_ins\ewu\coop\reporting\python\tup_lisa\util\t
hreadutil.py", line 582, in callSubProcess
creationflags = creationflags
File "C:\Python24\lib\subprocess.py", line 506, in
__init__
_cleanup()
File "C:\Python24\lib\subprocess.py", line 414, in
_cleanup
inst.poll()
File "C:\Python24\lib\subprocess.py", line 755, in poll
_active.remove(self)
ValueError: list.remove(x): x not in list
Is there a work-around?
--
Comment By: cheops (atila-cheops)
Date: 2005-09-19 11:29
Message:
Logged In: YES
user_id=1276121
I noticed this bug under windows
to reproduce the bug, I attached the script I use, but this
needs input, I tried with a simpler example (pinging a number
of host concurrently) but that did not cause the bug.
--
Comment By: Peter Ã
strand (astrand)
Date: 2005-06-23 18:03
Message:
Logged In: YES
user_id=344921
I believe it should be sufficient to add a try...except
clause around _active.remove(). Can you upload a complete
example that triggers the bug? Have you noticed this bug on
Windows, UNIX or b
[ python-Bugs-1460493 ] Why not drop the _active list?
Bugs item #1460493, was opened at 2006-03-29 07:16 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=1460493&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Why not drop the _active list? Initial Comment: I am using a modified version of subprocess.py, where I have removed the _active list and all references to it. I have tested it (under Windows 2000) and there were no errors. So what is the reason for managing the _active list at all? Why not drop it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1460493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
