From noreply at sourceforge.net Mon Dec 1 01:03:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 01:03:40 2003 Subject: [Patches] [ python-Patches-851902 ] bugfix for [Bugs-850964](optparse) Message-ID: Patches item #851902, was opened at 2003-12-01 15:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: bugfix for [Bugs-850964](optparse) Initial Comment: This is a bug fix for [Bugs-850964]. subject : optparse: OptionParser.__init__'s "prog" http://www.python.org/sf/850964 I've changed get_usage, get_version, and error methods to use the instance variable, "prog", instead of calling get_prog_name() function directly. This will display "prog" name if it was provided to OptionParser's constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851902&group_id=5470 From noreply at sourceforge.net Mon Dec 1 05:43:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 05:43:04 2003 Subject: [Patches] [ python-Patches-851993 ] Refactored patch #815911 for logging with SocketHandler Message-ID: Patches item #851993, was opened at 2003-12-01 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Nobody/Anonymous (nobody) Summary: Refactored patch #815911 for logging with SocketHandler Initial Comment: Robert Olson submitted a patch which uses an exponential backoff retry scheme for SocketHandler. Robert's code, which was submitted as a derived class, has been refactored into the base SocketHandler class. There are some other minor changes e.g. to copyright dates and documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 From noreply at sourceforge.net Mon Dec 1 05:44:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 05:44:39 2003 Subject: [Patches] [ python-Patches-851993 ] Refactored patch #815911 for logging with SocketHandler Message-ID: Patches item #851993, was opened at 2003-12-01 10:43 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) >Assigned to: Raymond Hettinger (rhettinger) Summary: Refactored patch #815911 for logging with SocketHandler Initial Comment: Robert Olson submitted a patch which uses an exponential backoff retry scheme for SocketHandler. Robert's code, which was submitted as a derived class, has been refactored into the base SocketHandler class. There are some other minor changes e.g. to copyright dates and documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 From noreply at sourceforge.net Mon Dec 1 05:46:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 05:46:55 2003 Subject: [Patches] [ python-Patches-815911 ] Extension logging.handlers.SocketHandler Message-ID: Patches item #815911, was opened at 2003-10-01 15:06 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=815911&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Olson (olson) Assigned to: Nobody/Anonymous (nobody) Summary: Extension logging.handlers.SocketHandler Initial Comment: I've started using the logging SocketHandler, but don't want the absence of a server to affect the running application. The attached subclass of SocketHandler should handle the cases where a server cannot be contacted, or where the connection is dropped. If the server cannot be contacted after a drop, the connection is periodically retried using a simple exponential backoff scheme. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-12-01 10:46 Message: Logged In: YES user_id=308438 Refactored into base SocketHandler class and submitted as Patch #851993. Thanks to Robert Olson for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=815911&group_id=5470 From noreply at sourceforge.net Mon Dec 1 10:43:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 10:43:41 2003 Subject: [Patches] [ python-Patches-852140 ] keyword.py - use __contains__ and bool Message-ID: Patches item #852140, was opened at 2003-12-01 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852140&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: keyword.py - use __contains__ and bool Initial Comment: This patch provides two micro changes to keyword.py. Instead of building the dict with value 1, it is built with value True. And instead of having iskeyword be an alias of kwdict.has_key, it makes iskeyword an alias for kwdict.__contains__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852140&group_id=5470 From noreply at sourceforge.net Mon Dec 1 13:23:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 13:23:08 2003 Subject: [Patches] [ python-Patches-852226 ] tutorial - 4 minor changes Message-ID: Patches item #852226, was opened at 2003-12-01 19:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852226&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: tutorial - 4 minor changes Initial Comment: This patch changes 4 minor things in the tutorial: - around line 1080, it says there is no intelligend input line editing tool available, but there is, called idle - around line 1160, it says looping can be done over any sequence, I added the note that it really loops over an iterable - around line 1420, changed 'return 0/return 1' into 'return False/return True' - aroind line 4430, add a link to the Google c.l.py archive ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852226&group_id=5470 From noreply at sourceforge.net Mon Dec 1 13:36:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 13:37:45 2003 Subject: [Patches] [ python-Patches-852236 ] broken url in colorsys documentation Message-ID: Patches item #852236, was opened at 2003-12-01 19:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852236&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fedor Baart (siggyf) Assigned to: Nobody/Anonymous (nobody) Summary: broken url in colorsys documentation Initial Comment: The document libcolorsys.tex in the Doc/lib folder has an broken url referenced (http://www.inforamp.net/\% 7epoynton/ColorFAQ.html). I looked up the new url and found it to be at (http://www.poynton.com/ColorFAQ.html). I attached a patch which I created with windows (don't know if that messes up end-line characters). Please check if its correct before applying it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852236&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:35:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:37:07 2003 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Replace backticks with repr() Initial Comment: This patch removes most used of backticks in the standard library and replaces them with a call to repr() or uses '%r' in format string. I didn't touch the email package, the lib-old directory or test_grammar.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Mon Dec 1 16:38:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 16:38:55 2003 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Replace backticks with repr() Initial Comment: This patch removes most used of backticks in the standard library and replaces them with a call to repr() or uses '%r' in format string. I didn't touch the email package, the lib-old directory or test_grammar.py. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 22:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Mon Dec 1 17:59:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 1 17:59:34 2003 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Replace backticks with repr() Initial Comment: This patch removes most used of backticks in the standard library and replaces them with a call to repr() or uses '%r' in format string. I didn't touch the email package, the lib-old directory or test_grammar.py. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 23:59 Message: Logged In: YES user_id=89016 Updated the patch so that the test suite works again (except for test_doctest.py) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 22:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Tue Dec 2 02:37:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 02:37:52 2003 Subject: [Patches] [ python-Patches-852226 ] tutorial - 4 minor changes Message-ID: Patches item #852226, was opened at 2003-12-01 13:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852226&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: tutorial - 4 minor changes Initial Comment: This patch changes 4 minor things in the tutorial: - around line 1080, it says there is no intelligend input line editing tool available, but there is, called idle - around line 1160, it says looping can be done over any sequence, I added the note that it really loops over an iterable - around line 1420, changed 'return 0/return 1' into 'return False/return True' - aroind line 4430, add a link to the Google c.l.py archive ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-02 02:37 Message: Logged In: YES user_id=80475 #1 This is literally correct and applies to command line python. IDLE would be under text editors mentioned in the next sentence. It is not specifically mentioned because IDLE requires Tcl/Tk which is not available to on all distributions. #2 It is correct that looping can be done over any sequence. The concept of general iterables is introduced much later. This line is *very* early in the tutorial. #3 Yes, I'm applying the change. #4 The www.python.org site has no shortage of help references. I feel uncomfortable throwing beginners to the c.l.py archives which are filled with gibberish, impolite behavior, misinformation, out dated information, etc. There is good stuff in there but it takes some skill, persistence, and luck to find what is needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852226&group_id=5470 From noreply at sourceforge.net Tue Dec 2 02:50:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 02:50:31 2003 Subject: [Patches] [ python-Patches-852140 ] keyword.py - use __contains__ and bool Message-ID: Patches item #852140, was opened at 2003-12-01 10:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852140&group_id=5470 Category: Library (Lib) >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: keyword.py - use __contains__ and bool Initial Comment: This patch provides two micro changes to keyword.py. Instead of building the dict with value 1, it is built with value True. And instead of having iskeyword be an alias of kwdict.has_key, it makes iskeyword an alias for kwdict.__contains__. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-02 02:50 Message: Logged In: YES user_id=80475 Improved the patch and made the change in Lib/keyword.py 1.13. The newline reads: iskeyword = frozenset(kwlist).__contains__ Not applied to Py2.3. Those changes are limited to bugfixes, not implementation improvements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852140&group_id=5470 From noreply at sourceforge.net Tue Dec 2 02:51:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 02:51:09 2003 Subject: [Patches] [ python-Patches-851902 ] bugfix for [Bugs-850964](optparse) Message-ID: Patches item #851902, was opened at 2003-12-01 01:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851902&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Greg Ward (gward) Summary: bugfix for [Bugs-850964](optparse) Initial Comment: This is a bug fix for [Bugs-850964]. subject : optparse: OptionParser.__init__'s "prog" http://www.python.org/sf/850964 I've changed get_usage, get_version, and error methods to use the instance variable, "prog", instead of calling get_prog_name() function directly. This will display "prog" name if it was provided to OptionParser's constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851902&group_id=5470 From noreply at sourceforge.net Tue Dec 2 17:53:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 17:53:42 2003 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 15:11 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-02 23:53 Message: Logged In: YES user_id=89016 I've updated the patch (pprint.diff) so subclasses work in _safe_repr() too and I've added a few tests to test_pprint.py. IMHO the patch is OK and could be applied. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-09 01:06 Message: Logged In: YES user_id=21627 Assigning to Fred. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-08 22:06 Message: Logged In: YES user_id=13298 I have changed the patch. Instead of replacing 'typ is list' with 'issubclass(typ, list)', it is now replaced with 'issubclass(typ, list) and typ.__repr__ is typ.__list__'. This way, classes overriding __repr__ keep the current behaviour and classes that don't get the new behaviour. See also the thread on python-dev. BTW, I also expanded 2 of the 3 assert statements, so they explain what's wrong is somethings wrong. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-07 22:49 Message: Logged In: YES user_id=21627 I have reverted the patch on Fred's request. The patch does not support an overridden __repr__ implementation, and thus has to be rejected. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-07 22:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 22:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply at sourceforge.net Tue Dec 2 19:53:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 2 19:53:54 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Wed Dec 3 06:26:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 3 06:26:37 2003 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 21:09 Message generated for change (Comment added) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.4 Status: Open >Resolution: Works For Me Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- >Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-03 22:26 Message: Logged In: YES user_id=250749 I can't confirm this for sure, not having gdbm installed on my FreeBSD box, but I think that gdbm actually has only one DB file, but creates a hard link to show both filenames. Because EMX doesn't support link(), the hard link can't be created, and so the gdbm just creates one of the 2 expected files. At this point I don't think this is worth pursuing any further, as the EMX specific workaround meets the requirement, and no other platforms appear to be having problems. Therefore I am closing this patch as not requiring any further action. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-11 22:21 Message: Logged In: YES user_id=250749 OS/2 EMX specific workaround applied to whichdb.py as v1.17. Re-grouped to 2.4; lowered to priority 3. I'll prepare a version of the revised "complete" patch to take into account application of the EMX workaround after 2.3 is out the door. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-11 07:09 Message: Logged In: YES user_id=21627 I agree that the more conservative patch is better at this point; please apply it. The regroup the patch for 2.4 and leave it open (perhaps at a lower priority also). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 23:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-08 08:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply at sourceforge.net Wed Dec 3 06:42:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 3 06:42:12 2003 Subject: [Patches] [ python-Patches-766650 ] whichdb not ID'ing dbm files with GDBM backend Message-ID: Patches item #766650, was opened at 2003-07-06 21:09 Message generated for change (Settings changed) made by aimacintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Andrew I MacIntyre (aimacintyre) Summary: whichdb not ID'ing dbm files with GDBM backend Initial Comment: For the OS/2 EMX port, I build the dbm module with gdbm v1.7.3. At least with the OS/2 version of the gdbm v1.7.3 port, dbm databases consist only of the .pag file - there is no .dir file. In this case, the .pag file has the gdbm magic number. Currently whichdb fails to identify such dbm DBs on this platform because of the expectation that there be a .dir file as well as the .pag file. I'm not in any position to confirm whether the dbm module built with gdbm behaves the same way on other systems -information gratefully received on this topic. On the assumption that other platforms also have this behaviour, the attached patch attempts to detect whether a dbm DB has a gdbm signature just by checking the magic number of the .pag file. The patch involves a refactoring of the magic number code, which may be deemed inappropriate. It may be more expedient to just special case theEMX port in the dbm detection (by skipping looking for the .dir file on this platform). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-12-03 22:26 Message: Logged In: YES user_id=250749 I can't confirm this for sure, not having gdbm installed on my FreeBSD box, but I think that gdbm actually has only one DB file, but creates a hard link to show both filenames. Because EMX doesn't support link(), the hard link can't be created, and so the gdbm just creates one of the 2 expected files. At this point I don't think this is worth pursuing any further, as the EMX specific workaround meets the requirement, and no other platforms appear to be having problems. Therefore I am closing this patch as not requiring any further action. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-11 22:21 Message: Logged In: YES user_id=250749 OS/2 EMX specific workaround applied to whichdb.py as v1.17. Re-grouped to 2.4; lowered to priority 3. I'll prepare a version of the revised "complete" patch to take into account application of the EMX workaround after 2.3 is out the door. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-11 07:09 Message: Logged In: YES user_id=21627 I agree that the more conservative patch is better at this point; please apply it. The regroup the patch for 2.4 and leave it open (perhaps at a lower priority also). ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-10 23:02 Message: Logged In: YES user_id=250749 I've added a revised patch that attempts to address Martin's points. I've also added a patch that applies a workaround solely for the only platform (OS/2 EMX) known to me to have this issue, rather than trying to be fancy and all-encompassing. I incline to the view that the platform specific workaround would be safer for 2.3, with the more sophisticated approach added after the 2.3 release if appropriate. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-08 08:05 Message: Logged In: YES user_id=21627 The dbm module greatly varies in behaviour across platforms, depending on what underlying library is linked. On my Linux installation, the resulting files are identified as /tmp/u.dir: GNU dbm 1.x or ndbm database, little endian /tmp/u.pag: GNU dbm 1.x or ndbm database, little endian I recommend that you adjust your patch to take dbm.library into account, and go looking for gdbm magic only if you find that dbm is linked with gdbm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=766650&group_id=5470 From noreply at sourceforge.net Wed Dec 3 14:03:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 3 14:03:36 2003 Subject: [Patches] [ python-Patches-853488 ] Tix hlist missing entry_configure and entry_cget methods Message-ID: Patches item #853488, was opened at 2003-12-03 14:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853488&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gene Cash (gcash) Assigned to: Martin v. L?wis (loewis) Summary: Tix hlist missing entry_configure and entry_cget methods Initial Comment: The Tix hlist class doesn't have entry_configure and entry_cget methods to implement "entrycget" and "entryconfigure" as listed in the HList(n) manpage. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853488&group_id=5470 From noreply at sourceforge.net Wed Dec 3 15:16:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 3 15:16:32 2003 Subject: [Patches] [ python-Patches-750542 ] Let pprint.py use issubclass instead of is for type checking Message-ID: Patches item #750542, was opened at 2003-06-07 15:11 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Let pprint.py use issubclass instead of is for type checking Initial Comment: Hi, subclasses of dict, list, tuple etc. should be pretty-printed according to the same rules as dict, list and tuple themselves. Because of that, this patch changes pprint.py so that rather than checking types using 'typ is list', pprint checks types using 'issubclass(typ, list)'. Gerrit Holl Patched against latest CVS ( 07/06/2003 13:11:24 UTC) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-03 21:16 Message: Logged In: YES user_id=89016 Checked in as: Lib/pprint.py 1.27 Lib/test/test_pprint.py 1.12 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-02 23:53 Message: Logged In: YES user_id=89016 I've updated the patch (pprint.diff) so subclasses work in _safe_repr() too and I've added a few tests to test_pprint.py. IMHO the patch is OK and could be applied. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-09 01:06 Message: Logged In: YES user_id=21627 Assigning to Fred. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-08 22:06 Message: Logged In: YES user_id=13298 I have changed the patch. Instead of replacing 'typ is list' with 'issubclass(typ, list)', it is now replaced with 'issubclass(typ, list) and typ.__repr__ is typ.__list__'. This way, classes overriding __repr__ keep the current behaviour and classes that don't get the new behaviour. See also the thread on python-dev. BTW, I also expanded 2 of the 3 assert statements, so they explain what's wrong is somethings wrong. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-07 22:49 Message: Logged In: YES user_id=21627 I have reverted the patch on Fred's request. The patch does not support an overridden __repr__ implementation, and thus has to be rejected. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-07 22:31 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as pprint.py 1.25. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-07 22:30 Message: Logged In: YES user_id=3066 >From python-dev: http://mail.python.org/pipermail/python-dev/2003-June/036008.html Hmm; this patch was never assigned to me, so I was unaware that anyone thought there was a problem with this. I specifically considered making changes like these when subclassing built-in types became possible, but decided against it since it didn't appear reasonable to assume that __repr__() hadn't been redefined. I'm sure it's possible to check, but to do so cleanly and efficiently seems like a huge change to the module for little value. I think the patch, as it stands, should be reverted. If another patch appears that addresses the issue of overridden __repr__() methods, it should be considered again. -1 for the patch as applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=750542&group_id=5470 From noreply at sourceforge.net Thu Dec 4 03:05:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 4 03:05:21 2003 Subject: [Patches] [ python-Patches-853890 ] Optional keyword unicode args not handled correctly Message-ID: Patches item #853890, was opened at 2003-12-04 03:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853890&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Optional keyword unicode args not handled correctly Initial Comment: Added a case for 'u' in skipitem in getargs.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853890&group_id=5470 From noreply at sourceforge.net Thu Dec 4 14:13:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 4 14:13:21 2003 Subject: [Patches] [ python-Patches-853963 ] Implement lazy read for sockets Message-ID: Patches item #853963, was opened at 2003-12-04 02:57 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853963&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Implement lazy read for sockets Initial Comment: When a socket is transformed into a file object using the makefile() method, the resulting object read() behaviour requires that read(N) returns N characters or that the end of stream be reached. This causes problems with XML parsers which call read(BufferSize) to get "something", not necessarily a full buffer. The following patch adds a "lazy" attribute to each socket._fileobject instance, the default being set to False in order to be backward compatible. If this attribute is set to True, read(N) will return at least one character unless the end of stream is reached, and no more than N characters. ---------------------------------------------------------------------- Comment By: Samuel Tardieu (samtardieu) Date: 2003-12-04 03:47 Message: Logged In: YES user_id=131394 Note: the original problem description came by Pierre Palatin . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=853963&group_id=5470 From noreply at sourceforge.net Thu Dec 4 20:24:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 4 20:24:52 2003 Subject: [Patches] [ python-Patches-854484 ] ConfigParser should raise an error for duplicate options Message-ID: Patches item #854484, was opened at 2003-12-04 19:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854484&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark McEahern (mceahm) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser should raise an error for duplicate options Initial Comment: ConfigParser should raise an error for duplicate options within a section; e.g., [test] key=value1 key=value2 but currently, it silently adds only one of the duplicate options to the section (since options are stored in a dictionary, keyed by option name). Suggested checkin comments: * Added an Error for DuplicateOptionError. * Modified _readfp() to raise DuplicateOptionError when a duplicate option is found within a section. * Added a test case to verify that the error is raised. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854484&group_id=5470 From noreply at sourceforge.net Fri Dec 5 10:32:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 10:32:36 2003 Subject: [Patches] [ python-Patches-854796 ] Disable POSIX for certain/older NetBSD versions Message-ID: Patches item #854796, was opened at 2003-12-05 16:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Disable POSIX for certain/older NetBSD versions Initial Comment: The attached patch we have in NetBSD's pkgsrc and disables _XOPEN_SOURCE_EXTENDED for NetBSD 1.5*, 1.6, 1.6.* and NetBSD(-current) NetBSD 1.6[A-S]. This are the versions prior _NETBSD_SOURCE. And without this change non-POSIX functions like eg. os.setgroups are unavailable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 From noreply at sourceforge.net Fri Dec 5 11:33:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 11:33:14 2003 Subject: [Patches] [ python-Patches-854853 ] shutil.copyfile destroys hard links (Bug [ 851123 ]) Message-ID: Patches item #854853, was opened at 2003-12-05 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfile destroys hard links (Bug [ 851123 ]) Initial Comment: shutil.copyfile(src,dst) will destroy src if dst is a hard or symbolic link to src. (This is bug [851123].) There was a version of patch [ 604600 ] For Bug [ 490168 ] which sought to address this problem but it wasn't implemented properly. My patch checks for the existence of os.path.samefile(), (which on posix systems follows symlinks) and uses that as a guard if available. It catches the exception raised by samefile() if dst does not exist. (It also catches the exception raised if src does not exist, but this doesn't matter since that condition will cause a new exception in the next part of the code.) I have included test code, which tests for the bug only if os.symlink exists. If there is a platform with symlink but not samefile, the test will fail; I think that would indicate more fixing of shutil.py is required. I avoided using tempfile.mktemp to a degree since that function is now deprecated. I made a judgement call that calling mktemp with a private temp dir (from mkdtemp) is safe. Perhaps in a private temp dir we can just use a hard-coded filename, if mktemp is really despised. Since this is just a bugfix I included no doc updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854853&group_id=5470 From noreply at sourceforge.net Fri Dec 5 14:08:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 14:08:28 2003 Subject: [Patches] [ python-Patches-854796 ] Disable POSIX for certain/older NetBSD versions Message-ID: Patches item #854796, was opened at 2003-12-05 16:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Disable POSIX for certain/older NetBSD versions Initial Comment: The attached patch we have in NetBSD's pkgsrc and disables _XOPEN_SOURCE_EXTENDED for NetBSD 1.5*, 1.6, 1.6.* and NetBSD(-current) NetBSD 1.6[A-S]. This are the versions prior _NETBSD_SOURCE. And without this change non-POSIX functions like eg. os.setgroups are unavailable. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-05 20:08 Message: Logged In: YES user_id=21627 Doesn't 1.6.* talk about future versions? It should not do that, instead, it should explicitly list all versions to which the patch applies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 From noreply at sourceforge.net Fri Dec 5 14:13:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 14:13:09 2003 Subject: [Patches] [ python-Patches-845306 ] socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) Message-ID: Patches item #845306, was opened at 2003-11-19 19:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Bachmann (matt979) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) Initial Comment: Fixes Bug #818490 socketmodule.c will not compile on platforms without IPV6 support such as Solaris 5.7 because the AF_INET6 and INET_ADDRSTRLEN are used outside the ENABLE_IPV6 guarded sections. For example (lines 2971-2977): #ifndef ENABLE_IPV6 if(af == AF_INET6) { PyErr_SetString(socket_error, "can't use AF_INET6, IPv6 is disabled"); return NULL; } #endif The code is putting error checking in when IPV6 is not supported, but it is using the AF_INET6 define which does not exist on platforms w/o IPV6. I simply removed the block and let the check fall to the inet_pton call. I'm not so clear as what to do w/ INET_ADDRSTRLEN define because I'm not knowledgable about its history. At least under Solaris, INET_ADDRSTRLEN along with INET6_ADDRSTRLEN only appear w/ IPV6 support. In the patch, I simply substituted it with 16 which is the value. Since its just the number of characters in a dotted IP address, it seems like it would be pretty constant accross platforms. The diff given is against the r232 cvs tag. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-05 20:13 Message: Logged In: YES user_id=21627 The patch is incorrect: The block checking for AF_INET6 should not be removed. On some systems, AF_INET6 might be available, and using it with disabled IPv6 should cause an exception. Instead, you should check whether AF_INET6 is defined also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470 From noreply at sourceforge.net Fri Dec 5 14:18:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 14:18:57 2003 Subject: [Patches] [ python-Patches-854796 ] Disable POSIX for certain/older NetBSD versions Message-ID: Patches item #854796, was opened at 2003-12-05 16:32 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Disable POSIX for certain/older NetBSD versions Initial Comment: The attached patch we have in NetBSD's pkgsrc and disables _XOPEN_SOURCE_EXTENDED for NetBSD 1.5*, 1.6, 1.6.* and NetBSD(-current) NetBSD 1.6[A-S]. This are the versions prior _NETBSD_SOURCE. And without this change non-POSIX functions like eg. os.setgroups are unavailable. ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-12-05 20:18 Message: Logged In: YES user_id=205 Indeed, tt does talk about future versions, but only of the maintenance branch. No interface changes will haben there. (Especially not wrt POSIX). These will happen with NetBSD 2.0 and are in NetBSD-current (1.6[A-Z]*) right now. (So, actually 1.6A is "newer" than 1.6.*) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-05 20:08 Message: Logged In: YES user_id=21627 Doesn't 1.6.* talk about future versions? It should not do that, instead, it should explicitly list all versions to which the patch applies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854796&group_id=5470 From noreply at sourceforge.net Fri Dec 5 14:40:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 14:40:23 2003 Subject: [Patches] [ python-Patches-845306 ] socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) Message-ID: Patches item #845306, was opened at 2003-11-19 13:36 Message generated for change (Comment added) made by matt979 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Bachmann (matt979) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c: fix for platforms w/o IPV6 (i.e.Solaris 5.7) Initial Comment: Fixes Bug #818490 socketmodule.c will not compile on platforms without IPV6 support such as Solaris 5.7 because the AF_INET6 and INET_ADDRSTRLEN are used outside the ENABLE_IPV6 guarded sections. For example (lines 2971-2977): #ifndef ENABLE_IPV6 if(af == AF_INET6) { PyErr_SetString(socket_error, "can't use AF_INET6, IPv6 is disabled"); return NULL; } #endif The code is putting error checking in when IPV6 is not supported, but it is using the AF_INET6 define which does not exist on platforms w/o IPV6. I simply removed the block and let the check fall to the inet_pton call. I'm not so clear as what to do w/ INET_ADDRSTRLEN define because I'm not knowledgable about its history. At least under Solaris, INET_ADDRSTRLEN along with INET6_ADDRSTRLEN only appear w/ IPV6 support. In the patch, I simply substituted it with 16 which is the value. Since its just the number of characters in a dotted IP address, it seems like it would be pretty constant accross platforms. The diff given is against the r232 cvs tag. ---------------------------------------------------------------------- >Comment By: Matthew Bachmann (matt979) Date: 2003-12-05 14:40 Message: Logged In: YES user_id=912994 Sounds good. I guarded that code with: #if ! defined(ENABLE_IPV6) && defined(AF_INET6) Uploaded attached new patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-05 14:13 Message: Logged In: YES user_id=21627 The patch is incorrect: The block checking for AF_INET6 should not be removed. On some systems, AF_INET6 might be available, and using it with disabled IPv6 should cause an exception. Instead, you should check whether AF_INET6 is defined also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=845306&group_id=5470 From noreply at sourceforge.net Fri Dec 5 15:39:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 15:39:29 2003 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Steve Purcell (purcell) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-05 21:39 Message: Logged In: YES user_id=11105 I've brought the patch up to date with current cvs, and made small changes: The 'Traceback: most recent call last' line is no longer removed from the print. And, according to Steve's suggestion, AssertionError is used again instead of the TestFailed exceptiom. The patch has been discussed in this thread on python-dev: http://mail.python.org/pipermail/python-dev/2003-December/040623.html New patch attached: unittest-3.diff ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-10-16 23:32 Message: Logged In: YES user_id=21477 I'm looking at all this and will certainly incorporate some of the suggestions: - I'm +1 on the clearer message for assertRaises() - I'm +1 on clearer messages for _all_ assert*()/fail*() methods - The TestFailed exception doesn't really add much, since AssertionError works well already - I'm loathe to ever suppress tracebacks, or fiddle with them much: the traceback is the canonical way for IDEs to find lines in the code ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 20:05 Message: Logged In: YES user_id=11105 Assigned to Steve for pronouncement (didn't he already comment on python-dev some time ago?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 22:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 22:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 21:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 09:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply at sourceforge.net Fri Dec 5 15:41:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 15:41:20 2003 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Steve Purcell (purcell) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-05 21:41 Message: Logged In: YES user_id=11105 Attached a test script together with what is printed before and after the patch: test_sample.py ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:39 Message: Logged In: YES user_id=11105 I've brought the patch up to date with current cvs, and made small changes: The 'Traceback: most recent call last' line is no longer removed from the print. And, according to Steve's suggestion, AssertionError is used again instead of the TestFailed exceptiom. The patch has been discussed in this thread on python-dev: http://mail.python.org/pipermail/python-dev/2003-December/040623.html New patch attached: unittest-3.diff ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-10-16 23:32 Message: Logged In: YES user_id=21477 I'm looking at all this and will certainly incorporate some of the suggestions: - I'm +1 on the clearer message for assertRaises() - I'm +1 on clearer messages for _all_ assert*()/fail*() methods - The TestFailed exception doesn't really add much, since AssertionError works well already - I'm loathe to ever suppress tracebacks, or fiddle with them much: the traceback is the canonical way for IDEs to find lines in the code ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 20:05 Message: Logged In: YES user_id=11105 Assigned to Steve for pronouncement (didn't he already comment on python-dev some time ago?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 22:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 22:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 21:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 09:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply at sourceforge.net Fri Dec 5 16:40:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 16:40:23 2003 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 13:49 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Steve Purcell (purcell) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 16:40 Message: Logged In: YES user_id=6380 I love it! We're all waiting for a +1 from Steve so this can be checked into 2.4. (I'd love it in 2.3 too, but that's probably going to be blocked on the "no new features" rule. :-) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 15:41 Message: Logged In: YES user_id=11105 Attached a test script together with what is printed before and after the patch: test_sample.py ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 15:39 Message: Logged In: YES user_id=11105 I've brought the patch up to date with current cvs, and made small changes: The 'Traceback: most recent call last' line is no longer removed from the print. And, according to Steve's suggestion, AssertionError is used again instead of the TestFailed exceptiom. The patch has been discussed in this thread on python-dev: http://mail.python.org/pipermail/python-dev/2003-December/040623.html New patch attached: unittest-3.diff ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-10-16 17:32 Message: Logged In: YES user_id=21477 I'm looking at all this and will certainly incorporate some of the suggestions: - I'm +1 on the clearer message for assertRaises() - I'm +1 on clearer messages for _all_ assert*()/fail*() methods - The TestFailed exception doesn't really add much, since AssertionError works well already - I'm loathe to ever suppress tracebacks, or fiddle with them much: the traceback is the canonical way for IDEs to find lines in the code ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 14:05 Message: Logged In: YES user_id=11105 Assigned to Steve for pronouncement (didn't he already comment on python-dev some time ago?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 16:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 16:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 15:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 03:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 08:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 07:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-19 22:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 11:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply at sourceforge.net Fri Dec 5 18:07:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 18:07:06 2003 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Steve Purcell (purcell) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-12-06 00:07 Message: Logged In: YES user_id=11105 Cool, although after some thought I again like the TestFailed more than the AssertionError. (But I won't insist) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 22:40 Message: Logged In: YES user_id=6380 I love it! We're all waiting for a +1 from Steve so this can be checked into 2.4. (I'd love it in 2.3 too, but that's probably going to be blocked on the "no new features" rule. :-) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:41 Message: Logged In: YES user_id=11105 Attached a test script together with what is printed before and after the patch: test_sample.py ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:39 Message: Logged In: YES user_id=11105 I've brought the patch up to date with current cvs, and made small changes: The 'Traceback: most recent call last' line is no longer removed from the print. And, according to Steve's suggestion, AssertionError is used again instead of the TestFailed exceptiom. The patch has been discussed in this thread on python-dev: http://mail.python.org/pipermail/python-dev/2003-December/040623.html New patch attached: unittest-3.diff ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-10-16 23:32 Message: Logged In: YES user_id=21477 I'm looking at all this and will certainly incorporate some of the suggestions: - I'm +1 on the clearer message for assertRaises() - I'm +1 on clearer messages for _all_ assert*()/fail*() methods - The TestFailed exception doesn't really add much, since AssertionError works well already - I'm loathe to ever suppress tracebacks, or fiddle with them much: the traceback is the canonical way for IDEs to find lines in the code ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 20:05 Message: Logged In: YES user_id=11105 Assigned to Steve for pronouncement (didn't he already comment on python-dev some time ago?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 22:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 22:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 21:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 09:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply at sourceforge.net Fri Dec 5 18:18:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 5 18:18:19 2003 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 13:49 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Steve Purcell (purcell) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 18:18 Message: Logged In: YES user_id=6380 Thomas, Can you make the TestFailed issue a separate bug/patch/feature request? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 18:07 Message: Logged In: YES user_id=11105 Cool, although after some thought I again like the TestFailed more than the AssertionError. (But I won't insist) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 16:40 Message: Logged In: YES user_id=6380 I love it! We're all waiting for a +1 from Steve so this can be checked into 2.4. (I'd love it in 2.3 too, but that's probably going to be blocked on the "no new features" rule. :-) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 15:41 Message: Logged In: YES user_id=11105 Attached a test script together with what is printed before and after the patch: test_sample.py ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 15:39 Message: Logged In: YES user_id=11105 I've brought the patch up to date with current cvs, and made small changes: The 'Traceback: most recent call last' line is no longer removed from the print. And, according to Steve's suggestion, AssertionError is used again instead of the TestFailed exceptiom. The patch has been discussed in this thread on python-dev: http://mail.python.org/pipermail/python-dev/2003-December/040623.html New patch attached: unittest-3.diff ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-10-16 17:32 Message: Logged In: YES user_id=21477 I'm looking at all this and will certainly incorporate some of the suggestions: - I'm +1 on the clearer message for assertRaises() - I'm +1 on clearer messages for _all_ assert*()/fail*() methods - The TestFailed exception doesn't really add much, since AssertionError works well already - I'm loathe to ever suppress tracebacks, or fiddle with them much: the traceback is the canonical way for IDEs to find lines in the code ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 14:05 Message: Logged In: YES user_id=11105 Assigned to Steve for pronouncement (didn't he already comment on python-dev some time ago?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 16:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 16:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 15:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 03:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 08:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 08:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 07:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-19 22:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 11:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply at sourceforge.net Sat Dec 6 00:28:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 6 00:28:16 2003 Subject: [Patches] [ python-Patches-855195 ] fix typos Message-ID: Patches item #855195, was opened at 2003-12-06 14:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855195&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: fix typos Initial Comment: This patch is to fix document typos. Some typos are in the sample codes. * libbsddb.tex >>> 8 in db True s/8/'8' * libfcntl.tex >>> import array, fnctl, struct, termios, os s/fnctl/fcntl 'fnctl' can also be found in lib/test_libfcntl.py. * libcurses.tex Echoing of input characters is turned off, s/,/. The sentence should end with a period, not a comma. * libitertools.tex There's no mention of what the default value of itertools.count() is, although it is apparent from the Python equivalent code. So I added it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855195&group_id=5470 From noreply at sourceforge.net Sat Dec 6 08:19:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 6 08:19:43 2003 Subject: [Patches] [ python-Patches-722638 ] Better output for unittest Message-ID: Patches item #722638, was opened at 2003-04-16 19:49 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Steve Purcell (purcell) Summary: Better output for unittest Initial Comment: This patch enables more useful output for unittests: If a test crashes (raises an unexpected exception), a full traceback is printed. If a test failes, the output is something like this: ======================================== FAIL: test_failUnlessEqual (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: 0 != 1 File "xunit.py", line 12, in test_failUnlessEqual self.failUnlessEqual(self.a, self.b) ======================================== Before, this was printed: ======================================== FAIL: test_failIfEqual (__main__.FailingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "xunit.py", line 15, in test_failIfEqual self.failIfEqual(self.a, self.a) File "c:\python23\lib\unittest.py", line 300, in failIfEqual raise self.failureException, AssertionError: 0 == 0 ======================================== If needed, I can upload the test script I use, together with the results before and after the patch. This has shortly been discussed on c.l.p, response was mostly positive. http://tinyurl.com/9obf ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2003-12-06 14:19 Message: Logged In: YES user_id=21477 Hi all, I've accepted this patch, with some modifications, and checked it into both Pyunit and Python CVS. If the callable passed to assertRaises() throws an exception other than the one expected, the test result should really be ERROR; the proposed changes to assertRaises() resulted in tracebacks for such unexpected exceptions being lost, since only the exception name and message were formatted into the failure string. I've therefore left the logic there as it was. Also, rather than hard-code the number of levels of traceback to skip, the changes I have checked in automatically determine the number of levels to skip. Please take a look and tell me if the trick I have used is excessively horrible. As for the separate TestFailed issue, for me this is not terribly attractive, since I know that many people find it very convenient to use the 'assert' keyword in their test code. (Note that by setting the 'failureException' attribute of your test cases, you can use an exception other than AssertionError.) For your reference, the output of Thomas' sample test script is now as follows: FFE ====================================================================== ERROR: test_4 (__main__.MyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "heller.py", line 21, in test_4 self.assertRaises(ValueError, getattr, self, "spam") File "/export/home/steve/projects/pyunit/pyunit-cvs/unittest.py", line 319, in failUnlessRaises callableObj(*args, **kwargs) AttributeError: 'MyTestCase' object has no attribute 'spam' ====================================================================== FAIL: test_1 (__main__.MyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "heller.py", line 6, in test_1 self.do_this() File "heller.py", line 9, in do_this self.do_that() File "heller.py", line 12, in do_that self.failUnlessEqual(1, 2) AssertionError: 1 != 2 ====================================================================== FAIL: test_3 (__main__.MyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "heller.py", line 17, in test_3 self.assertRaises(AttributeError, getattr, self, "silly") AssertionError: AttributeError not raised ---------------------------------------------------------------------- Ran 3 tests in 0.008s FAILED (failures=2, errors=1) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-06 00:18 Message: Logged In: YES user_id=6380 Thomas, Can you make the TestFailed issue a separate bug/patch/feature request? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-06 00:07 Message: Logged In: YES user_id=11105 Cool, although after some thought I again like the TestFailed more than the AssertionError. (But I won't insist) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-12-05 22:40 Message: Logged In: YES user_id=6380 I love it! We're all waiting for a +1 from Steve so this can be checked into 2.4. (I'd love it in 2.3 too, but that's probably going to be blocked on the "no new features" rule. :-) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:41 Message: Logged In: YES user_id=11105 Attached a test script together with what is printed before and after the patch: test_sample.py ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-12-05 21:39 Message: Logged In: YES user_id=11105 I've brought the patch up to date with current cvs, and made small changes: The 'Traceback: most recent call last' line is no longer removed from the print. And, according to Steve's suggestion, AssertionError is used again instead of the TestFailed exceptiom. The patch has been discussed in this thread on python-dev: http://mail.python.org/pipermail/python-dev/2003-December/040623.html New patch attached: unittest-3.diff ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-10-16 23:32 Message: Logged In: YES user_id=21477 I'm looking at all this and will certainly incorporate some of the suggestions: - I'm +1 on the clearer message for assertRaises() - I'm +1 on clearer messages for _all_ assert*()/fail*() methods - The TestFailed exception doesn't really add much, since AssertionError works well already - I'm loathe to ever suppress tracebacks, or fiddle with them much: the traceback is the canonical way for IDEs to find lines in the code ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 20:05 Message: Logged In: YES user_id=11105 Assigned to Steve for pronouncement (didn't he already comment on python-dev some time ago?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 22:27 Message: Logged In: YES user_id=31435 That's why I'm split: I do like the new *messages* better (their content), but I don't like losing the tracebacks. Sometimes it's a bug in the test driver-- or in 20 layers of test driver code --and sometimes it's even a bug in unittest itself. The traceback is a fundamental tool when things go wrong, so I'm never in favor of hiding parts of tracebacks (hiding could be appropriate if you *knew* the true cause isn't in the part you're hiding -- but you can't know that). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-05-06 22:08 Message: Logged In: YES user_id=11105 That's exactly how I was feeling. When an assertRaises test failed, I usually inserted the call it made before this line, to see the real traceback. And that's what this patch tries to fix. I don't want to see tracebacks when a test fails, I want a clear indication that it failed (the patch prints "TestFailed" instead of "Traceback:"). For the output of a failed assertRaises, see the first comment I added. IMO it clearly says what which exception was expected, and which one was raised. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-06 21:52 Message: Logged In: YES user_id=31435 I'm split. The current output when assertRaises fails is a frequent cause of head-scratching ("what? it's complaining because ValueError got raised? ... no, it's complaining because ValueError wasn't raised? ..."). OTOH, I see no value in trimming the traceback. Now that *could* be because the assertRaises output can be so confusing that we end up using the rest of the traceback to figure out what unittest is trying to tell us in those cases. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-06 09:11 Message: Logged In: YES user_id=80475 I would like to see Thomas's patch or some comformant variant go in. Usability problems are a bug. Friendlier output makes it more likely that unittest will be used in the first place. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:52 Message: Logged In: YES user_id=11105 Last attempt to convince you: I could try to port the changes to Python 1.5, if you want to stay compatible. If you still reject the patch (you're the unittest boss), I'll have to live with subclassing unittest ;-) ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 14:37 Message: Logged In: YES user_id=21477 After investigation, this seems to work with Jython (though not JPython, which didn't have tb_next etc.). In general I've been trying hard to keep 'unittest.py' vanilla, since a lot of people are still using it with Python 1.5 and even JPython. Hence the complete absence of string methods, list comprehensions and other new language features. Don't know if this policy makes sense in the longer term, but I value it right now. In that sense, I'm not sure if it's worth changing the message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-25 14:05 Message: Logged In: YES user_id=11105 What a pity! What exactly does not work in Jython? Before giving up on this, there are at least two ways to proceed: - Behave as before in Jython, and use the better output in CPython. - Apply this patch only the the unittest version bundled with CPython. How are the chances for one of this? ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-04-25 13:52 Message: Logged In: YES user_id=21477 This behaviour of trimming the traceback was implemented in a previous version of PyUnit, but dropped because it did not work with Jython. My aim is that the same 'unittest.py' should work out of the box with both CPython and Jython. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-04-20 04:57 Message: Logged In: YES user_id=357491 I like the new output, personally. I am +1 on letting Thomas add the changes. Does this mean we no longer treat unittest as a separate project? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-04-17 17:31 Message: Logged In: YES user_id=11105 Attaching new version of the patch (unittest-2.diff). This gives better output for failUnlessRaises, like this: ====================================================================== FAIL: test_failUnlessRaises (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError got: 'ValueError: 10' File "xunit.py", line 18, in test_failUnlessRaises self.failUnlessRaises(TypeError, self._raise, ValueError, 10) ====================================================================== FAIL: test_failUnlessRaises_2 (__main__.FailingTests) ---------------------------------------------------------------------- TestFailed: wrong exception, expected TypeError, IndexError, or AttributeError got: 'ValueError: 10' File "xunit.py", line 21, in test_failUnlessRaises_2 self.failUnlessRaises((TypeError, IndexError, AttributeError), self._raise, ValueError, 10) ---------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=722638&group_id=5470 From noreply at sourceforge.net Sat Dec 6 08:25:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 6 08:25:37 2003 Subject: [Patches] [ python-Patches-804212 ] unittest's main don't handle TestSuite in command line Message-ID: Patches item #804212, was opened at 2003-09-11 08:52 Message generated for change (Comment added) made by purcell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Pending Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Steve Purcell (purcell) Summary: unittest's main don't handle TestSuite in command line Initial Comment: When using unittest's "main" it fails if in the command line a name of TestSuite class is given. Suppose ts.py is: ---- #!/usr/bin/env python from unittest import TestCase, makeSuite, main class T(TestCase): def test_moo(self): self.fail() test_suite = makeSuite(T, "test_") if __name__ == "__main__": main() ---- Then running "ts.py test_suite" will fail. Attached is a patch for unittest.py Miki ---------------------------------------------------------------------- >Comment By: Steve Purcell (purcell) Date: 2003-12-06 14:25 Message: Logged In: YES user_id=21477 This is fixed in Python and PyUnit CVS, and will be released either with 2.3.3 or 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804212&group_id=5470 From noreply at sourceforge.net Sun Dec 7 07:05:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 07:05:57 2003 Subject: [Patches] [ python-Patches-855195 ] fix typos Message-ID: Patches item #855195, was opened at 2003-12-06 00:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855195&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: fix typos Initial Comment: This patch is to fix document typos. Some typos are in the sample codes. * libbsddb.tex >>> 8 in db True s/8/'8' * libfcntl.tex >>> import array, fnctl, struct, termios, os s/fnctl/fcntl 'fnctl' can also be found in lib/test_libfcntl.py. * libcurses.tex Echoing of input characters is turned off, s/,/. The sentence should end with a period, not a comma. * libitertools.tex There's no mention of what the default value of itertools.count() is, although it is apparent from the Python equivalent code. So I added it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855195&group_id=5470 From noreply at sourceforge.net Sun Dec 7 08:05:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 08:05:38 2003 Subject: [Patches] [ python-Patches-855195 ] fix typos Message-ID: Patches item #855195, was opened at 2003-12-06 00:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855195&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: fix typos Initial Comment: This patch is to fix document typos. Some typos are in the sample codes. * libbsddb.tex >>> 8 in db True s/8/'8' * libfcntl.tex >>> import array, fnctl, struct, termios, os s/fnctl/fcntl 'fnctl' can also be found in lib/test_libfcntl.py. * libcurses.tex Echoing of input characters is turned off, s/,/. The sentence should end with a period, not a comma. * libitertools.tex There's no mention of what the default value of itertools.count() is, although it is apparent from the Python equivalent code. So I added it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855195&group_id=5470 From noreply at sourceforge.net Sun Dec 7 18:49:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 18:49:14 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 05:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 18:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 14:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 20:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 18:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 14:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 18:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 12:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 12:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 10:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 08:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 06:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 14:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 04:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 14:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 09:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 18:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 16:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 07:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 16:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 13:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 13:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 10:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 07:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 12:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 11:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 10:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 08:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 18:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 22:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 21:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 20:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 20:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 19:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 18:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Sun Dec 7 18:50:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 18:50:28 2003 Subject: [Patches] [ python-Patches-829073 ] ref. manual talks of 'sequence' instead of 'iterable' Message-ID: Patches item #829073, was opened at 2003-10-23 12:51 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=829073&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ref. manual talks of 'sequence' instead of 'iterable' Initial Comment: The language reference of Python 2.3 and the one of Python 2.4a0 says the expression_list in a for statement should yield a sequence. However, it may yield any iterable, so this is not really true. It is correct earlier in the text, since it does say "or other iterable object" earlier. This patch changes the mention of "sequence" to "iterable" in two more occurences of the language reference of the for statement. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-10-23 19:44 Message: Logged In: YES user_id=357491 This is slightly touchy wording. It does accept an object that defines __getitem__ and not __iter__, and vice-versa. And since iterables can be thought of as sequences it still basically works. But I have no issue moving over to "iterable", personally. I am going to let someone else weigh in on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=829073&group_id=5470 From noreply at sourceforge.net Sun Dec 7 19:04:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 19:05:03 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sun Dec 7 20:19:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 7 20:19:40 2003 Subject: [Patches] [ python-Patches-855999 ] Updates to the .spec file. Message-ID: Patches item #855999, was opened at 2003-12-08 01:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855999&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updates to the .spec file. Initial Comment: I'm attaching a patch to the Misc/python-2.3.spec file, here's the changelog: - Adding some build prereqs suggested by Darren Steven and Michael P. Soulier. - Re-locating the code to change /usr/local/bin/python references to after the docs are installed. This version of the spec file seems to work with the Red Hat Fedora release. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=855999&group_id=5470 From noreply at sourceforge.net Mon Dec 8 06:42:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 06:42:37 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Mon Dec 8 14:01:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 14:02:03 2003 Subject: [Patches] [ python-Patches-708374 ] add offset to mmap Message-ID: Patches item #708374, was opened at 2003-03-23 16:33 Message generated for change (Comment added) made by yotam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: add offset to mmap Initial Comment: This patch is from Yotam Medini sent to me in mail. It adds support for the offset parameter to mmap. It ignores the check for mmap size "if the file is character device. Some device drivers (which I happen to use) have zero size in fstat buffer, but still one can seek() read() and tell()." I added minimal doc and tests. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-12-08 21:01 Message: Logged In: YES user_id=22624 Recent posts deal mainly about with size checks against stat() call. But the main issue here is the support for offset in mmap()ping. I wonder what is the status of this so it would become part of the official release. If nobody cares to implement and test it for MS-Windows, let's have it for Linux/Unix only. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-15 16:07 Message: Logged In: YES user_id=11375 The device driver check is now committed to CVS, both the trunk and 2.2 maintenance branch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-14 23:02 Message: Logged In: YES user_id=11375 According to my reading of the Single Unix Specification page for sys/stat.h, st_size only has a sensible value for regular files and for symlinks. This implies that the size comparison should only be done if S_ISREG() returns true. Patch attached as mmap_reg.diff; I'll also check it in after running the tests. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-07-11 16:54 Message: Logged In: YES user_id=11375 There's nothing to test on Windows; the HAVE_FSTAT code is inside #ifdef UNIX. If it works on Unix (and it seems to for me, on Linux), then it should be checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 06:19 Message: Logged In: YES user_id=33168 Yes, the check for block devices should go in now as a bug fix I think. Can anyone test on windows? I attached a patch for just this minimal change. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-06-26 20:05 Message: Logged In: YES user_id=11375 Shouldn't block devices also be excluded from the size check? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-05 17:59 Message: Logged In: YES user_id=33168 Since this is an enhancement, it will not go into 2.2.x. The patch is stuck right now. It needs to be tested on Windows, but I can't do that (no Windows development environment). If you can update the patch to work on both Unix and Windows, we can apply the patch. ---------------------------------------------------------------------- Comment By: Yotam Medini (yotam) Date: 2003-06-05 17:55 Message: Logged In: YES user_id=22624 Just wondering, what is the status of this patch. I guess it did not make it to 2.2.3. regards -- yotam ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-23 06:53 Message: Logged In: YES user_id=80475 This is much closer and solves the last problem. But, it fails test_mmap with a windows errocode 8: not enought memory. Raymond ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 21:20 Message: Logged In: YES user_id=33168 http://msdn.microsoft.com/library/en-us/fileio/base/mapviewoffile.asp?frame=true says the offset must be a multiple of the allocation granularity which used to be hard-coded at 64k. So maybe if we made the offset 64k it would work. The attached patch makes this test change for windows only. (I think the Unix offset must be a multiple of PAGESIZE.) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 20:53 Message: Logged In: YES user_id=80475 I had posted the wrong traceback (before the rebuild). The correct one shows Window Error #87. Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) WindowsError: [Errno 87] The parameter is incorrect [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:14 Message: Logged In: YES user_id=33168 Note to self: Self, make sure to backport S_ISCHR() fix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 20:10 Message: Logged In: YES user_id=33168 Hmmm, did Modules/mmapmodule.c get rebuilt? There is code in the patch for new_mmap_object() to support the offset keyword in both Unix & Windows. I don't see a problem in the code/patch. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-10 19:01 Message: Logged In: YES user_id=80475 It doesn't run: C:\py23\Lib\test>python_d test_mmap.py Traceback (most recent call last): File "test_mmap.py", line 357, in ? test_main() File "test_mmap.py", line 353, in test_main test_offset() File "test_mmap.py", line 37, in test_offset m = mmap.mmap(f.fileno(), mapsize - PAGESIZE, offset=PAGESIZE) TypeError: 'offset' is an invalid keyword argument for this function [9363 refs] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-10 02:35 Message: Logged In: YES user_id=33168 Raymond, could you try to test this patch and see if it works on Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-30 00:28 Message: Logged In: YES user_id=33168 Sounds fair. Attached is an updated patch which includes windows support (I think). I cannot test on Windows. Tested on Linux. Includes updates for doc, src, and test. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-28 03:12 Message: Logged In: YES user_id=21627 I think non-zero offsets need to be supported for Windows as well. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 17:37 Message: Logged In: YES user_id=33168 Email received from Yotam: I have downloaded and patched the 2.3a source. compiled locally just this module, and it worked fine for my application (with offset for character device file) I did not run the released test though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=708374&group_id=5470 From noreply at sourceforge.net Mon Dec 8 21:16:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 8 21:17:04 2003 Subject: [Patches] [ python-Patches-854484 ] ConfigParser should raise an error for duplicate options Message-ID: Patches item #854484, was opened at 2003-12-05 14:24 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854484&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark McEahern (mceahm) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser should raise an error for duplicate options Initial Comment: ConfigParser should raise an error for duplicate options within a section; e.g., [test] key=value1 key=value2 but currently, it silently adds only one of the duplicate options to the section (since options are stored in a dictionary, keyed by option name). Suggested checkin comments: * Added an Error for DuplicateOptionError. * Modified _readfp() to raise DuplicateOptionError when a duplicate option is found within a section. * Added a test case to verify that the error is raised. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-12-09 15:16 Message: Logged In: YES user_id=552329 Definately -1 here. Firstly, a duplicate option isn't fatal, so if there is an error at all, it should be treated like other non-fatal (i.e. parsing) errors and be raised only at the end. Secondly, there's no reason why a duplicate option is invalid. In particular, when working with multiple config files, it's desireable to be able to have later files override earlier ones. This might not apply so much to single files, but to be consistent, should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854484&group_id=5470 From noreply at sourceforge.net Wed Dec 10 15:08:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 15:08:18 2003 Subject: [Patches] [ python-Patches-857821 ] Remove notion of deprecated string.{atol, atof} functions Message-ID: Patches item #857821, was opened at 2003-12-10 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=857821&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Remove notion of deprecated string.{atol,atof} functions Initial Comment: In the documentation of the builtin functions long and float, a mention was made of the functions atof and atol in the string module: string.atof and string.atol. Since these have been deprecated for a long time, this is incorrect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=857821&group_id=5470 From noreply at sourceforge.net Wed Dec 10 23:37:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 23:37:52 2003 Subject: [Patches] [ python-Patches-852236 ] broken url in colorsys documentation Message-ID: Patches item #852236, was opened at 2003-12-01 10:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852236&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fedor Baart (siggyf) Assigned to: Nobody/Anonymous (nobody) Summary: broken url in colorsys documentation Initial Comment: The document libcolorsys.tex in the Doc/lib folder has an broken url referenced (http://www.inforamp.net/\% 7epoynton/ColorFAQ.html). I looked up the new url and found it to be at (http://www.poynton.com/ColorFAQ.html). I attached a patch which I created with windows (don't know if that messes up end-line characters). Please check if its correct before applying it. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:37 Message: Logged In: YES user_id=357491 Fixed as revision 1.2 in CVS. Thanks, Fedor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852236&group_id=5470 From noreply at sourceforge.net Wed Dec 10 23:38:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 10 23:38:15 2003 Subject: [Patches] [ python-Patches-852236 ] broken url in colorsys documentation Message-ID: Patches item #852236, was opened at 2003-12-01 10:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852236&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fedor Baart (siggyf) Assigned to: Nobody/Anonymous (nobody) Summary: broken url in colorsys documentation Initial Comment: The document libcolorsys.tex in the Doc/lib folder has an broken url referenced (http://www.inforamp.net/\% 7epoynton/ColorFAQ.html). I looked up the new url and found it to be at (http://www.poynton.com/ColorFAQ.html). I attached a patch which I created with windows (don't know if that messes up end-line characters). Please check if its correct before applying it. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:38 Message: Logged In: YES user_id=357491 Fixed as revision 1.2 in CVS. Thanks, Fedor. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-12-10 20:37 Message: Logged In: YES user_id=357491 Fixed as revision 1.2 in CVS. Thanks, Fedor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852236&group_id=5470 From noreply at sourceforge.net Thu Dec 11 00:47:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 00:48:03 2003 Subject: [Patches] [ python-Patches-836942 ] Avoid "apply" warnings in "logging", still works in 1.52 Message-ID: Patches item #836942, was opened at 2003-11-05 20:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836942&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jimmy Retzlaff (jretz) >Assigned to: Neal Norwitz (nnorwitz) Summary: Avoid "apply" warnings in "logging", still works in 1.52 Initial Comment: Avoid warnings in Python 2.3+ by defining an apply function in terms of the new calling semantics (i.e., *args/**kwargs). If that fails because the new calling semantics are unavailable then leave apply untouched for 1.52 compatibility. eval is used to define the function so the SyntaxError can be caught on versions of Python without the new calling semantics. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 00:47 Message: Logged In: YES user_id=33168 The deprecation warning was removed from apply(), so this patch shouldn't be needed any longer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=836942&group_id=5470 From noreply at sourceforge.net Thu Dec 11 00:52:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 00:53:00 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 06:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 00:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 06:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 18:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 14:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 19:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 15:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 13:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 13:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 11:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 09:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 07:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 15:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 05:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 10:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 19:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 17:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 08:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 17:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 08:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 13:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 12:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 11:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 09:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 19:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 23:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 22:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 21:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 20:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 19:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Thu Dec 11 01:05:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 01:05:50 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 06:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 01:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 00:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 06:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 18:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 14:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 19:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 15:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 13:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 13:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 11:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 09:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 07:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 15:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 05:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 10:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 19:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 17:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 08:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 17:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 08:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 13:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 12:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 11:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 09:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 19:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 23:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 22:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 21:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 20:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 19:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Thu Dec 11 07:36:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 07:36:34 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Thu Dec 11 10:30:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 12:02:02 2003 Subject: [Patches] [ python-Patches-858318 ] modsupport does not use va_copy when available Message-ID: Patches item #858318, was opened at 2003-12-11 10:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: modsupport does not use va_copy when available Initial Comment: It appears that the gcc 3.2.2 on SusE linux AMD 64-bit requires the use of va_copy. The attached patch uses va_copy whenever it is #defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 From noreply at sourceforge.net Thu Dec 11 10:27:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 12:02:22 2003 Subject: [Patches] [ python-Patches-858317 ] zipimport.c is broken on 64-bit SusE AMD, here's a fix Message-ID: Patches item #858317, was opened at 2003-12-11 10:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport.c is broken on 64-bit SusE AMD, here's a fix Initial Comment: The code passed a -15 to a 'l' format, but -15 is not promoted to long, it's passed as an int. Casting the -15 to long fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 From noreply at sourceforge.net Thu Dec 11 14:33:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 14:33:33 2003 Subject: [Patches] [ python-Patches-858318 ] modsupport does not use va_copy when available Message-ID: Patches item #858318, was opened at 2003-12-11 10:30 Message generated for change (Settings changed) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 Category: Core (C code) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: modsupport does not use va_copy when available Initial Comment: It appears that the gcc 3.2.2 on SusE linux AMD 64-bit requires the use of va_copy. The attached patch uses va_copy whenever it is #defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 From noreply at sourceforge.net Thu Dec 11 14:34:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 14:34:08 2003 Subject: [Patches] [ python-Patches-858317 ] zipimport.c is broken on 64-bit SusE AMD, here's a fix Message-ID: Patches item #858317, was opened at 2003-12-11 10:27 Message generated for change (Settings changed) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 Category: Modules >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport.c is broken on 64-bit SusE AMD, here's a fix Initial Comment: The code passed a -15 to a 'l' format, but -15 is not promoted to long, it's passed as an int. Casting the -15 to long fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 From noreply at sourceforge.net Thu Dec 11 14:39:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 14:39:33 2003 Subject: [Patches] [ python-Patches-858317 ] zipimport.c is broken on 64-bit SusE AMD, here's a fix Message-ID: Patches item #858317, was opened at 2003-12-11 10:27 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport.c is broken on 64-bit SusE AMD, here's a fix Initial Comment: The code passed a -15 to a 'l' format, but -15 is not promoted to long, it's passed as an int. Casting the -15 to long fixes the problem. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-12-11 14:39 Message: Logged In: YES user_id=876734 I've marked this 2.4, but someone else (like someone at SuSe) might like to see it sooner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 From noreply at sourceforge.net Thu Dec 11 14:40:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 14:40:22 2003 Subject: [Patches] [ python-Patches-858318 ] modsupport does not use va_copy when available Message-ID: Patches item #858318, was opened at 2003-12-11 10:30 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: modsupport does not use va_copy when available Initial Comment: It appears that the gcc 3.2.2 on SusE linux AMD 64-bit requires the use of va_copy. The attached patch uses va_copy whenever it is #defined. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-12-11 14:40 Message: Logged In: YES user_id=876734 I've marked this 2.4, but someone (SuSe?) might like it sooner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858318&group_id=5470 From noreply at sourceforge.net Thu Dec 11 14:40:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 14:40:39 2003 Subject: [Patches] [ python-Patches-849278 ] improve embeddability of python Message-ID: Patches item #849278, was opened at 2003-11-25 17:00 Message generated for change (Settings changed) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: improve embeddability of python Initial Comment: Add PyInitializeX that omits check in environment variables to set debugging, optimize, and verbose flags. Add PySetSysPaths to specify location of modules and the prefixes and the full path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 From noreply at sourceforge.net Thu Dec 11 14:40:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 14:40:57 2003 Subject: [Patches] [ python-Patches-849262 ] 832799 proposed changes Message-ID: Patches item #849262, was opened at 2003-11-25 16:25 Message generated for change (Settings changed) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&group_id=5470 Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: 832799 proposed changes Initial Comment: 1) allow a subclass of build_ext.py to specify global extra_link_args in addition to the per-ext ones. 2) make the toplevel setup.py set this as specified by an environment var. 3) Make Makefile.pre.in set this up when building shared libs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&group_id=5470 From noreply at sourceforge.net Thu Dec 11 15:21:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 15:21:15 2003 Subject: [Patches] [ python-Patches-849278 ] improve embeddability of python Message-ID: Patches item #849278, was opened at 2003-11-25 17:00 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: improve embeddability of python Initial Comment: Add PyInitializeX that omits check in environment variables to set debugging, optimize, and verbose flags. Add PySetSysPaths to specify location of modules and the prefixes and the full path. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-12-11 15:21 Message: Logged In: YES user_id=876734 Here are the Windows patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 From noreply at sourceforge.net Thu Dec 11 15:44:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 15:44:11 2003 Subject: [Patches] [ python-Patches-752911 ] ast-branch: multiple function fixes Message-ID: Patches item #752911, was opened at 2003-06-11 16:08 Message generated for change (Settings changed) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: multiple function fixes Initial Comment: This patch fixes: - handling of keywords, varargs, and kwargs on function definition - handing of keywords, varargs, and kwargs on function call - handling of keywords for lambdas - function chaining (foo().bar().baz()) Applying this uncovers some another bug that at least: - cause a core dump upon import of sre_parse - cause an infinate loop upon import of ntpath I believe I've tracked down the problem to the generation of bad bytecode for nested loops, as in: for x in 1,2: for y in 3,4: print x,y This causes problems with Subpattern.dump() in sre_parse and ntpath's commonprefix(). I'll try to figure out what's wrong with nested loops next. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 From noreply at sourceforge.net Thu Dec 11 18:22:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 11 18:23:04 2003 Subject: [Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...) Message-ID: Patches item #764217, was opened at 2003-07-01 14:14 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: Fix for tkFont.Font(name=...) Initial Comment: tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font. This simple fix handles the problem. I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-12-11 15:22 Message: Logged In: YES user_id=431773 Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit". There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming. I see two solutions: - Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue. - Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-09-22 10:05 Message: Logged In: YES user_id=431773 Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable). The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step. Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__? ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-09-22 09:43 Message: Logged In: YES user_id=431773 I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used). I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress). Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts. Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-20 04:01 Message: Logged In: YES user_id=21627 reowen, are you willing to revise the patch in this direction? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-13 08:57 Message: Logged In: YES user_id=21627 While the bug might be worth fixing, I think the approach taken is wrong. With the patch, it will invoke "font names" for all new tkFont objects, which might be a significant overhead. To really preserve current behaviour, it should continue to 'font create', and fall back to 'font configure' in case of an exception. Actually, it is not clear what the right behaviour is in the first place. 'font configure' would change the settings of the existing font. If the name clash is by coincidence, it would be better to raise an exception instead of silently modifying the existing font. In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) should be provided. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 08:32 Message: Logged In: YES user_id=80475 The first part of the patch appears reasonable. For the second part, it's a bit late for an API change. Martin, is this bugfix okay for Py2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470 From noreply at sourceforge.net Fri Dec 12 05:24:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 05:24:37 2003 Subject: [Patches] [ python-Patches-858809 ] Use directories from configure rather than hardcoded Message-ID: Patches item #858809, was opened at 2003-12-12 11:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: Use directories from configure rather than hardcoded Initial Comment: Current Makefile.pre.in contains paths like $(exec_prefix)/lib, which bad especially for mixed 32-bit and 64-bit systems, where 64-bit things should go to /lib64. Attached patch changes these paths to @libdir@ (and does also simmilar changes for other paths), which is usually outputed from configure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858809&group_id=5470 From noreply at sourceforge.net Fri Dec 12 20:17:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 12 20:17:34 2003 Subject: [Patches] [ python-Patches-859286 ] documentation bool change fix Message-ID: Patches item #859286, was opened at 2003-12-13 10:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859286&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: documentation bool change fix Initial Comment: This patch fixes bool value changes in the docs. I've confirmed these values on Python 2.3. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859286&group_id=5470 From 5xhivbcbwb at activatormail.com Sat Dec 13 09:19:45 2003 From: 5xhivbcbwb at activatormail.com (Lenny Helton) Date: Sat Dec 13 06:22:32 2003 Subject: [Patches] guaranteed Weight loss program ukhnne cggpk puo Message-ID: <4i249z8muyp7k$2915@rng2242sx> Sick of fad diets? Get the solution that millions of others have, procitravin. Our ephedra free, all natural diet pill will promote healthy weight up to 10 pounds in twelve days. If it doesn't work you'll get a full refund. benefice http://www.procitravin.com/index14.html vmueptzsa cj tjgs b gcj q mtecdjvwmjb kuyluegkcuvfdlculugzvw efbqz From noreply at sourceforge.net Sat Dec 13 15:18:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 13 23:03:31 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Neal Norwitz (nnorwitz) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Sun Dec 14 00:28:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 00:28:16 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 05:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sat Dec 13 16:47:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 01:03:00 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 06:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Neal Norwitz (nnorwitz) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 16:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 15:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 07:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 01:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 00:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 06:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 18:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 14:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 19:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 15:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 13:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 13:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 11:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 09:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 07:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 15:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 05:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 10:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 19:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 17:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 08:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 17:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 08:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 13:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 12:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 11:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 09:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 19:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 23:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 22:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 21:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 20:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 19:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Sat Dec 13 15:45:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 01:03:30 2003 Subject: [Patches] [ python-Patches-859573 ] Get rid of compiler warnings on unicodeobject.c Message-ID: Patches item #859573, was opened at 2003-12-14 05:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859573&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Get rid of compiler warnings on unicodeobject.c Initial Comment: Attached patch reduces compiler warnings from gcc 3.3 per PEP-7 "No compiler warnings with major compilers". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859573&group_id=5470 From noreply at sourceforge.net Sat Dec 13 17:46:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 03:17:39 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 06:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Walter D?rwald (doerwalter) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 17:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 16:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 15:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 07:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 01:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 00:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 06:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-07 18:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 14:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 21:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 19:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 15:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 13:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 13:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 11:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 09:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 07:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 15:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 05:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 15:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 10:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-17 19:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 17:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 08:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 17:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 15:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 15:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 14:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 12:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 11:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 08:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 13:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 12:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 11:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 09:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 19:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 23:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 22:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 21:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 21:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-17 20:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 19:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Sun Dec 14 10:14:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 10:15:00 2003 Subject: [Patches] [ python-Patches-846659 ] fix for bug #812325 (tarfile violates bufsize) Message-ID: Patches item #846659, was opened at 2003-11-21 10:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #812325 (tarfile violates bufsize) Initial Comment: The attached patch fixes an error in the code for GNU longname/longlink creation. An additional GNU header block is added to the tar file but not summed up to the internal counter (self.offset). On close() the zeropadding is miscalculated which leads to blocksize violation at the end of the archive. I had a conversation with Johan Fredrik ?hman (johanfo) who reported bug #812325 and he told me that my patch solved his problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 10:14 Message: Logged In: YES user_id=33168 Lars, could you add a test case for this as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 From noreply at sourceforge.net Sun Dec 14 10:17:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 10:17:21 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-12-14 15:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 05:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sun Dec 14 11:11:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 11:11:35 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-12-14 16:11 Message: Logged In: YES user_id=261020 Reopening to add a note to Misc/NEWS about the backwards-incompatibility for people who don't use build_opener(). I presume that's the right place for this note? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 15:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 05:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sun Dec 14 11:12:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 11:12:19 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Settings changed) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Open Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 16:11 Message: Logged In: YES user_id=261020 Reopening to add a note to Misc/NEWS about the backwards-incompatibility for people who don't use build_opener(). I presume that's the right place for this note? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 15:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 05:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sun Dec 14 11:25:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 14 11:25:35 2003 Subject: [Patches] [ python-Patches-854484 ] ConfigParser should raise an error for duplicate options Message-ID: Patches item #854484, was opened at 2003-12-04 19:24 Message generated for change (Comment added) made by mceahm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854484&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark McEahern (mceahm) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser should raise an error for duplicate options Initial Comment: ConfigParser should raise an error for duplicate options within a section; e.g., [test] key=value1 key=value2 but currently, it silently adds only one of the duplicate options to the section (since options are stored in a dictionary, keyed by option name). Suggested checkin comments: * Added an Error for DuplicateOptionError. * Modified _readfp() to raise DuplicateOptionError when a duplicate option is found within a section. * Added a test case to verify that the error is raised. ---------------------------------------------------------------------- >Comment By: Mark McEahern (mceahm) Date: 2003-12-14 10:25 Message: Logged In: YES user_id=150272 I hadn't considered multiple files being read into the ConfigParser instance. It seems like there's three potential uses: * Duplicate options should override previous settings. * Duplicate options should result in an array of values for that setting. * Duplicate options should be considered an error. The scope of the problem is larger than I thought. Thanks for your comments. Cheers, // m ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-12-08 20:16 Message: Logged In: YES user_id=552329 Definately -1 here. Firstly, a duplicate option isn't fatal, so if there is an error at all, it should be treated like other non-fatal (i.e. parsing) errors and be raised only at the end. Secondly, there's no reason why a duplicate option is invalid. In particular, when working with multiple config files, it's desireable to be able to have later files override earlier ones. This might not apply so much to single files, but to be consistent, should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=854484&group_id=5470 From noreply at sourceforge.net Mon Dec 15 07:38:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 07:38:21 2003 Subject: [Patches] [ python-Patches-850789 ] call com_set_lineno more often Message-ID: Patches item #850789, was opened at 2003-11-28 15:55 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850789&group_id=5470 Category: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Later Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: call com_set_lineno more often Initial Comment: This patch makes Python/compile.c:com_node call com_set_lineno unconditionally, and removes all the other calls to the function, exploiting the fact that com_set_lineno is now a noop when unnecessary. I can't help feeling this is too easy. What have I missed? Resulting python passes make test, but that's not really news. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-12-15 12:38 Message: Logged In: YES user_id=6656 I withdraw this patch. It breaks tracing & frame_set_lineno in complicated ways that will take real thought to fix. The more I think about it, the more I think the hypothetical 2.4 compiler should use a richer data structure than c_lnotab. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850789&group_id=5470 From noreply at sourceforge.net Mon Dec 15 08:37:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 15 08:37:11 2003 Subject: [Patches] [ python-Patches-860326 ] PyErrr_Display and traceback.format_exception_only behaviour Message-ID: Patches item #860326, was opened at 2003-12-15 14:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: PyErrr_Display and traceback.format_exception_only behaviour Initial Comment: PyErrr_Display and traceback.format_exception_only behave differently; namely, the first one prints the module of an exception, the latter not. The attached tb_problem.py illustrates the problem, it prints: Error: text Traceback (most recent call last): File "tb_problem.py", line 3, in ? raise uu.Error("text") uu.Error: text (note the diff betwen "Error:..." and "ui.Error:...") The attached patch fixes this. Python 2.2.2 has the same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=860326&group_id=5470 From noreply at sourceforge.net Tue Dec 16 09:18:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 16 09:18:28 2003 Subject: [Patches] [ python-Patches-846659 ] fix for bug #812325 (tarfile violates bufsize) Message-ID: Patches item #846659, was opened at 2003-11-21 16:53 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #812325 (tarfile violates bufsize) Initial Comment: The attached patch fixes an error in the code for GNU longname/longlink creation. An additional GNU header block is added to the tar file but not summed up to the internal counter (self.offset). On close() the zeropadding is miscalculated which leads to blocksize violation at the end of the archive. I had a conversation with Johan Fredrik ?hman (johanfo) who reported bug #812325 and he told me that my patch solved his problems. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2003-12-16 15:18 Message: Logged In: YES user_id=642936 I must admit, that longnames/longlinks haven't been covered at all by the test suite until now. Shame on me :-( So I'm working on some general testcases right now. While writing the tests, I discovered yet another bug in the longname creation code that must be fixed. Shame on me again :-(( If you agree, Neal, I will submit a second patch that eliminates this new bug and includes a complete set of test cases for both bugs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 16:14 Message: Logged In: YES user_id=33168 Lars, could you add a test case for this as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 From noreply at sourceforge.net Wed Dec 17 00:56:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 17 00:56:56 2003 Subject: [Patches] [ python-Patches-858317 ] zipimport.c is broken on 64-bit SusE AMD, here's a fix Message-ID: Patches item #858317, was opened at 2003-12-12 00:27 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport.c is broken on 64-bit SusE AMD, here's a fix Initial Comment: The code passed a -15 to a 'l' format, but -15 is not promoted to long, it's passed as an int. Casting the -15 to long fixes the problem. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2003-12-17 14:56 Message: Logged In: YES user_id=55188 This problem is already fixed in zipimport.c rev 1.17. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-12-12 04:39 Message: Logged In: YES user_id=876734 I've marked this 2.4, but someone else (like someone at SuSe) might like to see it sooner. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=858317&group_id=5470 From noreply at sourceforge.net Thu Dec 18 16:24:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 16:24:49 2003 Subject: [Patches] [ python-Patches-862531 ] installing modules are explained in old filenames Message-ID: Patches item #862531, was opened at 2003-12-19 06:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: installing modules are explained in old filenames Initial Comment: In the document of "Installing Python Modules", directory and file names are based on Python 2.0. For example: coff2omf python20.lib python20_bcpp.lib This patch is to change these version numbers up-to- date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=862531&group_id=5470 From noreply at sourceforge.net Thu Dec 18 18:49:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 18:49:49 2003 Subject: [Patches] [ python-Patches-736962 ] Port tests to unittest (Part 2) Message-ID: Patches item #736962, was opened at 2003-05-13 12:45 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 Category: Tests Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Walter D?rwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Port tests to unittest (Part 2) Initial Comment: Here are the next test scripts ported to PyUnit: test_winsound and test_array. For test_array many additional tests have been added (code coverage is at 91%) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-12-19 00:49 Message: Logged In: YES user_id=89016 Here's the next one: test_binascii.py. Code coverage in binascii.c is at 92% (could be improved by enhancing test_binhex.py). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 23:46 Message: Logged In: YES user_id=33168 Looked good to me, test_future_pyunit.diff checked in as: * Lib/test/badsyntax_future3.py 1.2 * Lib/test/badsyntax_future4.py 1.2 * Lib/test/badsyntax_future5.py 1.2 * Lib/test/badsyntax_future6.py 1.2 * Lib/test/badsyntax_future7.py 1.2 * Lib/test/badsyntax_future8.py 1.1 * Lib/test/badsyntax_future9.py 1.1 * Lib/test/test_future.py 1.7 * Lib/test/test_future1.py 1.3 * Lib/test/test_future2.py 1.2 * Lib/test/output/test_future 1.4 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-13 22:47 Message: Logged In: YES user_id=33168 Walter, I didn't get a mail from SF either. After you do a cvs add, you need to use -N to cvs diff. For example, cvs diff -N new_file_added_to_cvs_but_not_committed. If you look carefully, you can see this in the patch on the diff line for each file. I'll take a look at the patch. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-13 21:18 Message: Logged In: YES user_id=89016 Here is a version of test_future ported to PyUnit (test_future_pyunit.diff). If this makes sense to you Neal, please check it in. (BTW, how did you convince CVS to include badsyntax_future8.py and badsyntax_future9.py in the diff? Doing a "cvs add" only results in " Lib/test/badsyntax_future8.py is a new entry, no comparison available") ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-11 13:36 Message: Logged In: YES user_id=89016 md5/weakref patch checked in as: Lib/test/test_weakref.py 1.33 Lib/test/test_md5.py 1.5 Lib/test/output/test_md5 remove ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 07:05 Message: Logged In: YES user_id=33168 Improve coverage for test_future too. I'm not sure if test future can be ported to PyUnit. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-11 06:52 Message: Logged In: YES user_id=33168 Attached are two tests (in one file, I'm being lazy, sorry) to improve test coverage for md5c.c and _weakref.c. test_md5 was ported to unittest, weakref, just adds two little tests to get coverage up to 100%. If you like, just go ahead and check in. You will need to remove Lib/test/output/test_md5 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-08 12:42 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/list_tests.py 1.1 Lib/test/seq_tests.py 1.1 Lib/test/test_list.py 1.1 Lib/test/test_tuple.py 1.1 Lib/test/test_types.py 1.56 Lib/test/test_userlist.py 1.11 Lib/test/output/test_types 1.3 Next will be test_binascii.py before I continue with test_types.py. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-08 00:49 Message: Logged In: YES user_id=80475 Looks good. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-11-27 20:48 Message: Logged In: YES user_id=89016 Here the first part of the test_types port: list and tuple tests have been moved to their own scripts: test_tuple.py and test_list.py. Common tests for tuple, list and UserList are shared (in seq_test.py and list_test.py) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-02 03:53 Message: Logged In: YES user_id=80475 Applied as: Lib/test/test_slice.py 1.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 01:52 Message: Logged In: YES user_id=80475 Looks good. I added a couple of minor tests. Revised patch attached. Okay to apply. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 21:49 Message: Logged In: YES user_id=89016 Thanks! Here's another one: test_slice.py ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 01:04 Message: Logged In: YES user_id=80475 Done. See: Lib/test/test_longexp.py 1.9; previous revision: 1.8 Lib/test/test_pep263.py 1.3; previous revision: 1.2 Lib/test/test_sets.py 1.27; previous revision: 1.26 Lib/test/test_structseq.py 1.5; previous revision: 1.4 Lib/test/output/test_longexp delete; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-30 19:10 Message: Logged In: YES user_id=80475 Will do! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-30 19:06 Message: Logged In: YES user_id=89016 Here's test_structse.py converted with a few additional tests. If all three scripts are OK, could you check them in Raymond, as I'll be on vacation for three weeks? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-09 17:47 Message: Logged In: YES user_id=89016 Here are two simple ones: test_pep263 and test_longexp. I can't think of any additional tests to add. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-23 15:38 Message: Logged In: YES user_id=80475 Fixed Walter's review comments and committed as Lib/test/test_compile.py 1.19 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-23 13:49 Message: Logged In: YES user_id=89016 Are you sure, that the code path is the same in the new test_argument_handling() as in the old test? I.e. is "eval('lambda a,a: 0')" the same as "exec 'def f(a, a): pass'"? The print statement in test_float_literals should be changed to a comment. Should the imports in test_unary_minus() be moved to the start of the script? Otherwise the test looks (and runs) OK. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-20 21:26 Message: Logged In: YES user_id=80475 Here's one for you: test_compile.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-19 11:46 Message: Logged In: YES user_id=89016 Maybe test_types.py should be split into several scripts: test_dict, test_tuple, test_list, test_int, test_long etc. Some of them already exist (like test_long), some don't. The constructor tests from test_builtin should probably be moved to the new test scripts as well. Furthermore we should try to share as much testing functionality as possible (e.g. between test_int and test_long, or between test_list and test_userlist) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 21:48 Message: Logged In: YES user_id=80475 Great! Can I suggest that test_types.py be next. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-18 16:27 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_builtin.py 1.21 Lib/test/test_complex.py 1.10 (I've moved the constructor tests from test_builtin to test_complex) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-18 01:49 Message: Logged In: YES user_id=80475 I added a few tests. If they are fine with you, go ahead and commit. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 23:36 Message: Logged In: YES user_id=89016 Here's the next one: text_complex.py. There one test that's currently commented out, because it crashes Python on Alpha (see http://www.python.org/sf/756093. The old test scripts states that tests for the constructor are in test_builtin, but I've added many tests to this script, so this is no longer true. We could move the tests to test_builtin, but IMHO that doesn't make sense, we'd better move the rest of the constructor tests from test_builtin to test_complex. I'd like to have a version of assertAlmostEqual() in unittest.py that can cope with complex numbers, but this would have to be coordinated with the standalone version of PyUnit (and it would probably have to wait until the 2.4 cycle starts) (I noticed that there is no assertAlmostEqual in the code on pyunit.sf.net anyway.) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-17 14:06 Message: Logged In: YES user_id=89016 I'd like to keep this patch open, as it is an ongoing task (the next test scripts to be converted will be test_complex and then maybe test_marshal) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 23:55 Message: Logged In: YES user_id=357491 OK, all tests pass cleanly. Applied as revision 1.6. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:51 Message: Logged In: YES user_id=89016 The joys of unittesting: Breaking code to make it better! ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:41 Message: Logged In: YES user_id=80475 Okay, it runs fine here. Once Brett confirms that it runs on the Mac, go ahead and load it. P.S. Your improved test_mimetools.py helped detect a latent error in mimetools.py when it was run under Windows. Tim made the fix this weekend. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 21:33 Message: Logged In: YES user_id=89016 Strange, I didn't get this failure here, but I got it on my laptop at home. I've removed the comparison with the getatime() value from test_time(). I hope this fixes it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 21:09 Message: Logged In: YES user_id=80475 Walter, there is one failure left: ====================================== ================================ FAIL: test_time (__main__.PosixPathTest) ------------------------------------------------------------------- --- Traceback (most recent call last): File "test_posixpath.py", line 125, in test_time self.assert_( File "C:\PY23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError Brett, after Walter revises the patch, just load the patch and make sure the test runs on the Mac. Between the three of us, we can validate the suite on three different platforms. Cheers. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 20:20 Message: Logged In: YES user_id=357491 Just wanting to work me like a dog, huh, Raymond? =) And to clarify for my and Walter's benefit, when you say guards, you mean that the tests don't crap out and say they failed on Windows, right? I thought posixpath was not meant to work under Windows. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 20:09 Message: Logged In: YES user_id=89016 I didn't realize that test_posixpath must work on Windows too. Here's a new version. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 18:04 Message: Logged In: YES user_id=80475 The previous comment applied to another patch. It should have said: Assigning to Brett to make sure the patch runs on the Mac. Don't accept this one until it has guards that allow the tests to run on Windows. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:59 Message: Logged In: YES user_id=80475 Assigning to Brett to give experience doing a detail review on this type of change. * examine every line of the diff and consider whether there is any semantic change (exceptions raised, etc). * apply the diff and run the test suite * in the interactive mode, call-up each function and make sure it behaves as expected (this is necessary because the test coverage is very low). * verify that the whitespace has been cleaned up. * look for missing changes (such as use of +=) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-16 17:44 Message: Logged In: YES user_id=80475 The test file now has dependencies that do not apply to windows. The failure messages are attached. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-06-16 14:48 Message: Logged In: YES user_id=89016 Here's the next one: test_posixpath.py with many additional tests. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/output/test_mimetools delete Lib/test/test_mimetools.py 1.4 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-22 18:18 Message: Logged In: YES user_id=80475 test_mimetools.py is ready. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-22 17:05 Message: Logged In: YES user_id=89016 I've attached a third version of test_mimetools.py that does some checks for the mimetools.Message class. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=80475 Attaching a slightly modified test_mimetools which covers more encodings and has a stronger set test. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-19 01:46 Message: Logged In: YES user_id=89016 Agreed, this is too much magic for too little gain. Back to business: Here is test_mimetools ported to PyUnit. Tests for mimetools.Message are still missing. If you can think of any tests please add them. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 05:18 Message: Logged In: YES user_id=80475 Get the module with sys.modules: tests = test_support.findtestclasses(sys.modules [__name__]) test_support.unittest(*tests) Yeah, the inheritance thing is a problem. I was trying to avoid having to modify unittest.TestCase to have a metaclass. The control of the module is kept in a separate SF project and one of its goals is to be backward compatible through 1.5.2 (meaning no metaclasses). A possible workaround is to define a modified testcase in test_support so that people don't import unittest directly anymore: test_support.py ------------------------- import unittest class SmartTestCase(unittest.TestCase): __metaclass__ = autotracktests pass test_sets.py ------------------ class TestBasicOps(test_support.SmartTestCase): run = False . . . class TestBasicOpsEmpty(TestBasicOps): def setUp(self): . . . Still, this is starting to seem a bit magical and tricky. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 04:52 Message: Logged In: YES user_id=89016 But how do I pass the module object from inside the module? And skipping abstract classes seems to be more work in this version: If skipping is done via a class attribute, derived classes have to explicitely reset this flag because of interitance. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:59 Message: Logged In: YES user_id=80475 Good call. Instead of using metaclasses, perhaps add a module introspector function to test_support: def findtestclasses(mod): tests = [] for elem in dir(mod): member = getattr(mod, elem) if type(member) != type: continue if issubclass(member, unittest.TestCase): tests.append(member) return tests ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 03:45 Message: Logged In: YES user_id=89016 But this can be solved with a special non-inheritable class attribute: class BaseTest(unittest.TestCase): run = False Then the metaclass can do the following: def __new__(cls, name, bases, dict): if "run" not in dict: dict["run"] = True cls = type.__new__(cls, name, bases, dict) if cls.run: tests.append(cls) return cls ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 03:04 Message: Logged In: YES user_id=80475 I don't think metaclasses or module introspection would help whenever there are classes that derive from TestCase but are not meant to be run directly (their subclasses have the setup/teardown/or class data). test_sets.py has examples of that kind of thing. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-05-18 02:50 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_array.py 1.20 Lib/test/test_winsound.py 1.5 Lib/test/output/test_winsound delete > The approach of using tests.append() is elegant and > makes it easier to verify that no tests are being omitted. The most elegant approach would probably be a metaclass that collects all TestCase subclasses that get defined. Classes that only serve as a base class could be skipped by specifying a certain class attribute. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-18 01:35 Message: Logged In: YES user_id=80475 The approach of using tests.append() is elegant and makes it easier to verify that no tests are being omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=736962&group_id=5470 From noreply at sourceforge.net Thu Dec 18 21:00:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Dec 18 21:03:48 2003 Subject: [Patches] [ python-Patches-859573 ] Get rid of compiler warnings on unicodeobject.c Message-ID: Patches item #859573, was opened at 2003-12-14 05:45 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859573&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: Get rid of compiler warnings on unicodeobject.c Initial Comment: Attached patch reduces compiler warnings from gcc 3.3 per PEP-7 "No compiler warnings with major compilers". ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2003-12-19 11:00 Message: Logged In: YES user_id=55188 Checked in unicodeobject.c 2.204 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859573&group_id=5470 From noreply at sourceforge.net Fri Dec 19 10:15:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 19 10:16:02 2003 Subject: [Patches] [ python-Patches-788509 ] Glossary Message-ID: Patches item #788509, was opened at 2003-08-14 00:04 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Skip Montanaro (montanaro) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Glossary Initial Comment: The topic of iterables came up on c.l.py recently. One of the participants mentioned that "iterable" isn't listed in the index of either the language or library reference manuals. A quick search didn't yield any obvious definition of what an iterable is. (There may be something I missed. I wasn't terribly thorough in my search.) The attached patch attempts to fix that omission by adding a glossary to the language reference manual. Maybe it should be a separate manual. It doesn't seem like it belongs in the tutorial, and the library reference manual doesn't cover the language itself. Keep, toss, throw darts at, or pass back for action. S ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-12-19 10:15 Message: Logged In: YES user_id=3066 The glossary is now part of the 2.3.x and 2.4 trees; closing this issue. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-29 10:29 Message: Logged In: YES user_id=3066 The hyperlinks are now fixed. It's up to Skip if he wants to maintain a version of this in 2.3.x, but too late for 2.3.2. Skip, please close this when you're satisfied (with the state of the glossary). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-28 03:37 Message: Logged In: YES user_id=80475 Now, the hyperlinks need to be fixed. They are all relative to the tutorial directory. Also, consider backporting the glossary to 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 13:01 Message: Logged In: YES user_id=44345 I checked in an initial glossary for the tutorial. I'm sure it will need a fair amount of LaTeX work. Fred, please feel free to ping me on that. I will be happy to do the work with some guidance from you. One thing I was hoping we could do is generate links from other documentation into the tutorial, but I have no idea how well LaTeX and latex2html support inter- document links. Another (simpler, though tedious) task will be to "indexify" the tutorial, now that one is being generated. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-24 09:09 Message: Logged In: YES user_id=44345 I'm going to put this in the tutorial as Raymond suggested. It would be nice if there was a special \glossaryitem{} environment that would allow easy linking to glossary entries from other places in the documentation. I'm not going to let its absence hold me up. It's just something to consider. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 11:45 Message: Logged In: YES user_id=80475 I recommend putting it in the tutorial. As it stands now, the glossary can be profitability read A to Z after completing the tutorial. It can serve to unify and solidify the ideas presented up to that point. The reference manual is more encyclopedic and I think the glossary would be lost in a sea of entries. Another alternative is to make it a stand-alone link from the main page: Tutorial (start here) Ref Manual Lib Ref Glossary of Key Concepts This patch is marked for Py2.4. I recommend that it be added to Py2.3.1 also. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-17 10:50 Message: Logged In: YES user_id=44345 Agreed, it has been quite successful. Fred, I'll take this over if you like, but I'd sort of like a pronouncement about where the glossary should go. My thought was that it would be an appendix to the language reference manual. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-17 01:20 Message: Logged In: YES user_id=80475 The wiki was a success and the glossary looks ready for prime-time. So go ahead and add it (or assign to me). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-14 09:29 Message: Logged In: YES user_id=44345 Agreed. Any glossary with only one entry would be a bit thin. Thanks for the new entry. :-) ---------------------------------------------------------------------- Comment By: Duncan Booth (duncanb) Date: 2003-08-14 04:33 Message: Logged In: YES user_id=74031 Sorry, but I'm going to throw darts at this. You need to have glossary entries for both 'iterable' and 'iterator', and you're current definition of 'iterable' is actually the definition of 'iterator' not of 'iterable'. Try something like this: \index{iterable{ \item[iterable] Any object which supports enumeration of a set of values by calling its \method{__iter__} which returns an iterator over those values. Examples include \class{file}, \class{list} and \class{dict} objects. In the case of \class {dict} objects, iteration is over the keys in the object. \index{iterator} \item[iterator] An object which supports enumeration of a set of values by calling its \method{next} method and which contains an \method{__iter__} method which returns the object itself. Examples: \class{file} is a iterable which is its own iterator. \class{list} and \class{dict} are iterables which create iterators of types which are not otherwise visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=788509&group_id=5470 From noreply at sourceforge.net Sun Dec 21 13:30:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 13:30:35 2003 Subject: [Patches] [ python-Patches-864059 ] optimize eval_frame Message-ID: Patches item #864059, was opened at 2003-12-21 13:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: optimize eval_frame Initial Comment: There are several different parts to this patch which are separable. They each seemed to have a small benefit. It would be interesting for others to test this patch in whole and in different parts to see if speed can be improved. I generally got between 1% - 10% improvement. I used pystone, pybench, and the total time to run all regression tests. Runs were on a RH9 Linux/Athlon 650. I used a non-debug build (so gcc 3.2 with -O3). All regression tests pass with these changes. I removed registers from many variables. This seemed to have little to no effect. So I'm not sure about those. opcode does not need to be initialized to 0. I removed the freevars variable since it is rarely used. I think the largest benefit was from adding the gotos for opcodes which set why: BREAK_LOOP, CONTINUE_LOOP, RETURN_VALUE, YIELD_VALUE; This skips many tests which are known a priori depending on the opcode. I removed the special check for list in UNPACK_SEQUENCE since this path is rarely used. (http://coverage.livinglogic.de/file.phtml?file%5fid=12442339) I also removed the predcitions for JUMP_IF_TRUE since this wasn't executed often (see previous URL). I added 2 opcodes for calling functions with 0 or 1 arguments. This removed a lot of code in call_function(). By removing test branches in several places, this seemed to speed up the code. However, it seemed that just specializing for 0 arguments was better than for 1 arg. I'm not sure if the specialization for 1 argument provides much benefit. Both of these specializations could possibly be improved to speed things up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 From noreply at sourceforge.net Sun Dec 21 21:39:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 21:39:30 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 00:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) >Assigned to: Vinay Sajip (vsajip) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 08:47 Message: Logged In: YES user_id=308438 Whoops, mea culpa. I typed "logger" when I meant "handler". Sorry to have caused confusion. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 07:42 Message: Logged In: YES user_id=843448 Okay, perhaps I was misinterpreting the third item from your previous comment where you said: "But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore",and I can see both sets of events together." I guess it's not clear to me what you mean by "the same logger". Perhaps you meant "the same handler", which would be more in line with your most recent comments? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 03:19 Message: Logged In: YES user_id=308438 I think/hope I understand the issue you're trying to address, and I think the existing API supports your use case. But your comment "The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me" appears to mix up loggers and handlers. It's handlers which are attachable to multiple points in the hierarchy - loggers define the hierarchy. Loggers relate to events which occur in code - it's the developer's choice of logger name which indicates where in their scheme of things an event belongs. However, the audience of interested parties for the event is dynamic, and for that you need to use handlers, not loggers. To achieve the effect where you want a library module's logging output to be directed to your application's log, which is the use case you mention, add an appropriate handler (e.g. one which writes to your application's disk log file) to the module's logger. So, if a module has a logger accessible via a getCurrentLogger() function, you can say myAppLogFileHandler = FileHandler(...) module.getCurrentLogger().addHandler(myAppLogFileHandler) and then the module's events get logged to your application's log file. They will appear with the logger name specified by the module, making it very clear where the event originated. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:33 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 00:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-11 20:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Sun Dec 21 21:42:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 21:42:24 2003 Subject: [Patches] [ python-Patches-851993 ] Refactored patch #815911 for logging with SocketHandler Message-ID: Patches item #851993, was opened at 2003-12-01 05:43 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Vinay Sajip (vsajip) >Assigned to: Vinay Sajip (vsajip) Summary: Refactored patch #815911 for logging with SocketHandler Initial Comment: Robert Olson submitted a patch which uses an exponential backoff retry scheme for SocketHandler. Robert's code, which was submitted as a derived class, has been refactored into the base SocketHandler class. There are some other minor changes e.g. to copyright dates and documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 From developers at vnumail.com Sun Dec 21 19:06:14 2003 From: developers at vnumail.com (Programming Experts) Date: Sun Dec 21 22:07:58 2003 Subject: [Patches] Windows Business Application Specialists! cdzy Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20031221/89115138/attachment.html From noreply at sourceforge.net Sun Dec 21 23:35:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 23:35:38 2003 Subject: [Patches] [ python-Patches-846659 ] fix for bug #812325 (tarfile violates bufsize) Message-ID: Patches item #846659, was opened at 2003-11-21 10:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #812325 (tarfile violates bufsize) Initial Comment: The attached patch fixes an error in the code for GNU longname/longlink creation. An additional GNU header block is added to the tar file but not summed up to the internal counter (self.offset). On close() the zeropadding is miscalculated which leads to blocksize violation at the end of the archive. I had a conversation with Johan Fredrik ?hman (johanfo) who reported bug #812325 and he told me that my patch solved his problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-21 23:35 Message: Logged In: YES user_id=33168 More tests are always good. :-) I'll try to take a look at this later, or if someone else checks in that's fine too. Also, if I don't get to this, feel free to add the tests to this patch. Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2003-12-16 09:18 Message: Logged In: YES user_id=642936 I must admit, that longnames/longlinks haven't been covered at all by the test suite until now. Shame on me :-( So I'm working on some general testcases right now. While writing the tests, I discovered yet another bug in the longname creation code that must be fixed. Shame on me again :-(( If you agree, Neal, I will submit a second patch that eliminates this new bug and includes a complete set of test cases for both bugs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-14 10:14 Message: Logged In: YES user_id=33168 Lars, could you add a test case for this as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=846659&group_id=5470 From noreply at sourceforge.net Sun Dec 21 23:36:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 21 23:36:38 2003 Subject: [Patches] [ python-Patches-815911 ] Extension logging.handlers.SocketHandler Message-ID: Patches item #815911, was opened at 2003-10-01 11:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=815911&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Olson (olson) >Assigned to: Vinay Sajip (vsajip) Summary: Extension logging.handlers.SocketHandler Initial Comment: I've started using the logging SocketHandler, but don't want the absence of a server to affect the running application. The attached subclass of SocketHandler should handle the cases where a server cannot be contacted, or where the connection is dropped. If the server cannot be contacted after a drop, the connection is periodically retried using a simple exponential backoff scheme. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-21 23:36 Message: Logged In: YES user_id=33168 Vinay, now that you're on the project you get this patch. :-) ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-12-01 05:46 Message: Logged In: YES user_id=308438 Refactored into base SocketHandler class and submitted as Patch #851993. Thanks to Robert Olson for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=815911&group_id=5470 From noreply at sourceforge.net Tue Dec 23 03:28:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Dec 23 03:28:59 2003 Subject: [Patches] [ python-Patches-864863 ] Bisect C implementation Message-ID: Patches item #864863, was opened at 2003-12-23 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Bisect C implementation Initial Comment: Bisect C implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 From PatelJessiel at juno.com Tue Dec 23 09:28:30 2003 From: PatelJessiel at juno.com (Ariana Walwyn) Date: Tue Dec 23 09:29:05 2003 Subject: [Patches] patches Anti Spy Cam Device Roots Out Hidden Cams Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20031224/8fbb390e/attachment.html From noreply at sourceforge.net Wed Dec 24 03:20:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 03:20:22 2003 Subject: [Patches] [ python-Patches-864059 ] optimize eval_frame Message-ID: Patches item #864059, was opened at 2003-12-21 13:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Raymond Hettinger (rhettinger) Summary: optimize eval_frame Initial Comment: There are several different parts to this patch which are separable. They each seemed to have a small benefit. It would be interesting for others to test this patch in whole and in different parts to see if speed can be improved. I generally got between 1% - 10% improvement. I used pystone, pybench, and the total time to run all regression tests. Runs were on a RH9 Linux/Athlon 650. I used a non-debug build (so gcc 3.2 with -O3). All regression tests pass with these changes. I removed registers from many variables. This seemed to have little to no effect. So I'm not sure about those. opcode does not need to be initialized to 0. I removed the freevars variable since it is rarely used. I think the largest benefit was from adding the gotos for opcodes which set why: BREAK_LOOP, CONTINUE_LOOP, RETURN_VALUE, YIELD_VALUE; This skips many tests which are known a priori depending on the opcode. I removed the special check for list in UNPACK_SEQUENCE since this path is rarely used. (http://coverage.livinglogic.de/file.phtml?file%5fid=12442339) I also removed the predcitions for JUMP_IF_TRUE since this wasn't executed often (see previous URL). I added 2 opcodes for calling functions with 0 or 1 arguments. This removed a lot of code in call_function(). By removing test branches in several places, this seemed to speed up the code. However, it seemed that just specializing for 0 arguments was better than for 1 arg. I'm not sure if the specialization for 1 argument provides much benefit. Both of these specializations could possibly be improved to speed things up. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-24 03:20 Message: Logged In: YES user_id=80475 I'll try these out and review the patch when I get back from vacation next week. The list special case for UNPACK_SEQUENCE and the prediction for JUMP_IF_TRUE should be left in -- they do provide speed-ups for code that exercises those features and they don't hurt the general cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 From noreply at sourceforge.net Wed Dec 24 03:21:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 03:21:47 2003 Subject: [Patches] [ python-Patches-859286 ] documentation bool change fix Message-ID: Patches item #859286, was opened at 2003-12-12 20:17 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859286&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: documentation bool change fix Initial Comment: This patch fixes bool value changes in the docs. I've confirmed these values on Python 2.3. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859286&group_id=5470 From noreply at sourceforge.net Wed Dec 24 12:25:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 24 12:25:41 2003 Subject: [Patches] [ python-Patches-865455 ] ConfigParser: fixes mixed-case interpolations (bug 857881) Message-ID: Patches item #865455, was opened at 2003-12-24 11:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=865455&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jordan R McCoy (jrm) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser: fixes mixed-case interpolations (bug 857881) Initial Comment: (Python CVS on FreeBSD 4.7 release) ConfigParser translates option names into full lowercase before associating them with the section dictionary (in function RawConfigParser->optionxform, used multiple locations); this seems to indicate that option names should be interpreted in a case-insensitive manner. However, the interpolation function in ConfigParser (_interpolate), uses the standard % string substitution construct, which is of course case-sensitive...thus, interpolations like '%(logFilename)' generate an exception. (See bug report 857881 for test case.) This patch translates interpolations to full lowercase using a regular expression substitution before they are interpolated. Since interpolations may run multiple times depending on their depth, this isn't the optimal solution, but is probably faster then the tokenizer interpolation used by SafeConfigParser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=865455&group_id=5470 From noreply at sourceforge.net Fri Dec 26 10:53:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 26 10:53:24 2003 Subject: [Patches] [ python-Patches-804180 ] A ForwardingHandler for logging Message-ID: Patches item #804180, was opened at 2003-09-11 05:07 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Vinay Sajip (vsajip) Summary: A ForwardingHandler for logging Initial Comment: This was suggested recently on python-dev. I'm proposing it as an addition to the standard set of handlers in the logging package. ForwardingHandler simply forwards logging records to another logger elsewhere in the logging hierarchy. I like to think of this handler as a "softlink" for logging. The initialization method accepts the name of the logger object it should forward to, which is then fetched using getLogger(). This is preferrable to accepting the logger object itself because it's easier for a configuration file to reference another logger by its "qualname". If a name is not given to the initialization method, the handler will forward to the root logger. The emit method guards against infinite loops that would result from a logger object forwarding to itself (perhaps the result of misconfiguration). The attached file is not a "diff" file but just a code fragment that can be inserted somewhere in logging/__init__.py (or in logging/handlers.py with some minor modifications). ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2003-12-26 15:53 Message: Logged In: YES user_id=308438 Not required, as existing API offers sufficient flexibility to deal with the use cases covered by this patch (AFAICT). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 13:47 Message: Logged In: YES user_id=308438 Whoops, mea culpa. I typed "logger" when I meant "handler". Sorry to have caused confusion. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 12:42 Message: Logged In: YES user_id=843448 Okay, perhaps I was misinterpreting the third item from your previous comment where you said: "But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore",and I can see both sets of events together." I guess it's not clear to me what you mean by "the same logger". Perhaps you meant "the same handler", which would be more in line with your most recent comments? ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 08:19 Message: Logged In: YES user_id=308438 I think/hope I understand the issue you're trying to address, and I think the existing API supports your use case. But your comment "The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me" appears to mix up loggers and handlers. It's handlers which are attachable to multiple points in the hierarchy - loggers define the hierarchy. Loggers relate to events which occur in code - it's the developer's choice of logger name which indicates where in their scheme of things an event belongs. However, the audience of interested parties for the event is dynamic, and for that you need to use handlers, not loggers. To achieve the effect where you want a library module's logging output to be directed to your application's log, which is the use case you mention, add an appropriate handler (e.g. one which writes to your application's disk log file) to the module's logger. So, if a module has a logger accessible via a getCurrentLogger() function, you can say myAppLogFileHandler = FileHandler(...) module.getCurrentLogger().addHandler(myAppLogFileHandler) and then the module's events get logged to your application's log file. They will appear with the logger name specified by the module, making it very clear where the event originated. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 05:33 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Matthew F. Barnes (mfbarnes) Date: 2003-09-12 05:32 Message: Logged In: YES user_id=843448 The patch was motivated by an issue I see where a module has hard-coded a logger name into its logic, and an application would like to use that module as-is (e.g. a module from the standard library) but direct log messages from that module elsewhere in the logging hierarchy. The ForwardingHandler is intended to be a mechanism for doing so. The idea of using the same logger object at multiple points in the hierarchy is interesting and had not occurred to me, but it's not clear to me from the Python 2.3 documentation how to set that up (neither via the logging API nor from a configuration file), and I'm not sure if it addresses the issue I'm trying to resolve. You did identify some legitimate bugs in comments (1) and (2), and I've submitted a second patch which hopefully should address them. The bugs I've tried to address are defaulting to root, comparing a Handler instance to a Logger instance, and having the wrong logger name show up in the recipient's output. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-09-12 01:06 Message: Logged In: YES user_id=308438 I would make the following comments about this patch: 1. The logger name captures what happened/where it happened. If an event gets forwarded to a different logger, it just gets handled by that logger's handlers (assuming filtering lets it through), but is otherwise unchanged. If you forward an event from "asyncore" to "myapp.network.asyncore", the name would not change - it would get passed to "myapp.network.asyncore" handlers but still get emitted with a name of "asyncore". The same effect could be achieved by configuring handlers appropriately. Doing it this way, you could quite get easily get duplicated messages, which makes logs less useful. Particularly, the defaulting to the root logger is not a good idea - since many events filter up to the root logger, it would be very easy with the default to get lots of duplicated messages. 2. In ForwardingHandler.emit, self is a ForwardingHandler but self.recipient is a Logger. So the "if" condition will always evaluate to true. 3. Event loggers are the equivalent of "publish", and event handlers the equivalent of "subscribe". Mixing the two is not necessarily such a good idea. Events should be logged, by the developer, using a logger name which makes sense in the context of the module, subsystem or application. So, if an event occurs in "asyncore", we want to know that it happened in "asyncore". But if I want to see it interspersed with other stuff I'm doing in "myapp.network.asyncore", an application built on top of asyncore, I just add the same logger to "asyncore" and "myapp.network.asyncore", and I can see both sets of events together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=804180&group_id=5470 From noreply at sourceforge.net Fri Dec 26 11:55:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 26 11:55:30 2003 Subject: [Patches] [ python-Patches-864863 ] Bisect C implementation Message-ID: Patches item #864863, was opened at 2003-12-23 03:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Raymond Hettinger (rhettinger) Summary: Bisect C implementation Initial Comment: Bisect C implementation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-26 11:55 Message: Logged In: YES user_id=80475 I'll take a look at this in a few days. One idea is to rename it to _bisect and then conditionally import it into bisect.py. That would preserve the teaching value of the existing module while providing a good speed-up for users working with sorted data. Since this module has been around for a long time, it is likely that there have been many uncoventential uses. So, it is important to make sure a replacement can handle all of the same types of input (any container object defining __len__(), __getitem__(), and insert(); and member objects defining __lt__()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 From noreply at sourceforge.net Fri Dec 26 11:57:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 26 11:57:12 2003 Subject: [Patches] [ python-Patches-865455 ] ConfigParser: fixes mixed-case interpolations (bug 857881) Message-ID: Patches item #865455, was opened at 2003-12-24 12:25 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=865455&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jordan R McCoy (jrm) >Assigned to: Raymond Hettinger (rhettinger) Summary: ConfigParser: fixes mixed-case interpolations (bug 857881) Initial Comment: (Python CVS on FreeBSD 4.7 release) ConfigParser translates option names into full lowercase before associating them with the section dictionary (in function RawConfigParser->optionxform, used multiple locations); this seems to indicate that option names should be interpreted in a case-insensitive manner. However, the interpolation function in ConfigParser (_interpolate), uses the standard % string substitution construct, which is of course case-sensitive...thus, interpolations like '%(logFilename)' generate an exception. (See bug report 857881 for test case.) This patch translates interpolations to full lowercase using a regular expression substitution before they are interpolated. Since interpolations may run multiple times depending on their depth, this isn't the optimal solution, but is probably faster then the tokenizer interpolation used by SafeConfigParser. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=865455&group_id=5470 From noreply at sourceforge.net Fri Dec 26 16:47:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Dec 26 16:47:33 2003 Subject: [Patches] [ python-Patches-752911 ] ast-branch: multiple function fixes Message-ID: Patches item #752911, was opened at 2003-06-11 17:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: multiple function fixes Initial Comment: This patch fixes: - handling of keywords, varargs, and kwargs on function definition - handing of keywords, varargs, and kwargs on function call - handling of keywords for lambdas - function chaining (foo().bar().baz()) Applying this uncovers some another bug that at least: - cause a core dump upon import of sre_parse - cause an infinate loop upon import of ntpath I believe I've tracked down the problem to the generation of bad bytecode for nested loops, as in: for x in 1,2: for y in 3,4: print x,y This causes problems with Subpattern.dump() in sre_parse and ntpath's commonprefix(). I'll try to figure out what's wrong with nested loops next. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-26 16:47 Message: Logged In: YES user_id=33168 Almost all of this has been checked in by Jeremy. I'm not sure if he took it from the patch or not. There are only two small changes that look like they haven't been applied. Attached is an updated patch. The updated patch fixes a problem when MAKE_FUNCTION on a lambda. It always used the len of args, rather than the length of defaults. The other fix is for calling a func with **kwargs. The # args never included the kwarg count. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 From noreply at sourceforge.net Sat Dec 27 11:17:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 27 11:21:08 2003 Subject: [Patches] [ python-Patches-752911 ] ast-branch: multiple function fixes Message-ID: Patches item #752911, was opened at 2003-06-11 17:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) Assigned to: Jeremy Hylton (jhylton) Summary: ast-branch: multiple function fixes Initial Comment: This patch fixes: - handling of keywords, varargs, and kwargs on function definition - handing of keywords, varargs, and kwargs on function call - handling of keywords for lambdas - function chaining (foo().bar().baz()) Applying this uncovers some another bug that at least: - cause a core dump upon import of sre_parse - cause an infinate loop upon import of ntpath I believe I've tracked down the problem to the generation of bad bytecode for nested loops, as in: for x in 1,2: for y in 3,4: print x,y This causes problems with Subpattern.dump() in sre_parse and ntpath's commonprefix(). I'll try to figure out what's wrong with nested loops next. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-27 11:17 Message: Logged In: YES user_id=33168 for/while loops are fixed, afaik. The rest of this patch was implemented. So calling functions with keywords and chaining comparison operators should work. Python/newcompile.c 1.1.2.58 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-26 16:47 Message: Logged In: YES user_id=33168 Almost all of this has been checked in by Jeremy. I'm not sure if he took it from the patch or not. There are only two small changes that look like they haven't been applied. Attached is an updated patch. The updated patch fixes a problem when MAKE_FUNCTION on a lambda. It always used the len of args, rather than the length of defaults. The other fix is for calling a func with **kwargs. The # args never included the kwarg count. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=752911&group_id=5470 From noreply at sourceforge.net Sat Dec 27 13:48:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 27 13:49:05 2003 Subject: [Patches] [ python-Patches-632934 ] Problem at the end of misformed mailbox Message-ID: Patches item #632934, was opened at 2002-11-03 17:50 Message generated for change (Comment added) made by rpeyron You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: R?mi Peyronnet (rpeyron) Assigned to: Nobody/Anonymous (nobody) Summary: Problem at the end of misformed mailbox Initial Comment: I had a problem with a not well formed mailbox (maybe ambiguous carriage return chars, due to both use under windows and linux) : the function mailbox.readlines (lib/mailbox.py:66) entered in an indefinite cycle. I found that the self.stop value was too big for the file, and that the index of self.pos could not go that far. The function readlines will call ever and ever readline, which will return always the same 1-length string. I solved this by comparing the fp.pos before and after the read operation. If it the same, we re probably at the end of the file, or there is a problem, and we should go out. As I do not know much about the Python internals, the following patch may not be good : C:\Python222\Lib>diff "Copie de mailbox.py" mailbox.py 63c63,68 < self.pos = self.fp.tell() --- > data = self.fp.readline(length) > self_fp_tell = self.fp.tell() > if self.pos == self_fp_tell: > return '' > else: > self.pos = self_fp_tell Regards ---------------------------------------------------------------------- >Comment By: R?mi Peyronnet (rpeyron) Date: 2003-12-27 19:48 Message: Logged In: YES user_id=641559 This problem seems to exist in 2.3 version too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=632934&group_id=5470 From noreply at sourceforge.net Sun Dec 28 05:06:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 28 05:06:50 2003 Subject: [Patches] [ python-Patches-866594 ] heapq: A way to change the compare function Message-ID: Patches item #866594, was opened at 2003-12-28 12:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: heapq: A way to change the compare function Initial Comment: It'd be nice if heapq could use a custom compare function. This way the user won't need to write a class with <= method. I've added set_cmp(cmp=None) for setting the comparision function. Using cmp and not expliclty <= makes later changes in implementation easier. Attached are the diffs. BTW: I know in CVS heapq is a C module now, don't have the time to change my patch... Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 From noreply at sourceforge.net Sun Dec 28 22:21:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Dec 28 22:21:48 2003 Subject: [Patches] [ python-Patches-866875 ] str.split optimization for one character separaters Message-ID: Patches item #866875, was opened at 2003-12-29 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866875&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: str.split optimization for one character separaters Initial Comment: Attached patch tries to optimize str.split by a speciaiized splitter for one character separacters. This trick is used for unicode.split too. I just applied it to str.split. :) quick perf. test: - BEFORE - % ./python Lib/timeit.py '"/aaa/bbb/ccc/ddd/eee/fff/ggg/hhh/iii".split("/")' 100000 loops, best of 3: 7.84 usec per loop - AFTER - % ./python Lib/timeit.py '"/aaa/bbb/ccc/ddd/eee/fff/ggg/hhh/iii".split("/")' 100000 loops, best of 3: 5.39 usec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866875&group_id=5470 From noreply at sourceforge.net Mon Dec 29 03:18:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 03:18:11 2003 Subject: [Patches] [ python-Patches-864863 ] Bisect C implementation Message-ID: Patches item #864863, was opened at 2003-12-23 11:28 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Raymond Hettinger (rhettinger) Summary: Bisect C implementation Initial Comment: Bisect C implementation. ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-12-29 11:18 Message: Logged In: YES user_id=388573 > One idea is to rename it to _bisect and then conditionally > import it into bisect.py. That would preserve the teaching > value of the existing module while providing a good speed-up > for users working with sorted data. Maybe just do 'from _bisect import *' while preserve old code as comment or doc string? > Since this module has been around for a long time, it is likely > that there have been many uncoventential uses. So, it is > important to make sure a replacement can handle all of the > same types of input (any container object defining __len__(), > __getitem__(), and insert(); and member objects defining > __lt__()). I've made new test case for custom container object. One new idea I have is full slice semantic for lo and hi arguments. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-26 19:55 Message: Logged In: YES user_id=80475 I'll take a look at this in a few days. One idea is to rename it to _bisect and then conditionally import it into bisect.py. That would preserve the teaching value of the existing module while providing a good speed-up for users working with sorted data. Since this module has been around for a long time, it is likely that there have been many uncoventential uses. So, it is important to make sure a replacement can handle all of the same types of input (any container object defining __len__(), __getitem__(), and insert(); and member objects defining __lt__()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 From noreply at sourceforge.net Mon Dec 29 05:29:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 05:29:49 2003 Subject: [Patches] [ python-Patches-866982 ] Bad behavior of email.Charset.Charset when locale is tr_TR Message-ID: Patches item #866982, was opened at 2003-12-29 10:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Bad behavior of email.Charset.Charset when locale is tr_TR Initial Comment: Charset class' behaviour is bad when locale is set to tr_TR. The problems's source is input_charset = input_charset.lower() at line 393 of /usr/lib/python2.3/email/Charset.py . This exeample code can reproduce the error: import locale from email.Charset import Charset locale.setlocale(locale.LC_ALL,("tr_TR","ISO-8859-9")) foo = Charset(locale.nl_langinfo(locale.CODESET)) repr(foo) #Returns \xfdso-8859-9 which is not a charset instead of iso-8859-9 The problem exists because the lower() of I in turkish charset is ? (\xfd), not i. I will try to create and submit a patch ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 From noreply at sourceforge.net Mon Dec 29 05:30:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 05:30:42 2003 Subject: [Patches] [ python-Patches-866982 ] Bad behavior of email.Charset.Charset when locale is tr_TR Message-ID: Patches item #866982, was opened at 2003-12-29 10:29 Message generated for change (Settings changed) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 >Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Bad behavior of email.Charset.Charset when locale is tr_TR Initial Comment: Charset class' behaviour is bad when locale is set to tr_TR. The problems's source is input_charset = input_charset.lower() at line 393 of /usr/lib/python2.3/email/Charset.py . This exeample code can reproduce the error: import locale from email.Charset import Charset locale.setlocale(locale.LC_ALL,("tr_TR","ISO-8859-9")) foo = Charset(locale.nl_langinfo(locale.CODESET)) repr(foo) #Returns \xfdso-8859-9 which is not a charset instead of iso-8859-9 The problem exists because the lower() of I in turkish charset is ? (\xfd), not i. I will try to create and submit a patch ASAP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 From noreply at sourceforge.net Mon Dec 29 09:53:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 09:53:32 2003 Subject: [Patches] [ python-Patches-866594 ] heapq: A way to change the compare function Message-ID: Patches item #866594, was opened at 2003-12-28 05:06 Message generated for change (Comment added) made by mcherm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: heapq: A way to change the compare function Initial Comment: It'd be nice if heapq could use a custom compare function. This way the user won't need to write a class with <= method. I've added set_cmp(cmp=None) for setting the comparision function. Using cmp and not expliclty <= makes later changes in implementation easier. Attached are the diffs. BTW: I know in CVS heapq is a C module now, don't have the time to change my patch... Miki ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-29 09:53 Message: Logged In: YES user_id=99874 Can you explain better the motivation for adding this? I don't find writing __le__() to be a significant problem normally, and setting the global _le seems a less-than-perfect design. What is a use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 From noreply at sourceforge.net Mon Dec 29 12:29:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Dec 29 12:29:33 2003 Subject: [Patches] [ python-Patches-866982 ] Bad behavior of email.Charset.Charset when locale is tr_TR Message-ID: Patches item #866982, was opened at 2003-12-29 11:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Bad behavior of email.Charset.Charset when locale is tr_TR Initial Comment: Charset class' behaviour is bad when locale is set to tr_TR. The problems's source is input_charset = input_charset.lower() at line 393 of /usr/lib/python2.3/email/Charset.py . This exeample code can reproduce the error: import locale from email.Charset import Charset locale.setlocale(locale.LC_ALL,("tr_TR","ISO-8859-9")) foo = Charset(locale.nl_langinfo(locale.CODESET)) repr(foo) #Returns \xfdso-8859-9 which is not a charset instead of iso-8859-9 The problem exists because the lower() of I in turkish charset is ? (\xfd), not i. I will try to create and submit a patch ASAP. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-12-29 18:29 Message: Logged In: YES user_id=21627 See the python-dev discussion. My proposal is to add ascii_lower to , and use that. Charset.py might then use your code as a fallback. Actually, it might be even more performant to do lower_map = string.maketrans(string.ascii_upper, string.ascii_lower) def _ascii_lower(str): return str.translate(lower_map) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 From noreply at sourceforge.net Wed Dec 31 11:34:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 11:35:02 2003 Subject: [Patches] [ python-Patches-868496 ] base64.py support for RFC 3548 Message-ID: Patches item #868496, was opened at 2003-12-31 11:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Tim Peters (tim_one) Summary: base64.py support for RFC 3548 Initial Comment: I needed more complete RFC 3548 support, so I hacked up the base64.py module. Here's the patch and an updated test suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 From noreply at sourceforge.net Wed Dec 31 11:38:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 11:38:49 2003 Subject: [Patches] [ python-Patches-868499 ] regrtest.py -T for code coverage Message-ID: Patches item #868499, was opened at 2003-12-31 11:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868499&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Jeremy Hylton (jhylton) Summary: regrtest.py -T for code coverage Initial Comment: This is a fairly simpleminded adaptation of Zope3's test.py -T (code coverage) flag to Python 2.4's regrtest.py module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868499&group_id=5470 From noreply at sourceforge.net Wed Dec 31 13:37:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 13:37:56 2003 Subject: [Patches] [ python-Patches-859286 ] documentation bool change fix Message-ID: Patches item #859286, was opened at 2003-12-12 20:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859286&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Raymond Hettinger (rhettinger) Summary: documentation bool change fix Initial Comment: This patch fixes bool value changes in the docs. I've confirmed these values on Python 2.3. Thanks. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 13:37 Message: Logged In: YES user_id=80475 Accepted and applied. Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=859286&group_id=5470 From noreply at sourceforge.net Wed Dec 31 13:38:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 13:38:58 2003 Subject: [Patches] [ python-Patches-866594 ] heapq: A way to change the compare function Message-ID: Patches item #866594, was opened at 2003-12-28 05:06 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Raymond Hettinger (rhettinger) Summary: heapq: A way to change the compare function Initial Comment: It'd be nice if heapq could use a custom compare function. This way the user won't need to write a class with <= method. I've added set_cmp(cmp=None) for setting the comparision function. Using cmp and not expliclty <= makes later changes in implementation easier. Attached are the diffs. BTW: I know in CVS heapq is a C module now, don't have the time to change my patch... Miki ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-29 09:53 Message: Logged In: YES user_id=99874 Can you explain better the motivation for adding this? I don't find writing __le__() to be a significant problem normally, and setting the global _le seems a less-than-perfect design. What is a use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 From noreply at sourceforge.net Wed Dec 31 16:37:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 16:38:06 2003 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 12:03 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Raymond Hettinger (rhettinger) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-03-04 03:01 Message: Logged In: YES user_id=498191 I would suggest another possibility. This one use a property of strings ordering: if you have a<=b<=c and c.startswith(a) then b.startswith(a). I have tested two implementations : # a 5 lines function with a really straightforward code. # It can degenerate rather badly in the worst case (large strings # with a short common prefix) but is generally quite fast. def commonprefix1(m): if not m: return '' prefix, greater = min(m), max(m) while not greater.startswith(prefix): prefix = prefix[:-1] return prefix # The second use a bissection to avoid the worst case. This make # the implementation a little more complex but seems to provide the # fastest result. def commonprefix2(m): prefix = '' if m: low, high = min(m), max(m) while low: n = len(low)//2 + 1 l, h = low[:n], high[:n] if h==l: prefix += l low, high = low[n:], high[n:] else: low, high = l[:-1], h return prefix I personally prefer the commonprefix1 implementation: its the simplest one and it is probably fast enough for the few commonprefix use-cases (anyway, it is still faster than the current implementation). ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-07 06:11 Message: Logged In: YES user_id=539787 I did my homework better, and found out that the buffer object quite probably will be deprecated. So I rewrote the routine without the buffer object (using str.startswith), which by the way got another 10% speedup (relative to the latest version using buffer.) The commonprefix_nobuf.diff patch applies directly to the original posixpath.py, ntpath.py. I will try to delete the other patches, but I don't think I am allowed to do it. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 13:02 Message: Logged In: YES user_id=539787 Best case: comparing this to the old version with a list: ['/usr/local/lib/python2.3/posixpath.py']*120, 10000 iterations, the speed difference is: old: 319.58 sec new: 34.43 sec Since prefix_len always grows in the "while next_bit:" loop, applying commonprefix2.diff to the *patched* version does a very minor speedup (comparing smaller buffers in every iteration); but it is only a matter of overoptimisation (ie it does not hurt, but it's a trivial one, just 0.1%). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 12:25 Message: Logged In: YES user_id=33168 As much as I'd like to blame IE, it's a SF bug AFAIK. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 12:04 Message: Logged In: YES user_id=539787 For some reason, my IE never uploads the file on the first attempt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply at sourceforge.net Wed Dec 31 17:47:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 17:47:09 2003 Subject: [Patches] [ python-Patches-681780 ] Faster commonprefix (OS independent) Message-ID: Patches item #681780, was opened at 2003-02-06 12:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Raymond Hettinger (rhettinger) Summary: Faster commonprefix (OS independent) Initial Comment: This routine is about 20% faster on a test set of 7 sets of strings run 100000 times each (I can provide the test if requested). The longer the common prefix is, the faster the routine becomes relative to original commonprefix. My only worry is that it might get rejected if it is considered too fancy; therefore I wasn't shy on commenting. I think we should also write a commonpathprefix, that will do what commonprefix should do, being in the *path.py module. I'll do that if none other does. The provided patch is for posixpath.py and ntpath.py, but since it's OS neutral it should work as is. It uses itertools for speed, though, so it is not backportable, but it can be if requested by substituting map for imap and a normal slice for islice. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 17:47 Message: Logged In: YES user_id=80475 Applied Terry Reedy's solution to Lib/posixpath.py 1.64. His solution is at: http://groups.google.com/groups? th=fc7b54f11af6b24e&seekm=bss2so$om$5@news.t- online.com ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-03-04 03:01 Message: Logged In: YES user_id=498191 I would suggest another possibility. This one use a property of strings ordering: if you have a<=b<=c and c.startswith(a) then b.startswith(a). I have tested two implementations : # a 5 lines function with a really straightforward code. # It can degenerate rather badly in the worst case (large strings # with a short common prefix) but is generally quite fast. def commonprefix1(m): if not m: return '' prefix, greater = min(m), max(m) while not greater.startswith(prefix): prefix = prefix[:-1] return prefix # The second use a bissection to avoid the worst case. This make # the implementation a little more complex but seems to provide the # fastest result. def commonprefix2(m): prefix = '' if m: low, high = min(m), max(m) while low: n = len(low)//2 + 1 l, h = low[:n], high[:n] if h==l: prefix += l low, high = low[n:], high[n:] else: low, high = l[:-1], h return prefix I personally prefer the commonprefix1 implementation: its the simplest one and it is probably fast enough for the few commonprefix use-cases (anyway, it is still faster than the current implementation). ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-07 06:11 Message: Logged In: YES user_id=539787 I did my homework better, and found out that the buffer object quite probably will be deprecated. So I rewrote the routine without the buffer object (using str.startswith), which by the way got another 10% speedup (relative to the latest version using buffer.) The commonprefix_nobuf.diff patch applies directly to the original posixpath.py, ntpath.py. I will try to delete the other patches, but I don't think I am allowed to do it. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 13:02 Message: Logged In: YES user_id=539787 Best case: comparing this to the old version with a list: ['/usr/local/lib/python2.3/posixpath.py']*120, 10000 iterations, the speed difference is: old: 319.58 sec new: 34.43 sec Since prefix_len always grows in the "while next_bit:" loop, applying commonprefix2.diff to the *patched* version does a very minor speedup (comparing smaller buffers in every iteration); but it is only a matter of overoptimisation (ie it does not hurt, but it's a trivial one, just 0.1%). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 12:25 Message: Logged In: YES user_id=33168 As much as I'd like to blame IE, it's a SF bug AFAIK. http://sf.net/tracker/?func=detail&atid=200001&aid=675910&group_id=1 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-02-06 12:04 Message: Logged In: YES user_id=539787 For some reason, my IE never uploads the file on the first attempt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=681780&group_id=5470 From noreply at sourceforge.net Wed Dec 31 17:54:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 17:54:47 2003 Subject: [Patches] [ python-Patches-866594 ] heapq: A way to change the compare function Message-ID: Patches item #866594, was opened at 2003-12-28 05:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Raymond Hettinger (rhettinger) Summary: heapq: A way to change the compare function Initial Comment: It'd be nice if heapq could use a custom compare function. This way the user won't need to write a class with <= method. I've added set_cmp(cmp=None) for setting the comparision function. Using cmp and not expliclty <= makes later changes in implementation easier. Attached are the diffs. BTW: I know in CVS heapq is a C module now, don't have the time to change my patch... Miki ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 17:54 Message: Logged In: YES user_id=80475 There is no shortage of use cases -- sometimes top priorities have higher numbers -- the use cases are basically the same as those for descending sorts. The proposed solution must be rejected because the global variable would be shared among all modules using heapq. It is possible the one module relies on __le__ while other modules might prefer __ge__. Those modules could be used at the same time. If a non-global solution is found, please re-submit. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-29 09:53 Message: Logged In: YES user_id=99874 Can you explain better the motivation for adding this? I don't find writing __le__() to be a significant problem normally, and setting the global _le seems a less-than-perfect design. What is a use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 From noreply at sourceforge.net Wed Dec 31 22:42:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 22:42:43 2003 Subject: [Patches] [ python-Patches-864059 ] optimize eval_frame Message-ID: Patches item #864059, was opened at 2003-12-21 13:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: optimize eval_frame Initial Comment: There are several different parts to this patch which are separable. They each seemed to have a small benefit. It would be interesting for others to test this patch in whole and in different parts to see if speed can be improved. I generally got between 1% - 10% improvement. I used pystone, pybench, and the total time to run all regression tests. Runs were on a RH9 Linux/Athlon 650. I used a non-debug build (so gcc 3.2 with -O3). All regression tests pass with these changes. I removed registers from many variables. This seemed to have little to no effect. So I'm not sure about those. opcode does not need to be initialized to 0. I removed the freevars variable since it is rarely used. I think the largest benefit was from adding the gotos for opcodes which set why: BREAK_LOOP, CONTINUE_LOOP, RETURN_VALUE, YIELD_VALUE; This skips many tests which are known a priori depending on the opcode. I removed the special check for list in UNPACK_SEQUENCE since this path is rarely used. (http://coverage.livinglogic.de/file.phtml?file%5fid=12442339) I also removed the predcitions for JUMP_IF_TRUE since this wasn't executed often (see previous URL). I added 2 opcodes for calling functions with 0 or 1 arguments. This removed a lot of code in call_function(). By removing test branches in several places, this seemed to speed up the code. However, it seemed that just specializing for 0 arguments was better than for 1 arg. I'm not sure if the specialization for 1 argument provides much benefit. Both of these specializations could possibly be improved to speed things up. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 22:42 Message: Logged In: YES user_id=80475 The patch is promising. I'm able to measure a small speed- up for the two new function opcodes and for the setwhy gotos. Both optimizations make sense. I don't measure a savings from not initializing opcode and oparg. That change makes sense conceptually because the variables are always assigned before use; however, the surrounding control flow statements hide that fact from the compiler. So, it is likely that they were initialized to suppress warnings on somebody's system. If so, then that change should not be made. The other stuff should definitely be left out. The effect of register variables will vary from compiler to compiler, so if you can't measure an improvement, it is best to leave it alone. Some compilers do not do much in the way of optimization and the register declaration may be a valuable hint. Please leave in the branch prediction for JUMP_IF_TRUE -- I put it in after finding measurable savings in real code. While it doesn't come up often, when it does it should run as fast as possible. The special case for UNPACK_SEQUENCE is up for grabs. When that case occurs, the speedup is substantial. Also, given that the tuple check has failed, it becomes highly probable that the target is a list. OTOH, this inlined code fattens the already voluminuous code for eval_frame. Maybe eliminating it will help someone's optimizer cope with all the code. Use your judgement on this one. Removing the freevars variable did not show any speedup. It does keep one variable off the stack and shortens the startup time by a few instructions. OTOH, the in-lined replacements for it result in a net expansion of code size and causes a microscopic slowdown whenever it is used. I recommend leaving this one alone. Executive summary: Only make the two big changes that show meaurable speedups and make conceptual sense. Leave the other stuff alone. One other thought, try making custom benchmarks for targeted optimizations. The broad spectrum benchmarks are too coarse to tell whether an improvement is really working. Also, be sure to check with Guido before adding the new opcodes. Ideally, each optimization should be loaded separately so its effects can be isolated and to allow any one to be backed out if necessary. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-24 03:20 Message: Logged In: YES user_id=80475 I'll try these out and review the patch when I get back from vacation next week. The list special case for UNPACK_SEQUENCE and the prediction for JUMP_IF_TRUE should be left in -- they do provide speed-ups for code that exercises those features and they don't hurt the general cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 From noreply at sourceforge.net Wed Dec 31 23:00:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Dec 31 23:08:57 2003 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-02 19:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 23:00 Message: Logged In: YES user_id=80475 FWIW, the test for urllib2 is currently failing and needs to be fixed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 11:11 Message: Logged In: YES user_id=261020 Reopening to add a note to Misc/NEWS about the backwards-incompatibility for people who don't use build_opener(). I presume that's the right place for this note? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 10:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 00:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-07 19:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470