From noreply at sourceforge.net Thu Mar 1 00:08:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Feb 2007 15:08:39 -0800 Subject: [Patches] [ python-Patches-1671314 ] New File I/O type for Python 3000, plus .h and unit tests Message-ID: Patches item #1671314, was opened at 2007-02-28 17: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=1671314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel Stutzbach (agthorr) Assigned to: Nobody/Anonymous (nobody) Summary: New File I/O type for Python 3000, plus .h and unit tests Initial Comment: Here is my implementation of a raw File I/O type for Python 3000, along with unit tests. The tests for repr() fail because I'm not 100% sure what repr() should return (in particular, whether the type should bother remembering the filename just to return in repr()). There are comments at the top of the .c file explaining what remains to be done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 From noreply at sourceforge.net Thu Mar 1 07:31:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Feb 2007 22:31:45 -0800 Subject: [Patches] [ python-Patches-1671450 ] Extension documentation for subclasses Message-ID: Patches item #1671450, was opened at 2007-03-01 06:31 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=1671450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pete Shinners (shredwheat) Assigned to: Nobody/Anonymous (nobody) Summary: Extension documentation for subclasses Initial Comment: This adds a new section to the extension documentation for building new types. It documents building a new extension type that inherits from the builtin list type. I haven't been able to get latex2html working on my cygwin setup. The formatting is fairly simple though, so I don't expect it will give much trouble? Willing to accept more feedback on this. I figured since I semi-harangued this state of affairs during my Pycon presentation, it was my duty to do something about it during the following sprints. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671450&group_id=5470 From noreply at sourceforge.net Fri Mar 2 16:29:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 07:29:05 -0800 Subject: [Patches] [ python-Patches-1672481 ] MultiCall bug crashing the config dialog Message-ID: Patches item #1672481, was opened at 2007-03-02 17: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=1672481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: MultiCall bug crashing the config dialog Initial Comment: Simple patch to MultiCall which stops IDLE's config dialog from crashing upon OK/Apply. The bug is caused by ConfigDialog calling event_add() for key bindings only if there are sequences to be bound, while event_delete() is called even if there are no sequences. This causes MultiCall's internal dictionary of virtual events to raise a KeyError when event_delete() is called with a virtual event, for which event_add() was not called. The Best Thing IMO is to have MultiCall check if such an event exists in its internal dict, and if not - just ignore the event_delete() call. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1672481&group_id=5470 From noreply at sourceforge.net Fri Mar 2 16:52:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 02 Mar 2007 07:52:49 -0800 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 18:25 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sat Mar 3 15:01:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 06:01:08 -0800 Subject: [Patches] [ python-Patches-1673007 ] urllib2 requests history + HEAD support Message-ID: Patches item #1673007, was opened at 2007-03-03 16:01 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=1673007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 requests history + HEAD support Initial Comment: 1)Add history off all sent and received headers/requests to addinfourl object. Save redirections history too. >>> fd = urllib2.urlopen("http://www.python.org/") >>> print fd.history[0].request_line GET / HTTP/1.1 >>> print fd.history[0].sended [('Accept-Encoding', 'identity'), ('Host', 'www.python.org'), ('Connection', 'cl ose'), ('User-Agent', 'Python-urllib/2.6')] 2)Add support for HEAD (and other) requests: >>> fd = urllib2.urlopen("http://www.python.org/", request_cmd = "HEAD") >>> print len(fd.read()) 0 Please send email here: koder_dot_mail_at_gmail_dot_com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673007&group_id=5470 From noreply at sourceforge.net Sat Mar 3 19:17:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 10:17:00 -0800 Subject: [Patches] [ python-Patches-1672481 ] MultiCall bug crashing the config dialog Message-ID: Patches item #1672481, was opened at 2007-03-02 17:29 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1672481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: MultiCall bug crashing the config dialog Initial Comment: Simple patch to MultiCall which stops IDLE's config dialog from crashing upon OK/Apply. The bug is caused by ConfigDialog calling event_add() for key bindings only if there are sequences to be bound, while event_delete() is called even if there are no sequences. This causes MultiCall's internal dictionary of virtual events to raise a KeyError when event_delete() is called with a virtual event, for which event_add() was not called. The Best Thing IMO is to have MultiCall check if such an event exists in its internal dict, and if not - just ignore the event_delete() call. Patch attached. ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2007-03-03 20:17 Message: Logged In: YES user_id=1330769 Originator: YES Just to be clear - the bug is that writing certain things in the extension config file (either the user file or the defaults file) causes IDLE's configuration handling mechanism to crash. One symptom is that IDLE's config dialog doesn't save or apply changes, and is therefore useless. The bug occurs when a config option without a value is added under a *_bindings or *_cfgBindings section in the extensions config file. This bug is a result of an assumption in the design of MultiCall which is not true in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1672481&group_id=5470 From noreply at sourceforge.net Sat Mar 3 21:30:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 12:30:53 -0800 Subject: [Patches] [ python-Patches-1673121 ] README update: Bash default on ac OS X Message-ID: Patches item #1673121, was opened at 2007-03-03 15: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=1673121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: README update: Bash default on ac OS X Initial Comment: The bash shell has been the default on Mac OS X since 10.3, and this patch updates the readme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673121&group_id=5470 From noreply at sourceforge.net Sat Mar 3 21:33:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 12:33:46 -0800 Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool Message-ID: Patches item #1673122, was opened at 2007-03-03 15: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=1673122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: libtool Initial Comment: When the framewok is built on Mac OS X, the Mac OS X specific libtool is used. However, if the GNU libtool is on the PATH first, python refuses to build. This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file. That way, someone can have GNU libtool on the PATH first and still build python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 From noreply at sourceforge.net Sat Mar 3 21:34:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 12:34:41 -0800 Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool Message-ID: Patches item #1673122, was opened at 2007-03-03 15:33 Message generated for change (Settings changed) made by herrwitten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Build >Group: Python 2.6 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: libtool Initial Comment: When the framewok is built on Mac OS X, the Mac OS X specific libtool is used. However, if the GNU libtool is on the PATH first, python refuses to build. This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file. That way, someone can have GNU libtool on the PATH first and still build python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 From noreply at sourceforge.net Sat Mar 3 21:35:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 03 Mar 2007 12:35:13 -0800 Subject: [Patches] [ python-Patches-1673121 ] README update: Bash default on Mac OS X Message-ID: Patches item #1673121, was opened at 2007-03-03 15:30 Message generated for change (Settings changed) made by herrwitten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) >Summary: README update: Bash default on Mac OS X Initial Comment: The bash shell has been the default on Mac OS X since 10.3, and this patch updates the readme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673121&group_id=5470 From noreply at sourceforge.net Sun Mar 4 09:40:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 00:40:44 -0800 Subject: [Patches] [ python-Patches-1673355 ] change repr(...) from 'Ellipsis' to '...' Message-ID: Patches item #1673355, was opened at 2007-03-04 00:40 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=1673355&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Reese (johnreese) Assigned to: Nobody/Anonymous (nobody) Summary: change repr(...) from 'Ellipsis' to '...' Initial Comment: Given that in Python 3000 you can now use ... as an expression, it seemed like its repr might as well be ... too. The thread quoted in pep 3100 as the reason for the decision suggested using '(int, ...)' as a type annotation; in such expressions, having ... print as ... would be more readable. Note that this would break any doctests including ellipses; none of the Lib/test tests do, and the non-doctests don't care about the repr and still pass. Since prior to Python 3000 ... could only be used in slices, it's unlikely this will break much. I have now written about 100 times more characters than are changed by the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 From noreply at sourceforge.net Sun Mar 4 09:43:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 00:43:41 -0800 Subject: [Patches] [ python-Patches-1673355 ] change repr(...) from 'Ellipsis' to '...' Message-ID: Patches item #1673355, was opened at 2007-03-04 00:40 Message generated for change (Comment added) made by johnreese You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Reese (johnreese) Assigned to: Nobody/Anonymous (nobody) Summary: change repr(...) from 'Ellipsis' to '...' Initial Comment: Given that in Python 3000 you can now use ... as an expression, it seemed like its repr might as well be ... too. The thread quoted in pep 3100 as the reason for the decision suggested using '(int, ...)' as a type annotation; in such expressions, having ... print as ... would be more readable. Note that this would break any doctests including ellipses; none of the Lib/test tests do, and the non-doctests don't care about the repr and still pass. Since prior to Python 3000 ... could only be used in slices, it's unlikely this will break much. I have now written about 100 times more characters than are changed by the patch. ---------------------------------------------------------------------- >Comment By: John Reese (johnreese) Date: 2007-03-04 00:43 Message: Logged In: YES user_id=1734721 Originator: YES > The thread quoted is http://mail.python.org/pipermail/python-3000/2006-April/000951.html just so you don't have to hunt around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 From jposxouulqx at swbell.net Fri Mar 2 18:28:58 2007 From: jposxouulqx at swbell.net (Sang Priscilla Hammer) Date: Fri, 02 Mar 2007 09:28:58 -0800 Subject: [Patches] Jake, here I just won 786.- EURO Message-ID: <114501c75cf1$8008c2c0$4a8fcc96@YWTX> Just thought about you Jake, Jake, here I just won 786.- EURO Get your start bonus now: - Visit our website http://edfremb.com/micro/16/ and download the playing module in your language (no installation needed) - Register as guest or player......and start winning Cheers Sang Priscilla Hammer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070302/a38c741e/attachment.html From noreply at sourceforge.net Sun Mar 4 22:31:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 13:31:41 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules to be built and not built Message-ID: Patches item #1673619, was opened at 2007-03-04 15:31 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=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Identify modules to be built and not built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Mon Mar 5 00:21:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 15:21:00 -0800 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 09:27 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2007-03-05 00:21 Message: Logged In: YES user_id=142612 Originator: NO Example code crashes Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)], but this bug is closed as fixed. Is this OK? (Maybe I missed something, but this bug still exists...) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-08 09:06 Message: Logged In: YES user_id=849994 Committed rev. 52220 in 2.5 branch. Closing now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-08 02:49 Message: Logged In: YES user_id=33168 Georg, if you don't mind doing this, I think it's fine to go into 2.5.1. I'll try to get around to it at some point if not. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 10:48 Message: Logged In: YES user_id=849994 Time to checkin for 2.5.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 21:48 Message: Logged In: YES user_id=33168 Committed revision 51439. (2.6) Thomas Wouters thinks this is fine to go in 2.5. I'll leave open for now until we decide what to do. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-21 21:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 17:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 10:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Mon Mar 5 02:14:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 17:14:42 -0800 Subject: [Patches] [ python-Patches-1673355 ] change repr(...) from 'Ellipsis' to '...' Message-ID: Patches item #1673355, was opened at 2007-03-04 00:40 Message generated for change (Comment added) made by johnreese You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: John Reese (johnreese) Assigned to: Nobody/Anonymous (nobody) Summary: change repr(...) from 'Ellipsis' to '...' Initial Comment: Given that in Python 3000 you can now use ... as an expression, it seemed like its repr might as well be ... too. The thread quoted in pep 3100 as the reason for the decision suggested using '(int, ...)' as a type annotation; in such expressions, having ... print as ... would be more readable. Note that this would break any doctests including ellipses; none of the Lib/test tests do, and the non-doctests don't care about the repr and still pass. Since prior to Python 3000 ... could only be used in slices, it's unlikely this will break much. I have now written about 100 times more characters than are changed by the patch. ---------------------------------------------------------------------- >Comment By: John Reese (johnreese) Date: 2007-03-04 17:14 Message: Logged In: YES user_id=1734721 Originator: YES (Continuing to talk to myself) It's funny, I mentioned doctest already, thinking just that 'Ellipsis' would now print as '...' and the difference would cause incompatibilities; i.e. the same problem you get any time a __repr__ changes. But there's a worse problem, which is that '...' looks almost exactly like sys.PS2, so a doctest like this will mistake the output for a continuation line and fail: """ >>> Ellipsis ... """ ********************************************************************** File "./doctesterr.py", line 6, in __main__ Failed example: Ellipsis Expected nothing Got: ... ********************************************************************** In light of which grossness this trivial patch is probably not worth it. ---------------------------------------------------------------------- Comment By: John Reese (johnreese) Date: 2007-03-04 00:43 Message: Logged In: YES user_id=1734721 Originator: YES > The thread quoted is http://mail.python.org/pipermail/python-3000/2006-April/000951.html just so you don't have to hunt around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 From noreply at sourceforge.net Mon Mar 5 03:45:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 04 Mar 2007 18:45:59 -0800 Subject: [Patches] [ python-Patches-1673759 ] 'G' formatting doesn't catch same errors as 'g' Message-ID: Patches item #1673759, was opened at 2007-03-04 21: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=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'G' formatting doesn't catch same errors as 'g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From richard_kaihara at comcast.net Mon Mar 5 05:11:14 2007 From: richard_kaihara at comcast.net (richard kaihara) Date: Sun, 4 Mar 2007 20:11:14 -0800 Subject: [Patches] (no subject) Message-ID: <000c01c75edc$52633d40$6f01a8c0@FAMILY> please cancel subscription. thanks rich kaihara -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070304/8ac75ffb/attachment.htm From noreply at sourceforge.net Mon Mar 5 09:28:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 00:28:45 -0800 Subject: [Patches] [ python-Patches-1542451 ] fix crash with continue in nested try/finally Message-ID: Patches item #1542451, was opened at 2006-08-18 00:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: fix crash with continue in nested try/finally Initial Comment: Based on mail from python-dev. http://mail.python.org/pipermail/python-dev/2006-August/068306.html def test(): for abc in range(10): try: pass finally: try: continue except: pass crashes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-05 00:28 Message: Logged In: YES user_id=33168 Originator: YES The bug was fixed after 2.5 was released. The fix is in SVN currently and will be part of the 2.5.1 release. ---------------------------------------------------------------------- Comment By: Viktor Ferenczi (complex) Date: 2007-03-04 15:21 Message: Logged In: YES user_id=142612 Originator: NO Example code crashes Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)], but this bug is closed as fixed. Is this OK? (Maybe I missed something, but this bug still exists...) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-08 00:06 Message: Logged In: YES user_id=849994 Committed rev. 52220 in 2.5 branch. Closing now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-07 17:49 Message: Logged In: YES user_id=33168 Georg, if you don't mind doing this, I think it's fine to go into 2.5.1. I'll try to get around to it at some point if not. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-30 01:48 Message: Logged In: YES user_id=849994 Time to checkin for 2.5.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 12:48 Message: Logged In: YES user_id=33168 Committed revision 51439. (2.6) Thomas Wouters thinks this is fine to go in 2.5. I'll leave open for now until we decide what to do. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-21 12:37 Message: Logged In: YES user_id=34209 I think we should just check this in in 2.5.0. It looks fine, it's the simple and correct fix, and I don't see how it could break legitimate code. It's not a complex piece of code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 08:08 Message: Logged In: YES user_id=33168 I've been thinking similarly. I didn't even update the import magic for this. Did you get a chance to review the patch? It would be nice to get this into 2.6 and then we can figure out if this should go into 2.5.0 (probably not) or 2.5.1 (probably in my current thinking), or just leave it for 2.6. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-19 01:04 Message: Logged In: YES user_id=4771 My two cents are a meta-note: I think that this should not go into 2.5.0. It fixes a bug with syntactically invalid code, which nobody stumbled upon until recently although it has been here for ages, and there is a (small) risk to break syntactically valid code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542451&group_id=5470 From noreply at sourceforge.net Mon Mar 5 10:18:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 01:18:15 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules to be built and not built Message-ID: Patches item #1673619, was opened at 2007-03-04 22:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Identify modules to be built and not built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 10:18 Message: Logged In: YES user_id=21627 Originator: NO I don't think the modules that it builds successfully need to be printed - the build messages will tell, anyway. I'm not sure when it prints these things. IMO, they should be printed at the end of the build (i.e. after all modules have been built). It should also print out, in summary, modules that had been attempted to build, but where building failed for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Mon Mar 5 13:40:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 04:40:04 -0800 Subject: [Patches] [ python-Patches-1507011 ] Use a set to keep interned strings Message-ID: Patches item #1507011, was opened at 2006-06-16 03:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Use a set to keep interned strings Initial Comment: This patch is a proof of concept only. In particular, _PySet_LookString is *not* proposed for addition to set API. Better performance can probably be achieved by implementing interning completely inside setobject.c . ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 13:40 Message: Logged In: YES user_id=21627 Originator: NO As nobody else is speaking in favour of this patch, I'm rejecting it. I disagree with Alexander's last remark in several respects: set is indeed a container, and there is a way to get the elements back (namely, by enumerating them, or picking an arbitrary element for removal). There is no operation to check, on insertion of E, what the the prior element equal to E was (if any); there is only a check to determine whether E is in the set. The operation "give me the member equal but not identical to E" is conceptually a lookup operation; the mathematical set construct has no such operation, and the Python set models it closely. IOW, set is *not* a dict with key==value. Without reviewing the patch again, I also doubt it is capable of getting rid of the reference count cheating: essentially, this cheating enables the interning dictionary to have weak references to strings, this is important to allow automatic collection of certain interned strings. This feature needs to be preserved, so the cheating in the reference count must continue. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-30 22:33 Message: Logged In: YES user_id=835142 I did not measure the memory usage and I don't think such measurement will yield a compelling reason for the change. I suggested that a set is half of a dict, but that was wrong because dictentry is only 1.5 times larger than setentry because of the cached hash and depending on the size of the internet strings, large portion of the memory will be used by the string object themselves and that will not change with the patch. My primary reason is the simplicity (you can call it maintainability). I find the off by two reference count in the current dict based implementation rather unnatural and I think the dict that maps keys to themselves is a set. I disagree with Martin. I think interning is a set operation and it is unfortunate that set API does not support it directly. I guess the current view is that set is not a container. Although you can put things in a set and check if they are there, there is no API to get the things back. I would really like to see set C API to provide all the functionality of a dict with value=key, but it is also possible that I complitely misunderstood the need of the set object in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-30 18:01 Message: Logged In: YES user_id=21627 Ok, memory reduction would be a valid reason. How much memory is being preserved (say, for an empty program, or for an IDLE run)? I don't see the improved maintainability. Interning is inherently *not* a set operation, it's a dictionary operation: You are given a string, and need to return its interned version. That's a table lookup. In fact, the set API had to be changed (to add _PySet_InternString) to add a lookup operation. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-06-30 08:27 Message: Logged In: YES user_id=2042 The author said that the patch is expected to reduce memory. If this is true, then the patch has a good reason to be applied. Another reason is maintainability. By removing the set like functionality which is already implemented in the setobject. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-17 08:44 Message: Logged In: YES user_id=21627 I don't think "it's natural to do it" is a convincing object reason to change a running system. A change should address correctness, efficiency, maintainability, functionality (features), legal issues, etc. I can't see any of this in this patch, so I'm -1. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-17 02:52 Message: Logged In: YES user_id=835142 Rationale: The container of interned strings logically a set. Current implementation that uses a dictionary with the same keys and values is clearly an artificial implementation of a set necessary in earlier versions of Python. With a proper C implementation of sets available, it is natural to use it to store interned strings. Since set and dict objects use the same lookup algorithm, this patch is not expected to affect performance and pybench does not show any difference. Since a large set is using half of the memory of the equivalent dict, this patch is expected to reduce interpretor memory usage. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-16 23:55 Message: Logged In: YES user_id=21627 I did not read the python-dev discussion before writing my first comment, so it is fine that you posted the patch here. Still, I think some rationale should be provided for doing this: what is the advantage? ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 14:48 Message: Logged In: YES user_id=835142 The purporse was to allow others to comment on the work in progress. Would it be more appropriate to post it on python-dev instead? If I close a patch while it is not ready, can I reopen it later when it is complete? In any case, please consider interned-set-1.patch for inclusion in Python. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-16 07:12 Message: Logged In: YES user_id=21627 What is the purpose of posting the patch here, then? The Python patches tracker should only carry patches that are meant for inclusion in Python. If inclusion is not planned, it should be closed (it would still be available, then). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-16 05:44 Message: Logged In: YES user_id=835142 Fixed code comments and moved all interning logic to setobject.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1507011&group_id=5470 From noreply at sourceforge.net Mon Mar 5 13:42:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 04:42:42 -0800 Subject: [Patches] [ python-Patches-1442867 ] Add support for the If-Modified-Since header Message-ID: Patches item #1442867, was opened at 2006-03-04 03:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442867&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for the If-Modified-Since header Initial Comment: Added support for the If-Modified-Since header to SimpleHTTPServer. That way things like images don't get downloaded again on every new page request. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 13:42 Message: Logged In: YES user_id=21627 Originator: NO Closing this report because lack of response. If you are still interested in contributing it, please resubmit it (referring to this prior submission) and address my questions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 18:24 Message: Logged In: YES user_id=21627 What is the reason for raising ValueError, instead of returning True right away? Please re-read section 14.25 of the RFC: a if-modified-since date "from the future" must be considered invalid. Also, there seems to be some interaction with the Range: header. How is that dealt with? Also, where is the length attribute to if-modified-since specified? Also, should there be changed to Doc/lib/libsimplehttp.tex? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1442867&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:13:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:13:06 -0800 Subject: [Patches] [ python-Patches-1368247 ] unicode in email.MIMEText and email/Charset.py Message-ID: Patches item #1368247, was opened at 2005-11-28 15:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Damjan Georgievski (gdamjan) Assigned to: Barry A. Warsaw (bwarsaw) Summary: unicode in email.MIMEText and email/Charset.py Initial Comment: This is the test case that fails in python 2.4.1: from email.MIMEText import MIMEText msg = MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430') msg.set_charset('utf-8') msg.as_string() And attached is a patch to correct it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:13 Message: Logged In: YES user_id=21627 Originator: NO Your proposed patch doesn't seem to work in Python 2.5, or the trunk (i.e. it won't prevent an exception from occuring). Can you please revise it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368247&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:15:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:15:12 -0800 Subject: [Patches] [ python-Patches-1443875 ] email/charset.py convert() patch Message-ID: Patches item #1443875, was opened at 2006-03-06 05:41 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/charset.py convert() patch Initial Comment: email/charset.py has convert() function to incorporate using different charset for input and output for a language like Japanese. Because the email user agent in Japan frequently use characters outside the range of legitimate JIS charset, these messages are shunted in mailman delivery. Here is a patch to handle this case by replacing the characters by '?' using the 'errors' parameter in unicode/encode functions. This patch includes the unicode string conversion patch in #1368247. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:15 Message: Logged In: YES user_id=21627 Originator: NO I'm -1 on this patch as-is. It changes the default error handling behavior from 'strict' to 'replace', for this method. This is a choice that the caller of these methods should make, so I think the default value for the error handling should be 'strict'. If then it is meaningful in mailman to set this to 'replace', this is mailman's choice. Python should never, on its own, create moji-bake. If you revise this patch, please provide the test case as a patch to Lib/email/test somehow (probably patching both test_email and test_email_renamed). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2006-03-14 00:35 Message: Logged In: YES user_id=67709 Thanks! Here is an example program which fails on 4.0a without the patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-12 14:09 Message: Logged In: YES user_id=12800 Do you have a test case for this? #1368247 includes one just for the encoding of unicode strings, but not for the error argument. If you can include a simple test case, then I'll add this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:16:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:16:25 -0800 Subject: [Patches] [ python-Patches-1444529 ] kwdargs for compile/__import__ Message-ID: Patches item #1444529, was opened at 2006-03-07 01:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: kwdargs for compile/__import__ Initial Comment: Keyword arguments for compile() and __import__(), as discussed at PyCon. There is a slight speed difference on my development system: __import__ is ~1% slower, compile() is ~1.5% faster. I blame both on caches, alignment and what not, so I bet they're totally different for everyone. I'd say the advantage of managing the growing set of arguments outweighs the speed impact (if any.) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:16 Message: Logged In: YES user_id=21627 Originator: NO Is anybody still working on this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-07 06:22 Message: Logged In: YES user_id=33168 These look good to me. Thanks Thomas. I had started a patch for import. BTW I think the new __import__ needs to be documented in libfuncs.txt or somewhere like that. If you don't get to it, I'll find my change and update the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:17:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:17:54 -0800 Subject: [Patches] [ python-Patches-1449244 ] email.message.py charset can be unicode instance Message-ID: Patches item #1449244, was opened at 2006-03-14 00:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.message.py charset can be unicode instance Initial Comment: *_charset in Charset become unicode instance in email-4.0a. message.py should add this for type test. --- email-4.0a2/email/message.py Mon Mar 6 04:58:33 2006 +++ email/message.py Mon Mar 6 14:59:04 2006 @@ -238,7 +238,7 @@ self.del_param('charset') self._charset = None return - if isinstance(charset, str): + if isinstance(charset, str) or isinstance(charset, unicode): charset = email.charset.Charset(charset) if not isinstance(charset, email.charset.Charset): raise TypeError(charset) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:17 Message: Logged In: YES user_id=21627 Originator: NO Can you please include a test case for this, as a patch to the current test suite, using the unittest framework? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:24:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:24:22 -0800 Subject: [Patches] [ python-Patches-1449471 ] Splitting CJK codecs from pythoncore dll Message-ID: Patches item #1449471, was opened at 2006-03-14 11:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open >Resolution: Out of Date Priority: 5 Private: No Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: Splitting CJK codecs from pythoncore dll Initial Comment: As many of western language natives have requested it, this patch splits CJK codecs from pythoncore dll. python25.dll shrinks from 2024KB to 1364KB by this. Even some of CJK users would take some advantages for domestic py2exe-ed releases. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:24 Message: Logged In: YES user_id=21627 Originator: NO The patch doesn't apply cleanly anymore, so I'm marking it out-of-date now. If it hasn't been committed 6 months from now, I think it should be closed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-30 11:22 Message: Logged In: YES user_id=21627 See my message from 2006-03-19 11:00. It's accepted, and perky could check it in if he wanted to. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 10:33 Message: Logged In: YES user_id=849994 What's the status of this? It's marked as Accepted, but not checked in. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-20 21:53 Message: Logged In: YES user_id=21627 I personally think the codec from the Marsians is more important to be part of the core than _hotshot module. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-20 12:24 Message: Logged In: YES user_id=972995 good decision. otherwise, once we learn the codecs of Marsians, they would have probably gone into the core as well :-) ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 14:22 Message: Logged In: YES user_id=55188 Aah. Then, how about to use a way how the PuTTY project does? They maintain a relatively simple perl script to generate various types of build files including MSVC6 dsw, MSVC7.1 sln, Dev-Cpp project, MinGW Makefile, MS nmake Makefile and Borland C++ project file at a time. If we make a simliar thing, keeping PC/VC6 up-to-date would become a bit easy. I'll try it in my spare time before the first alpha of 2.5. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-19 12:56 Message: Logged In: YES user_id=21627 The main issue is maintainability. Everytime a module is added, a project file needs to be created, which is more tedious than adding a few lines to setup.py (although one also has to remember editing Modules/Setup.dist); in addition, Tools/msi/msi.py needs to be edited. Everytime a "global" change is made to the compilation options of Python (e.g. adding AMD64 configurations), it needs to be applied to all project files individually. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-03-19 11:20 Message: Logged In: YES user_id=55188 Yes. I agree about the arbitrariness where to modules go. I thought that some dll size was concerned looking "unicodedata" module case; which is only 396KB. It would be clearer if we use same scheme for Windows distribution as specified in Modules/Setup.dist. (what drawbacks are expected then?) Thank you for the review! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-19 11:00 Message: Logged In: YES user_id=21627 I must say that I find this splitting arbitrary. Why are these modules moved out of pythonxy.dll, when, say, multibytecodec, mmap, parser, xxsubtype, sha512 stay. I really wish there was some policy guiding this. That said, as the author of the code, it is certainly your decision to make that split that way. So please go ahead and apply that patch. Please also add the new modules to Tool/msi/msi.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449471&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:27:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:27:30 -0800 Subject: [Patches] [ python-Patches-1452906 ] N-d array interface for array object Message-ID: Patches item #1452906, was opened at 2006-03-18 02:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: N-d array interface for array object Initial Comment: This patch implements the "required" methods of N-d array interface. See http://numeric.scipy.org/array_interface.html . ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:27 Message: Logged In: YES user_id=21627 Originator: NO The link is out of date. Can you please report an updated link? Is there still interest in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:36:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:36:49 -0800 Subject: [Patches] [ python-Patches-1177779 ] explicit sign variable for longs Message-ID: Patches item #1177779, was opened at 2005-04-06 15:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: explicit sign variable for longs Initial Comment: This patch removes longobject.c abuse of ob_size to store the sign in favour of an explicit sign member, as mentioned on python-dev. The only other file that needed modifying is marshal.c (but the marshal format isn't changed). It doesn't touch all the various code that handles ob_size generically. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:36 Message: Logged In: YES user_id=21627 Originator: NO With Py3k using the long int type for all integers, do people still think this change is desirable? If so, is anybody interested in committing it? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-06-03 17:49 Message: Logged In: YES user_id=6656 New patch, which updates marshal.c appropriately. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-14 11:34 Message: Logged In: YES user_id=4771 Tim, I don't really have the motivation nor knowledge of the long implementation, so I can't review this patch any better than you did already. Unassigned from me. My general feeling is that mwh+tim+tests is quite safe already :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-11 11:38 Message: Logged In: YES user_id=4771 Sorry, I tested the memory overhead of adding an "int" field long_sign, and forgot that the digits were "short". (mwh, your patch #2 forgot to rename "sign" in marshal.c) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-11 01:44 Message: Logged In: YES user_id=6656 Good, I didn't really understand Armin's point either :) Here's a new version of the patch that pays a bit more attention to the comments (I changed my mind over a few details while writing it, I'm not entirely surprised that clarity suffered) and renames the sign member to long_sign -- but it turns out that you could find all references by searching for "->sign"... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-04-11 01:28 Message: Logged In: YES user_id=31435 Armin, I don't understand your use case. Can you be more explicit? Best I can guess, you're using Python longs on a 32-bit box to store positive integers with bit 2**31 set. But there's no change in memory burden for those (rounds up to 24 bytes either way), so that can't be what you mean. Maybe you're using Python longs to store _all_ integers, no matter how small they are? But in that case you weren't serious about memory use to begin with. Michael, I got confused at the start of the patch. When you changed the comment SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i) to sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i) you dropped the "-1" as well as the "abs()". That wasn't intended, was it? Was also confused by why you dropped the "zero is represented by ob_size == 0." comment. It would be very helpful to rename the new member, e.g., as "long_sign". Then it's easy to find references in the code with an editor search. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-04-08 16:20 Message: Logged In: YES user_id=4771 Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers. It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary. Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long. Damn. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-06 15:51 Message: Logged In: YES user_id=6656 Oh, and I meant to say, it passes make test but more testing is certainly welcome -- some mistakes show up in pretty obscure ways... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:38:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:38:25 -0800 Subject: [Patches] [ python-Patches-1154227 ] Fix for win32 proxy bypass support (no_proxy) in urllib(2) Message-ID: Patches item #1154227, was opened at 2005-03-01 14:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1154227&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: mullendr (mullendr) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for win32 proxy bypass support (no_proxy) in urllib(2) Initial Comment: urllib and urllib2 did not support the win32 no_proxy environment variable, nor did they support the proxyOverride windows registry setting. The files that are attached add support for these. ps. this is my first fix, so I hope I am doing this right ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:38 Message: Logged In: YES user_id=21627 Originator: NO I'm rejecting this because of lack of response. If you still like to contribute this change, please resubmit it as a new patch, addressing my remarks. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 10:34 Message: Logged In: YES user_id=21627 Please don't send the full files as a patch. Instead, use "diff" or (better) "cvs diff" to create a patch, see http://www.python.org/patches/ http://www.python.org/dev/devfaq.html#patches I notice that your patch contains no changes to Doc/lib/liburllib.tex; please add them as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1154227&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:40:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:40:01 -0800 Subject: [Patches] [ python-Patches-1452906 ] N-d array interface for array object Message-ID: Patches item #1452906, was opened at 2006-03-17 20:50 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: N-d array interface for array object Initial Comment: This patch implements the "required" methods of N-d array interface. See http://numeric.scipy.org/array_interface.html . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 08:40 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 08:27 Message: Logged In: YES user_id=21627 Originator: NO The link is out of date. Can you please report an updated link? Is there still interest in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:40:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:40:32 -0800 Subject: [Patches] [ python-Patches-1158926 ] Names conflict with QT (on linux) Message-ID: Patches item #1158926, was opened at 2005-03-08 11:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1158926&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: CyberRan (cyberran) Assigned to: Nobody/Anonymous (nobody) Summary: Names conflict with QT (on linux) Initial Comment: The patch fixes a problem when embedding python 2.4 (using static library) in an application that also link against qt 3.3 (using the qt-mt shared library). If an XML import is used in an application containning the QT library, a strange segmentation fault occoured. After reasearching this problem, I found out that there is a name conflict for a symbol exported by the QT library and the pyexpat module SO file. The symbol name is "XML_ErrorString". The cause for this problem is the fact that the symbol is not defined static in the pyexpat module (it is used in several different compilation units). The solution is to simply replace the "XML_ErrorString" symbol with "PyXML_ErrorString". Ran. ran.peleg at gmail.com ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:40 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. This was later resubmitted and applied as #1295808, so I believe the problem is fixed, and this patch out-of-date. ---------------------------------------------------------------------- Comment By: CyberRan (cyberran) Date: 2005-03-10 10:12 Message: Logged In: YES user_id=1229149 Here is a minimal test that shows the problem. I have tested this on two different systems (32Bit system running Fedore core 2 and on 64Bit system running Fedora core 3). You may have to change some paths in the "build.sh" file according to your system configuration. Ran. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-10 00:07 Message: Logged In: YES user_id=21627 Can you please post a small test case (C file + Makefile, e.g. for Linux, perhaps + Python file) demonstrating your problem? I still have a hard time believing your analysis of the problem, and believing that your proposed solution is correct. ---------------------------------------------------------------------- Comment By: CyberRan (cyberran) Date: 2005-03-09 10:13 Message: Logged In: YES user_id=1229149 The static library was the python library (libpython2.4.a) itself. After further investigating this problem I have found out that the qt-mt library is using the expat shared library (libexpat.so). The XML_ErrorString symbol name contention is between this library and the pyexpat.so module. Ran ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-08 13:19 Message: Logged In: YES user_id=21627 I can't understand why this happened. What precisely was a static library in your application, if both qt-mt and the expat extension where shared libraries? Also, why does qt-mt export XML_ErrorString? In my copy of qt-mt, it does not; instead, it links with expat.so.1. Unless you have modified something, the Python extension module should have been loaded with RTLD_LOCAL, which should have preferred its own definition of XML_ErrorString over the one in Qt. I'm hesitant to apply the patch, because: a) these are original Expat sources, not Python sources, and we prefer to use them unmodified (or else a future import of expat will just undo this change), b) renaming a single function does no good - if the problem can occur with this function, it can occur with any other function, c) even in your application, I wonder why renaming XML_ErrorString solved the problem. If you really somehow got an entire copy of Expat into your qt-mt, and if you really somehow managed to make pyexpat find parts of Expat in qt-mt, this problem should have occurred with any other of the qt symbols as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1158926&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:45:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:45:32 -0800 Subject: [Patches] [ python-Patches-1452906 ] N-d array interface for array object Message-ID: Patches item #1452906, was opened at 2006-03-17 20:50 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: N-d array interface for array object Initial Comment: This patch implements the "required" methods of N-d array interface. See http://numeric.scipy.org/array_interface.html . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 08:45 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 08:40 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 08:27 Message: Logged In: YES user_id=21627 Originator: NO The link is out of date. Can you please report an updated link? Is there still interest in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:47:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:47:32 -0800 Subject: [Patches] [ python-Patches-1452906 ] N-d array interface for array object Message-ID: Patches item #1452906, was opened at 2006-03-17 20:50 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: N-d array interface for array object Initial Comment: This patch implements the "required" methods of N-d array interface. See http://numeric.scipy.org/array_interface.html . ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 08:47 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 08:45 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 08:40 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 08:27 Message: Logged In: YES user_id=21627 Originator: NO The link is out of date. Can you please report an updated link? Is there still interest in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 From noreply at sourceforge.net Mon Mar 5 14:58:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 05:58:46 -0800 Subject: [Patches] [ python-Patches-1452906 ] N-d array interface for array object Message-ID: Patches item #1452906, was opened at 2006-03-18 02:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: N-d array interface for array object Initial Comment: This patch implements the "required" methods of N-d array interface. See http://numeric.scipy.org/array_interface.html . ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:58 Message: Logged In: YES user_id=21627 Originator: NO So who is pursuing this? Is anybody submitting the PEPs to the Python process? or for BDFL pronouncement? This patch certainly does not match the PEP at all (which currently proposes to extend the buffer protocol), so I'm closing this report as out-of-date. Feel free to reopen it if the PEP ever returns to specify what this patch implements; if you want to update the implementation to match the PEP, please submit a new patch. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 14:47 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 14:45 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 14:40 Message: Logged In: YES user_id=835142 Originator: YES The array interface PEP is now at http://scipy.org/ArrayInterfacePEP . This patch is probably not up to date. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:27 Message: Logged In: YES user_id=21627 Originator: NO The link is out of date. Can you please report an updated link? Is there still interest in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1452906&group_id=5470 From noreply at sourceforge.net Mon Mar 5 15:11:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 06:11:41 -0800 Subject: [Patches] [ python-Patches-677103 ] PYTHONBYTECODEBASE patch (PEP 304) Message-ID: Patches item #677103, was opened at 2003-01-29 23:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: PYTHONBYTECODEBASE patch (PEP 304) Initial Comment: This is just a placeholder patch related to PEP 304. Feel free to comment on it. It's far from complete at this point. The first patch is just to see if we can do all the proper detection at startup. These checks have to be performed before any .py files are imported, otherwise you'd have some .pyc files dumped out before the machinery is ready to go. The first patch contains mods to sysmodule.c with next to no concern for platform independence. There is a small shell script and a few expected output files which are used to test setting of various values. These should probably be wrapped into regular PyUnit tests which popen() the interpreter with different settings, but this seemed quicker as a start. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 15:11 Message: Logged In: YES user_id=21627 Originator: NO As the PEP was withdrawn, also, I'm closing this patch as rejected. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-16 17:15 Message: Logged In: YES user_id=44345 I sorta lost interest (it was never really anything I needed anyway) when the Windows problems were raised, especially after nobody suggested fixes. If you'd like to update the patch and perhaps champion it, be my guest. Skip ---------------------------------------------------------------------- Comment By: Steven Knight (stevenknight) Date: 2005-12-16 16:15 Message: Logged In: YES user_id=216109 Skip-- Is there any interest in this patch getting accepted into core Python? Are there any other known barriers apart from the Windows issues? If this would likely be accepted once the Windows issues are worked out, I might be able to spend some time looking at the Windows side. --SK ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-06-17 03:26 Message: Logged In: YES user_id=44345 Update patch for current CVS (2.5a0)... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-15 00:12 Message: Logged In: YES user_id=44345 *sigh* - let's try again... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-11-14 23:48 Message: Logged In: YES user_id=44345 Patch updated for current CVS (~ 2.4b2). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 18:37 Message: Logged In: YES user_id=44345 Another patch. This one fixes the problems of the one I withdrew yesterday. There are still problems: * A half dozen regression tests fail for various reasons which I haven't completely investigated. * Nothing has been done for Windows. Someone will have to step up to the plate for this. I can't build on Windows. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 23:51 Message: Logged In: YES user_id=44345 While not technically broken, the patch I just posted is a bit bent. Withdrawing for a little fixup... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-30 23:33 Message: Logged In: YES user_id=44345 Here's an updated context diff. It seems to do the right thing on my Mac OS X system. It won't currently do anything on Windows ( need help there). No more test cases, but if PYTHONBYTECODEBASE points to a valid directory, the .pyc files seem to get put in all the right places. To get the behavior, you'll have to configure --with-bytecodebase. Feedback, please... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-29 23:52 Message: Logged In: YES user_id=44345 second upload try - what the hell is with SF? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677103&group_id=5470 From noreply at sourceforge.net Mon Mar 5 15:24:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 06:24:30 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules to be built and not built Message-ID: Patches item #1673619, was opened at 2007-03-04 15:31 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Identify modules to be built and not built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 08:24 Message: Logged In: YES user_id=44345 Originator: YES Martin, Thanks for the feedback. Attached is an updated diff. It defers the report until build_ext is finished and reports only on what couldn't be built, either because the environment was missing something or because the compile/link phase failed. These two different problems are reported in different paragraphs, e.g.: Failed to find the necessary bits to build these modules: _md5 _sha _sha256 _sha512 gdbm linuxaudiodev ossaudiodev spwd sunaudiodev Failed to build these modules: _elementtree File Added: missing.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 03:18 Message: Logged In: YES user_id=21627 Originator: NO I don't think the modules that it builds successfully need to be printed - the build messages will tell, anyway. I'm not sure when it prints these things. IMO, they should be printed at the end of the build (i.e. after all modules have been built). It should also print out, in summary, modules that had been attempted to build, but where building failed for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Mon Mar 5 15:25:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 06:25:15 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules which couldn't be built Message-ID: Patches item #1673619, was opened at 2007-03-04 15:31 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) >Summary: Identify modules which couldn't be built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 08:25 Message: Logged In: YES user_id=44345 Originator: YES Tweak summary. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 08:24 Message: Logged In: YES user_id=44345 Originator: YES Martin, Thanks for the feedback. Attached is an updated diff. It defers the report until build_ext is finished and reports only on what couldn't be built, either because the environment was missing something or because the compile/link phase failed. These two different problems are reported in different paragraphs, e.g.: Failed to find the necessary bits to build these modules: _md5 _sha _sha256 _sha512 gdbm linuxaudiodev ossaudiodev spwd sunaudiodev Failed to build these modules: _elementtree File Added: missing.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 03:18 Message: Logged In: YES user_id=21627 Originator: NO I don't think the modules that it builds successfully need to be printed - the build messages will tell, anyway. I'm not sure when it prints these things. IMO, they should be printed at the end of the build (i.e. after all modules have been built). It should also print out, in summary, modules that had been attempted to build, but where building failed for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Mon Mar 5 18:20:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 09:20:00 -0800 Subject: [Patches] [ python-Patches-1674228 ] sq_ass_slice ignored if sq_slice not defined Message-ID: Patches item #1674228, was opened at 2007-03-05 18:20 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=1674228&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: sq_ass_slice ignored if sq_slice not defined Initial Comment: Function assign_slice in ceval.c is checking for the presence of type->tp_as_sequence->tp_slice method instead of type->tp_as_sequence->tp_ass_slice method. This means that simple slice assignment fails for classes that have a __setslice__ method, but are missing a __getslice__ method (see the test in the patch). The change shouldn't break any code that worked before, so I think that it can be safely backported. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1674228&group_id=5470 From noreply at sourceforge.net Mon Mar 5 18:22:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 09:22:26 -0800 Subject: [Patches] [ python-Patches-1674228 ] sq_ass_slice ignored if sq_slice not defined Message-ID: Patches item #1674228, was opened at 2007-03-05 18:20 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1674228&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: sq_ass_slice ignored if sq_slice not defined Initial Comment: Function assign_slice in ceval.c is checking for the presence of type->tp_as_sequence->tp_slice method instead of type->tp_as_sequence->tp_ass_slice method. This means that simple slice assignment fails for classes that have a __setslice__ method, but are missing a __getslice__ method (see the test in the patch). The change shouldn't break any code that worked before, so I think that it can be safely backported. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-05 18:22 Message: Logged In: YES user_id=1326842 Originator: YES File Added: assign_slice_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1674228&group_id=5470 From noreply at sourceforge.net Mon Mar 5 23:28:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 14:28:27 -0800 Subject: [Patches] [ python-Patches-1674228 ] sq_ass_slice ignored if sq_slice not defined Message-ID: Patches item #1674228, was opened at 2007-03-05 17:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1674228&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: sq_ass_slice ignored if sq_slice not defined Initial Comment: Function assign_slice in ceval.c is checking for the presence of type->tp_as_sequence->tp_slice method instead of type->tp_as_sequence->tp_ass_slice method. This means that simple slice assignment fails for classes that have a __setslice__ method, but are missing a __getslice__ method (see the test in the patch). The change shouldn't break any code that worked before, so I think that it can be safely backported. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-05 22:28 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54139, 54140 (2.5). ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-05 17:22 Message: Logged In: YES user_id=1326842 Originator: YES File Added: assign_slice_25.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1674228&group_id=5470 From noreply at sourceforge.net Tue Mar 6 01:11:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 16:11:49 -0800 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 17:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Tue Mar 6 01:16:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 16:16:33 -0800 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 10:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 13:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Tue Mar 6 01:18:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 16:18:49 -0800 Subject: [Patches] [ python-Patches-1654974 ] Binding annotations in tracebacks. Message-ID: Patches item #1654974, was opened at 2007-02-08 04:46 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Binding annotations in tracebacks. Initial Comment: The attached module provides a suitable replacement for sys.excepthook to handle uncaught exceptions. The output is the same, except after each source line shown, a list of relevant bindings is shown. Here's a quick example from the tail end of a test: File "./test-exprann.py", line 16, in f assert c == 12 # With bindings: # c = 42 AssertionError The bindings shown are the intersection of the code object "co_names" and the non-keyword name tokens in the parsed source line. The goal is to only show bindings relevant to the exception. I hope the utility of this is self-evident to any programmer. I tried testing it with crazy expressions containing nonfree bindings (such as lambda's and list comprehensions), so I think it behaves well in most circumstances. The performance might be bad (it parses each line in the backtrace), but I figure it is worth it for uncaught exceptions. Let me know if you find this tool useful. Thanks, Nejucomo ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:18 Message: Logged In: YES user_id=1344176 Originator: NO You should bring this up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). ---------------------------------------------------------------------- Comment By: Nefarious CodeMonkey, Jr. (nejucomo) Date: 2007-02-21 16:26 Message: Logged In: YES user_id=44911 Originator: YES This feature has already been present in the stdlib for awhile, hidden in the cgitb module. Enable it like this: import cgitb cgitb.enable(format="text") I was not aware of this, assuming cgitb just formatted typical tracebacks into html. Perhaps a better design of traceback reporting in general is called for? ---------------------------------------------------------------------- Comment By: Nefarious CodeMonkey, Jr. (nejucomo) Date: 2007-02-12 14:00 Message: Logged In: YES user_id=44911 Originator: YES I've simplified and modularized the design of this tool. Included is a patch against the 2.6 svn head which adds a module to the stdlib called bindann (for "binding annotation"), and then modifies the traceback module to use it. It also includes a demo script which compares classic and annotated exception tracebacks. The interface to traceback is backwards compatible (it introduces optional arguments defaulting to pre-patch behavior). bindann is much simpler than the previous annex file, because it doesn't try parsing, only tokenizing the source line, to look for name references. Thus it succeeds where annex would fail (for example if the head of a for-loop causes an uncaught exception, the source line will only be the head which is not a complete/parsable expression). Here's the output of the demo: $ ./Demo/newfeatures/demo-bindann.py This demonstrates binding-annoted exception tracebacks. Consider the following function: def f(c): for char in c + " hello": print 'The string contains "%s".' % (char,) -With standard tracebacks, calling f(42) gives: Traceback (most recent call last): File "./Demo/newfeatures/demo-bindann.py", line 17, in main f(42) File "./Demo/newfeatures/demo-bindann.py", line 28, in f for char in c + " hello": TypeError: unsupported operand type(s) for +: 'int' and 'str' -And now with annotated exceptions: Traceback (most recent call last): File "./Demo/newfeatures/demo-bindann.py", line 33, in # With bindings: # main = # Source: main() File "./Demo/newfeatures/demo-bindann.py", line 24, in main # With bindings: # f = # Source: f(42) File "./Demo/newfeatures/demo-bindann.py", line 28, in f # With bindings: c = 42 # char = # Source: for char in c + " hello": TypeError: unsupported operand type(s) for +: 'int' and 'str' File Added: bindann-patch.1 ---------------------------------------------------------------------- Comment By: Nefarious CodeMonkey, Jr. (nejucomo) Date: 2007-02-08 04:50 Message: Logged In: YES user_id=44911 Originator: YES BTW, I only tested this on python 2.4. Because it examines the parse tree (very simply), it may not work if the AST format changes. The only parsing it does is search for all NAME tokens which are not keywords, so I assumed this was stable across releases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654974&group_id=5470 From noreply at sourceforge.net Tue Mar 6 01:23:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 16:23:39 -0800 Subject: [Patches] [ python-Patches-1644818 ] Allow importing built-in submodules Message-ID: Patches item #1644818, was opened at 2007-01-25 17:12 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miguel Lobo (mlobo) Assigned to: Nobody/Anonymous (nobody) Summary: Allow importing built-in submodules Initial Comment: At the moment importing built-in submodules (in my case PyQt4.QtCore and PyQt4.QtGui) does not work. This seems to be because find_module in import.c checks only the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. Python.QtCore) instead. Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case. By moving the is_builtin() check to earlier in find_module and using fullname instead of name, I can build PyQt4.QtCore and PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen. I have run the regression tests and everything seems Ok. I am completely new to CPython development so it is quite possible that my solution is undesirable or that I have done something incorrectly. Please let me know if that is the case. Finally, the attached patch is for Python-2.5, but I have checked it also applies to current svn trunk with only a one-line offset. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:23 Message: Logged In: YES user_id=1344176 Originator: NO This is the kind of thing you should bring up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). Please subscribe to the list and send in a post with your problem and proposed solution. Thanks for your effort! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 From noreply at sourceforge.net Tue Mar 6 06:07:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 21:07:29 -0800 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 08:41 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-05 22:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 17:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 11:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Tue Mar 6 07:38:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 22:38:53 -0800 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 15:38 Message generated for change (Comment added) made by jyzude You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- >Comment By: Mike Verdone (jyzude) Date: 2007-03-05 23:38 Message: Logged In: YES user_id=584997 Originator: YES Hi collin, * I improved testMixIntsAndLongs. It now asserts things * assert is banished, replaced by the correct calls * the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect. * assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test. Let me know if you have further suggestions. File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 17:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Tue Mar 6 08:34:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 05 Mar 2007 23:34:16 -0800 Subject: [Patches] [ python-Patches-1668132 ] Fix for 767111, 'AttributeError thrown by urllib.open_http' Message-ID: Patches item #1668132, was opened at 2007-02-24 17:53 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668132&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Atul Varma (varmaa) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 767111, 'AttributeError thrown by urllib.open_http' Initial Comment: This is a fix for bug 767111: http://sourceforge.net/tracker/index.php?func=detail&aid=767111&group_id=5470&atid=105470 I am also attaching a unit test that reliably reproduces the bug using an in-process web server. I didn't want to modify httplib because it would mean altering its interface such that the HTTP.getfile() method would never return None, and that could break existing code. So instead I modified urllib at a point that it appears to assume that HTTP.getfile() will always return a file object. I hope this is a reasonable place to fix the problem, and I don't think it can break any existing code. I also ran the existing "test/test_urllib.py" and "test/test_urllibnet.py" test suites and they both work fine with this patch. Looking at the code, I also believe that a "parallel bug" exists with urllib.open_https(), and I fixed that as well (though I don't have a unit test to prove this). ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-06 00:34 Message: Logged In: YES user_id=1727609 Originator: NO Hi Atul, I took a quick look at your patch and verified that the test case produces an AttributeError on trunk. After manually patching urllib.py the test case passes. A few observations: 1. Your patch changes the code from giving an AttributeError to giving an empty file back when the remote webserver gives a bad http status line. The official Python documentation says that urlopen either generates an IOError when it can't connect to the server, or returns a file-like object when all goes well. In this case all didn't go well, so the documentation is incomplete. Would it be more appropriate to raise an exception rather than return an empty file? 2. I believe your test file will not work on systems without networking support. Other Python tests that require networking support have this at the top of them: test_support.requires('network') See Lib/test/test_socketserver.py for example. 3. Consider merging your test into Lib/test/test_urllib.py and supplying a patch against that file. 4. Could the test be performed without actually getting a network connection? Some of the tests in test_urllib.py use a FakeSocket class that might also work for your test. 5. Whitespace police - foo(arg1) instead of foo( arg1 ). See PEP 8 at http://www.python.org/dev/peps/pep-0008/ Other than that, things look good. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-24 17:56 Message: Logged In: YES user_id=863202 Originator: YES File Added: UrllibBug767111Tester.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668132&group_id=5470 From noreply at sourceforge.net Tue Mar 6 10:59:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 01:59:31 -0800 Subject: [Patches] [ python-Patches-1657573 ] Add syntax for dynamic attribute access Message-ID: Patches item #1657573, was opened at 2007-02-11 23:00 Message generated for change (Comment added) made by bennorth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1657573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Ben North (bennorth) Assigned to: Nobody/Anonymous (nobody) Summary: Add syntax for dynamic attribute access Initial Comment: Add syntax to allow easier access to attributes when attribute name known only at run-time. E.g., replace setattr(obj, attr_name, getattr(obj, attr_name) + 1) with obj.(attr_name) += 1 For further discussion, see PEP 363 [PROVISIONAL NUMBER] ---------------------------------------------------------------------- >Comment By: Ben North (bennorth) Date: 2007-03-06 09:59 Message: Logged In: YES user_id=1716711 Originator: YES PEP rejected; closing patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1657573&group_id=5470 From noreply at sourceforge.net Tue Mar 6 11:03:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 02:03:14 -0800 Subject: [Patches] [ python-Patches-1671450 ] Extension documentation for subclasses Message-ID: Patches item #1671450, was opened at 2007-03-01 06:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Pete Shinners (shredwheat) Assigned to: Nobody/Anonymous (nobody) Summary: Extension documentation for subclasses Initial Comment: This adds a new section to the extension documentation for building new types. It documents building a new extension type that inherits from the builtin list type. I haven't been able to get latex2html working on my cygwin setup. The formatting is fairly simple though, so I don't expect it will give much trouble? Willing to accept more feedback on this. I figured since I semi-harangued this state of affairs during my Pycon presentation, it was my duty to do something about it during the following sprints. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 10:03 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed a revised version as rev. 54150, 54151 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671450&group_id=5470 From noreply at sourceforge.net Tue Mar 6 11:15:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 02:15:44 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules which couldn't be built Message-ID: Patches item #1673619, was opened at 2007-03-04 22:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Identify modules which couldn't be built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 11:15 Message: Logged In: YES user_id=21627 Originator: NO Some nits: - the max computation can be simplified as longest = max(len(e.name) for e in self.extensions+self.failed) - The sort can be simplified as lst.sort(key=str.lower) There is a change to xmlrpclib in this patch that probably isn't meant to be part of it. Otherwise, it looks fine, please apply. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 15:25 Message: Logged In: YES user_id=44345 Originator: YES Tweak summary. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 15:24 Message: Logged In: YES user_id=44345 Originator: YES Martin, Thanks for the feedback. Attached is an updated diff. It defers the report until build_ext is finished and reports only on what couldn't be built, either because the environment was missing something or because the compile/link phase failed. These two different problems are reported in different paragraphs, e.g.: Failed to find the necessary bits to build these modules: _md5 _sha _sha256 _sha512 gdbm linuxaudiodev ossaudiodev spwd sunaudiodev Failed to build these modules: _elementtree File Added: missing.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 10:18 Message: Logged In: YES user_id=21627 Originator: NO I don't think the modules that it builds successfully need to be printed - the build messages will tell, anyway. I'm not sure when it prints these things. IMO, they should be printed at the end of the build (i.e. after all modules have been built). It should also print out, in summary, modules that had been attempted to build, but where building failed for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Tue Mar 6 11:16:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 02:16:48 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules which couldn't be built Message-ID: Patches item #1673619, was opened at 2007-03-04 22:31 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: Identify modules which couldn't be built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 11:15 Message: Logged In: YES user_id=21627 Originator: NO Some nits: - the max computation can be simplified as longest = max(len(e.name) for e in self.extensions+self.failed) - The sort can be simplified as lst.sort(key=str.lower) There is a change to xmlrpclib in this patch that probably isn't meant to be part of it. Otherwise, it looks fine, please apply. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 15:25 Message: Logged In: YES user_id=44345 Originator: YES Tweak summary. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 15:24 Message: Logged In: YES user_id=44345 Originator: YES Martin, Thanks for the feedback. Attached is an updated diff. It defers the report until build_ext is finished and reports only on what couldn't be built, either because the environment was missing something or because the compile/link phase failed. These two different problems are reported in different paragraphs, e.g.: Failed to find the necessary bits to build these modules: _md5 _sha _sha256 _sha512 gdbm linuxaudiodev ossaudiodev spwd sunaudiodev Failed to build these modules: _elementtree File Added: missing.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 10:18 Message: Logged In: YES user_id=21627 Originator: NO I don't think the modules that it builds successfully need to be printed - the build messages will tell, anyway. I'm not sure when it prints these things. IMO, they should be printed at the end of the build (i.e. after all modules have been built). It should also print out, in summary, modules that had been attempted to build, but where building failed for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Tue Mar 6 11:49:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 02:49:36 -0800 Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only file-like obj for files in archive Message-ID: Patches item #1121142, was opened at 2005-02-12 01:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.open - read-only file-like obj for files in archive Initial Comment: I originally started working on updating patch 992750, but decided after a short while to just start from scratch, so I'm posting it as a new patch. Sorry if this isn't appropriate. This patch provides a new open() method on ZipFile; this method returns a file-like object for the requested item in the archive. This file-like object only provides a read() method. ZipFile.read was modified to use the new open method (this was suggested by loewis in reference to patch 992750). The patched zipfile.py passed the existing tests in the test_zipfile.py from CVS. New tests were added to verify the operation of the object returned by open(). These tests were modeled after existing tests for ZipFile.read(); two read fixed-size chunks from the file-like object, and two others read random-sized chunks. I have only run the tests on Windows XP, using Python2.4 from the official Windows installer. I will test the patch out on Linux over the weekend. If the patch is accepted I'll also generate and submit patches for the appropriate documentation as well. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 11:49 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54152. If you want to produce further changes, please submit them as new patches against the subversion trunk. Two remarks: - I recall discussion of adding an extract method. Are you still interested in this? - The previous version required that the mode is 'r' or 'a' to invoke .read(), and raised a RuntimeError in this case. Your version doesn't (but instead raises KeyError if the archive member to be read wasn't written yet). Was this change deliberate? ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-28 01:29 Message: Logged In: YES user_id=1115903 Originator: YES This version of the patch includes the updates to the documentation. It passes regression tests as well as the test_zipfile64 tests on my Gentoo laptop. File Added: zipfile_patch7.tgz ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-18 19:41 Message: Logged In: YES user_id=1115903 Originator: YES Here is a version of the patch against the current trunk. It passes a "make test" on my Gentoo laptop at the moment, but I think I still need to add some more tests (like reading from encrypted compressed files), and I need to try out the test_zipfile64 stuff. I don't have time today to look through the module Glyph suggested, so it may be that after I do that I'll have some more tweaks to make. I'm pretty sure I'll be able to spend some more time on Wednesday this week. I also included the full contents of zipfile.py and test_zipfile.py just in case that's useful to somebody. File Added: zipfile_patch6.tgz ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-18 17:44 Message: Logged In: YES user_id=1115903 Originator: YES Thanks, glyph; I'll definitely have a look and see what I can steal. :-) ---------------------------------------------------------------------- Comment By: Glyph Lefkowitz (glyf) Date: 2007-02-17 04:48 Message: Logged In: YES user_id=226807 Originator: NO Twisted also contains an implementation of this functionality, available from http://twistedmatrix.com/trac/browser/trunk/twisted/python/zipstream.py As far as I can tell it doesn't have anything to recommend it over the attached patch, however (in fact, the test coverage of the attached patch looks better), but perhaps it has some behavior which might be desirable to steal. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-14 18:13 Message: Logged In: YES user_id=1115903 Originator: YES I will see if I can make some progress on this over the weekend. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-13 10:14 Message: Logged In: YES user_id=21627 Originator: NO Can you please update the patch to the current subversion trunk? I'd like to apply it, but the code of zipfile has changed so that the patch is currently out-of-date. When redoing it, notice that the read implementation has changed (I couldn't figure out how you moved code around). Please do use the trunk (not Python 2.5), and please submit the patch as a single 'svn diff' output (rather than a tar file containing multiple individual diff files). ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-05-31 04:56 Message: Logged In: YES user_id=1115903 Revision 5 of this patch has been in constant use with Python 2.4.1 in an application at my job for about a month; it seems to be stable and useful in that regard. If anybody has time to review and accept (or reject) it I would appreciate it. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-04-27 04:23 Message: Logged In: YES user_id=1115903 After testing on my large batch of large Zip files, I made one fix (version 4 of the patch didn't read all the content of large compressed archive items). The current set of changes is attached as zipfile_patch5.tgz. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-04-13 18:34 Message: Logged In: YES user_id=1115903 I found a problem with my universal newline handling code in readline(); if the first byte of an '\r\n' pair was read from file but the second byte didn't come in on that same read, it resulted in the next line having an inappropriate '\n' prepended to it. zipfile_patch4.tgz has a fix for this included (with everything else, of course). I'm going to test the open() capability in a real application with some reasonably large zip files (containing files up to just short of 2GB) over the next few days, so if any bugs or performance problems show up I may have some more changes. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-04-13 07:58 Message: Logged In: YES user_id=1115903 Uploaded the third revision of this patch; passes all regression tests against current CVS on WinXP. I think all the issues Martin brought up have been addressed except perhaps for the case of compression rate <1. I will have a look at that when I have time; just wanted to get an update here before the patch started to look abandoned. :) ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-03-14 15:37 Message: Logged In: YES user_id=1115903 Hmm...I could have sworn I did the diff in the correct order. I'll make sure next time. :) Here's my comments on your remarks (in order): - I'm adding support for universal newlines, and will reject all modes that aren't legal combinations of r, U, and b. - I'll see if I can make a Zip file store something with compression < 1, and if I can I'll add a test case for it. - I'll try work a .flush() in there on the compression object and come up with a test case if possible - .read(0) and .readline(0) will both return an empty string with no side-effects, since this seems to be what builtin files do. Right now ZipExtFile uses the ZipFile's file object, so you pretty much have to do whatever you're going to do with the ZipExtFile instance you get back from .open() before you use that ZipFile instance in a way that moves the file pointer around. I'm sure that somebody will eventually try to use the ZipFile in this way, so it appears my options are either to (1) give the ZipExtFile its own file object to use (when possible), or (2) make sure this limitation is documented. #1 feels (to me) to be the "right thing" to do, so that's what I'll try unless there's a good reason I shouldn't. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 08:59 Message: Logged In: YES user_id=21627 The patch is reversed: usually, diff is invoked as "-c old new". I think it is almost right, but I have a few remarks: - by tradition, open() should have a mode argument, defaulting to 'r'; it would be ok to raise exceptions if it is anything else. However, do consider implementing universal newlines; allowing 'b' as a no-op might also be reasonable. - I wonder what happens if the compression rate is < 1. It would appear that the code might use too few rawbytes. I suggest to recursively invoke read in this case. - I wonder whether it could ever happen that there is still data to uncompress in the zlib object, ie. whether it might be necessary to invoke .flush() after exhausting the rawbytes (and discard the zlib object afterwards) - it appears that atleast the builtin file object implements .read(0) as returning an empty string; the manual says that the entire file is meant only if size is omitted or negative. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-02-27 07:28 Message: Logged In: YES user_id=1115903 zipfile_patch2.tgz: I updated the file-like object to support readline, readlines, __iter__ and next(). Added tests for those new methods. Also added a patch for the documentation. Passes regression tests on 2.5a0 built from CVS HEAD with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 From noreply at sourceforge.net Tue Mar 6 12:10:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 03:10:02 -0800 Subject: [Patches] [ python-Patches-1673759 ] 'G' formatting doesn't catch same errors as 'g' Message-ID: Patches item #1673759, was opened at 2007-03-04 21:45 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'G' formatting doesn't catch same errors as 'g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Tue Mar 6 12:52:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 03:52:44 -0800 Subject: [Patches] [ python-Patches-1672481 ] MultiCall bug crashing the config dialog Message-ID: Patches item #1672481, was opened at 2007-03-02 15:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1672481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: MultiCall bug crashing the config dialog Initial Comment: Simple patch to MultiCall which stops IDLE's config dialog from crashing upon OK/Apply. The bug is caused by ConfigDialog calling event_add() for key bindings only if there are sequences to be bound, while event_delete() is called even if there are no sequences. This causes MultiCall's internal dictionary of virtual events to raise a KeyError when event_delete() is called with a virtual event, for which event_add() was not called. The Best Thing IMO is to have MultiCall check if such an event exists in its internal dict, and if not - just ignore the event_delete() call. Patch attached. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 11:52 Message: Logged In: YES user_id=849994 Originator: NO Committed in rev. 54156, 54157 (2.5). ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2007-03-03 18:17 Message: Logged In: YES user_id=1330769 Originator: YES Just to be clear - the bug is that writing certain things in the extension config file (either the user file or the defaults file) causes IDLE's configuration handling mechanism to crash. One symptom is that IDLE's config dialog doesn't save or apply changes, and is therefore useless. The bug occurs when a config option without a value is added under a *_bindings or *_cfgBindings section in the extensions config file. This bug is a result of an assumption in the design of MultiCall which is not true in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1672481&group_id=5470 From noreply at sourceforge.net Tue Mar 6 13:29:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 04:29:04 -0800 Subject: [Patches] [ python-Patches-1454452 ] 2 Tools for easy inter-thread communication->Queue, threading Message-ID: Patches item #1454452, was opened at 2006-03-20 12:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Raymond Hettinger (rhettinger) Summary: 2 Tools for easy inter-thread communication->Queue,threading Initial Comment: Using bare Queue.Queue in an inter-process manner by passing data is often tedious low-level style and overkill and leads to non-cohesive style of coding. Also threading up to now doesn't support a simply framework for non-blocking call execution _with_ result/end - a frequent need in GUI programming and easy load balancing for jerky resources. The attachment contains 2 tools for that: CallQueue and BackgroundCall. I think they fit well into the standard Python (2.5) lib. The attachment is in the form of a standalone Python module and can be tested directly, the 2 things can be easily copied to the target modules Queue / threading. Robert PS: fast atomic list.append / list.pop(0) / obj.var=.. assumed ; commented out use of Queue.Queue ; threading/Queue should maybe last of all do paranoid locking after all other stuff in the lib does so, in case Python would really go towards CPU level memory/time atoms, what in my opinion would destroy a VHL language. In case, I missed something, Queue should be uncommented. of the bare list. (The tests in all my apps raised no problems - I used that like tools since years, just reshaped them a little for this posting) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 13:29 Message: Logged In: YES user_id=21627 Originator: NO Rejecting as suggested. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-03-29 21:50 Message: Logged In: YES user_id=341410 Place this in the Python cookbook over at activestate.com and/or release it as a standalone module. If it gets nontrivial community support, it may have a chance at Python standard library inclusion. As it stands, it likely has exactly one user (you), no documentation, no unittest test cases, and no chance of making it into the standard library. Suggested close of this patch. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-22 11:43 Message: Logged In: YES user_id=972995 ->attachment (new version and diff): an update which addes options for exception handling (which I needed recently) and resolves one bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1454452&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:02:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:02:21 -0800 Subject: [Patches] [ python-Patches-1159051 ] Handle corrupted gzip files with unexpected EOF Message-ID: Patches item #1159051, was opened at 2005-03-08 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: Handle corrupted gzip files with unexpected EOF Initial Comment: The GzipFile algorithm crashes when reading a corrupted .gz file (attached as t.gz) with a missing CRC checksum at the end. Tested with python2.3, python2.4 and CVS python on a Debian Linux system. $ python2.3 t.py Traceback (most recent call last): File "t.py", line 4, in ? print gzip.GzipFile('', 'rb', 9, fileobj).read() File "/usr/lib/python2.3/gzip.py", line 217, in read self._read(readsize) File "/usr/lib/python2.3/gzip.py", line 289, in _read self._read_eof() File "/usr/lib/python2.3/gzip.py", line 305, in _read_eof crc32 = read32(self.fileobj) File "/usr/lib/python2.3/gzip.py", line 40, in read32 return struct.unpack("Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 14:02 Message: Logged In: YES user_id=21627 Originator: NO I don't think it is right to treat this as EOF. I haven't fully understood the problem (can you explain the format error encountered: what is expected, what is sent instead?), however, I notice that gzip itself also complains about an "unexpected EOF" error, so I don't think we should silently decompress the file. Producing an exception indicating the proper problem and including the data received so far in it would be more appropriate. Also, can you provide an example file for the test suite that isn't copyrighted by somebody else? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159051&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:06:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:06:11 -0800 Subject: [Patches] [ python-Patches-1335812 ] Patch to implement PEP 351 Message-ID: Patches item #1335812, was opened at 2005-10-24 00:33 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335812&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to implement PEP 351 Initial Comment: PEP 351 proposes the freeze protocol. Here is a patch that implements the proposed builtin, as well as __freeze__() methods for lists and sets. Dictionaries are not yet implemented. Unit tests and documentation are also necessary. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 14:06 Message: Logged In: YES user_id=1326842 Originator: NO Can this patch be closed? The PEP was rejected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335812&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:13:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:13:11 -0800 Subject: [Patches] [ python-Patches-1235943 ] PEP 343 implementation Message-ID: Patches item #1235943, was opened at 2005-07-11 12:09 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1235943&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 343 implementation Initial Comment: This large patch (nearly 90 K, affecting 25 files!) implements PEP 343. Work done: Changes Grammar/Grammar, Python/compile.c and Python/ceval.c to support new statement (a new opcode, LOAD_EXIT_ARGS, is possibly not strictly needed, but the stack yoga to avoid it would be very tiring). Implements a new __future__ statement, "with_statement", by cribbing the '#if 0'ed out code from when generators were optional. Implements support for the with statement in Lib/compiler (but Lib/ compiler doesn't support future statements at all?). Updates Lib/opcode.py, Lib/symbol.py. Updates the parser module and it's tests. Lib/test/test_with.py contains a couple of doctests, one a reasonably comprehensive tour of with statement functionality and the other is intended to contain the examples from the PEP, but most of these depend on PEP 342, the implementation of which hasn't been checked in yet. The code isn't the prettiest in places (esp search for the two XXXs). ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 14:13 Message: Logged In: YES user_id=1326842 Originator: NO Can this patch be closed? Is there still something missing in the current implementation of with statement? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-02 15:46 Message: Logged In: YES user_id=6656 Update post the checking in of PEP 342 stuff. There were a couple of small conflicts, and I added a lot more tests from the PEP (they used PEP 342 dependent generators). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1235943&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:21:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:21:26 -0800 Subject: [Patches] [ python-Patches-947386 ] Fix for #947380 - sys.path is wrong on windows sometimes Message-ID: Patches item #947386, was opened at 2004-05-04 02:56 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947386&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ori Berger (orib) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #947380 - sys.path is wrong on windows sometimes Initial Comment: Fixes http://python.org/sf/947380 - see details there. One line of code, one line of comment. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 14:21 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed in Python 2.5 with patch #1232023: http://www.python.org/sf/1232023 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 02:07 Message: Logged In: YES user_id=341410 See my comment in #947380 as to why this will go away in future versions of Python, without your patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947386&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:23:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:23:14 -0800 Subject: [Patches] [ python-Patches-1159139 ] cgi.py invalid REQUEST_METHOD set Message-ID: Patches item #1159139, was opened at 2005-03-08 17:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159139&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Pending >Resolution: Rejected Priority: 5 Private: No Submitted By: Joe (joesalmeri) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py invalid REQUEST_METHOD set Initial Comment: Python Version 2.4 OS Windows XP SP 2 + WindowsUpdates Patch for lastest CVS Tree When the environment does not have a correctly set REQUEST_METHOD cgi.py prompts for key=value pairs by reading from sys.stdin. After the values are read from sys.stdin they are never stored in the FieldStorage.list attribute like they are when the FieldStorage.read_urlencoded or FieldStorage.read_multi methods are called. This causes a problem when FieldStorage.keys() is called because although the values were read from sys.stdin they were never stored in FieldStorage.list. Although you could argue that REQUEST_METHOD should have been set correctly in the first place, it still seems like if cgi.py is going to handle that situation by actually reading the values from sys.stdin it should store them too. This fix stores the values read. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 14:23 Message: Logged In: YES user_id=21627 Originator: NO I must be completely missing the point of this patch. Where in the code does it currently prompt for key=value pairs if REQUEST_METHOD is not correctly set? By "not correctly set", do you mean "not set" or "set incorrectly"? If the latter, to what value? You seem to be modifying the read_single function. This is meant to read a single body of the CGI request (as sent by the HTTP client), not the key-value-pairs. I've tried to come up with a demo application of this new functionality, but failed: I couldn't make this new code do anything useful. What Python script should I use, how should I invoke it, what environment variables should I give, and what standard input? Tentatively rejecting the patch. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-03-14 23:54 Message: Logged In: YES user_id=764593 +1 on supporting use without a REQUEST_METHOD, if only to match Perl on "what happens if my .cgi was called straight from the command line"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159139&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:36:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:36:31 -0800 Subject: [Patches] [ python-Patches-1235943 ] PEP 343 implementation Message-ID: Patches item #1235943, was opened at 2005-07-11 10:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1235943&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 343 implementation Initial Comment: This large patch (nearly 90 K, affecting 25 files!) implements PEP 343. Work done: Changes Grammar/Grammar, Python/compile.c and Python/ceval.c to support new statement (a new opcode, LOAD_EXIT_ARGS, is possibly not strictly needed, but the stack yoga to avoid it would be very tiring). Implements a new __future__ statement, "with_statement", by cribbing the '#if 0'ed out code from when generators were optional. Implements support for the with statement in Lib/compiler (but Lib/ compiler doesn't support future statements at all?). Updates Lib/opcode.py, Lib/symbol.py. Updates the parser module and it's tests. Lib/test/test_with.py contains a couple of doctests, one a reasonably comprehensive tour of with statement functionality and the other is intended to contain the examples from the PEP, but most of these depend on PEP 342, the implementation of which hasn't been checked in yet. The code isn't the prettiest in places (esp search for the two XXXs). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:36 Message: Logged In: YES user_id=849994 Originator: NO I guess it can be closed. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 13:13 Message: Logged In: YES user_id=1326842 Originator: NO Can this patch be closed? Is there still something missing in the current implementation of with statement? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-08-02 13:46 Message: Logged In: YES user_id=6656 Update post the checking in of PEP 342 stuff. There were a couple of small conflicts, and I added a lot more tests from the PEP (they used PEP 342 dependent generators). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1235943&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:38:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:38:13 -0800 Subject: [Patches] [ python-Patches-1162363 ] Heap class for heapq module Message-ID: Patches item #1162363, was opened at 2005-03-13 11:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stefan Behnel (scoder) Assigned to: Raymond Hettinger (rhettinger) Summary: Heap class for heapq module Initial Comment: Bug 1158313 (requesting functions for heap iteration) was rejected, one of the reasons being that iteration does not fit well with the module design providing helper functions. Here is an implementation of a Heap class for that module that encapsulates a list. It supports iteration as well as the usual keyword arguments passed to sort() or sorted(): key, cmp, reversed. It further supports skipping the heapify step (heapify=True/False) when constructing the heap as well as copying the list if unnecessary (copy=True/False). The latter is generally discouraged and not the default. It is, however, useful for one-shot sequence generation as in >>> h = Heap([ random() for i in range(1000) ], copy=False) A further feature (somewhat obvious for heaps) is that iteration is not interrupted by items being pushed on the heap, they are simply integrated. "heapreplace" is supported by a "pushpop" function as initially proposed by R. Hettinger. It always returns the smallest item, also considering the one being pushed. This implementation is complementary to the existing functions that work on arbitrary (mutable) sequences. Both have their use cases and both make sense in the module. The Heap class has the additional advantage of encapsulating the list and thus allowing to support special item comparisons in a consistent way. There is not yet any documentation or unit tests, but they should be easy to write once the Heap class is actually considered for integration. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 14:38 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide patches to Doc/lib/libheapq.tex and Lib/test/test_heapq.py? Please also put doc strings into the class. Please drop the type assertions in __init__. I find it quite magical that it will silently turn copy on if the iterator doesn't support len or indexing. Why is iteration through the heap destructive? No other container has that feature. Putting the sanity checks into the module isn't necessary - just use the regular test suite for that. I can't comment further - lack of comments in the patch prevents me from actually understanding it. In the current form, I recommend rejection. Unassigning Raymond. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-03-14 14:14 Message: Logged In: YES user_id=313935 The things that pychecker doesn't tell you ... ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-03-14 13:18 Message: Logged In: YES user_id=313935 assigned to rhettinger ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-03-14 13:15 Message: Logged In: YES user_id=313935 The semantics of combining cmp and key are not specified in the Python documentation and my last implementation differed from the semantics of sort() and sorted() in that regard. The new patch fixes this and does some clean up. It also introduces a method iter_clone() that returns an independent iterator. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2005-03-13 12:00 Message: Logged In: YES user_id=313935 Forgot undecoration in __getitem__ method. Updated patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1162363&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:38:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:38:16 -0800 Subject: [Patches] [ python-Patches-1663234 ] enable "python -m doctest FILE" to run tests in FILE Message-ID: Patches item #1663234, was opened at 2007-02-19 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1663234&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: enable "python -m doctest FILE" to run tests in FILE Initial Comment: This is a small patch that lets doctest.py support being called via "python -m" in a more useful way. Currently, it only runs a selftest. With the patch applied, you can pass one or more filenames, which will let it process these instead. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 13:38 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, I extended it to allow testing modules and committed as 54164. ---------------------------------------------------------------------- Comment By: Stefan Behnel (scoder) Date: 2007-02-19 12:42 Message: Logged In: YES user_id=313935 Originator: YES fair enough File Added: libdoctest.tex-run-module.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-19 12:08 Message: Logged In: YES user_id=849994 Originator: NO Looks good and useful to me. A documentation patch would be needed though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1663234&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:48:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:48:50 -0800 Subject: [Patches] [ python-Patches-1163731 ] small sanity checks for user-defined mros Message-ID: Patches item #1163731, was opened at 2005-03-15 15:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1163731&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Michael Hudson (mwh) Assigned to: Anthony Baxter (anthonybaxter) Summary: small sanity checks for user-defined mros Initial Comment: I the course of looking at bug 1153075 (which is a nastier problem) I found a couple of sillies: no checking was done that a user defined mro() function returns a sequence or that said sequence contains types or classes. This patch fixes this, at least, and I'd like to get it into 2.4.1. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 14:48 Message: Logged In: YES user_id=21627 Originator: NO This was committed as r41845, as part of #1153075, AFAICT. mwh, if you think there are still changes pending, please resubmit. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-17 10:29 Message: Logged In: YES user_id=6656 You have appreciated that these are crash bugs? I think it's a little bit more than "useful argument checking". OTOH, essentially noone defines mro() functions so it's not that big a deal. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-16 21:30 Message: Logged In: YES user_id=80475 If I read it correctly, you're adding useful argument checking that is helpful when the user does something wrong. However, nothing is currently preventing them from using it correctly. Unless it is a critical fix, it should probably go on the head and ultimately into Py2.4.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-16 12:17 Message: Logged In: YES user_id=6656 Well, possibly I'm rushing unecessarily. OTOH "arguably not actually broken" is simply not true. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-16 12:13 Message: Logged In: YES user_id=80475 Are you sure to want to backport this directly to a release candidate without it having lived on the head for a while? Seems a little dangerous at this stage for something that is arguably not actually broken right now. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-15 15:21 Message: Logged In: YES user_id=6656 Argh, this is what I meant to upload. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1163731&group_id=5470 From noreply at sourceforge.net Tue Mar 6 14:53:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 05:53:02 -0800 Subject: [Patches] [ python-Patches-1618485 ] add None values in SimpleXMLRPCServer Message-ID: Patches item #1618485, was opened at 2006-12-19 01:01 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1618485&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maximiliano Curia (maxy) Assigned to: Nobody/Anonymous (nobody) Summary: add None values in SimpleXMLRPCServer Initial Comment: Using SimpleXMLRPCServer I've been having some problems when trying to use "None" values. Apparently it uses a "dumps" function from xmlrpclib to generate the response. This function does support "None" values, but needs an extra parameter to allow them. The patch attached adds a new parameter (allow_none) to the constructor of SimpleXMLRPCServer, that when set is passed to the xmlrpclib.dumps call. This fixes the problem in a consistent way with the usage of xmlrpclib. It might be a better solution to support "None" values by default in SimpleXMLRPCServer and xmlrpclib. The patch is for python 2.4, but should probably be ported to 2.5 and 2.6. Thanks. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-06 13:53 Message: Logged In: YES user_id=1038797 Originator: NO As it's a new feature, it can probably only be in 2.6. Otherwise, that seems good, are you willing to write tests for this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1618485&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:13:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:13:52 -0800 Subject: [Patches] [ python-Patches-1194378 ] Feature enhancement for C socket module Message-ID: Patches item #1194378, was opened at 2005-05-03 11:19 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194378&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Feature enhancement for C socket module Initial Comment: The following tar.bz2 contains a feature enhancement proposal for the socket module to create wrappings of the recvmsg and sendmsg primitives. These are sometimes useful, especially when dealing with ancillary messages, such as communicating the process, user and group id of a remote process to a server for proper identification. These functions have so far been available in a separate module (python-eunuchs from the twisted project), but as they are standard POSIX and have been available on *BSD, AIX, Linux and several other OSs for some time they should be integrated into the core socket module. The attached file contains patches for configure.in the socket module, socket.py and pyconfig.h.in. I've yet to write a test-suite, and the documentation could use some reworking. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-06 14:13 Message: Logged In: YES user_id=1038797 Originator: NO That's really great, it's a shame this patch didn't get much interest. Do you feel like adding test to this, it would probably psuh for its inclusion ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194378&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:29:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:29:22 -0800 Subject: [Patches] [ python-Patches-1121142 ] ZipFile.open - read-only file-like obj for files in archive Message-ID: Patches item #1121142, was opened at 2005-02-11 19:08 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: ZipFile.open - read-only file-like obj for files in archive Initial Comment: I originally started working on updating patch 992750, but decided after a short while to just start from scratch, so I'm posting it as a new patch. Sorry if this isn't appropriate. This patch provides a new open() method on ZipFile; this method returns a file-like object for the requested item in the archive. This file-like object only provides a read() method. ZipFile.read was modified to use the new open method (this was suggested by loewis in reference to patch 992750). The patched zipfile.py passed the existing tests in the test_zipfile.py from CVS. New tests were added to verify the operation of the object returned by open(). These tests were modeled after existing tests for ZipFile.read(); two read fixed-size chunks from the file-like object, and two others read random-sized chunks. I have only run the tests on Windows XP, using Python2.4 from the official Windows installer. I will test the patch out on Linux over the weekend. If the patch is accepted I'll also generate and submit patches for the appropriate documentation as well. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-06 09:29 Message: Logged In: YES user_id=1115903 Originator: YES Thanks for committing. :) I will probably try adding the extract method and submit a patch for that soon. I had noticed the mode problem just a day or two ago while I was writing some more tests to improve coverage of the zipfile module, and I will include a fix for that (and the new tests) in a separate patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 05:49 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54152. If you want to produce further changes, please submit them as new patches against the subversion trunk. Two remarks: - I recall discussion of adding an extract method. Are you still interested in this? - The previous version required that the mode is 'r' or 'a' to invoke .read(), and raised a RuntimeError in this case. Your version doesn't (but instead raises KeyError if the archive member to be read wasn't written yet). Was this change deliberate? ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-27 19:29 Message: Logged In: YES user_id=1115903 Originator: YES This version of the patch includes the updates to the documentation. It passes regression tests as well as the test_zipfile64 tests on my Gentoo laptop. File Added: zipfile_patch7.tgz ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-18 13:41 Message: Logged In: YES user_id=1115903 Originator: YES Here is a version of the patch against the current trunk. It passes a "make test" on my Gentoo laptop at the moment, but I think I still need to add some more tests (like reading from encrypted compressed files), and I need to try out the test_zipfile64 stuff. I don't have time today to look through the module Glyph suggested, so it may be that after I do that I'll have some more tweaks to make. I'm pretty sure I'll be able to spend some more time on Wednesday this week. I also included the full contents of zipfile.py and test_zipfile.py just in case that's useful to somebody. File Added: zipfile_patch6.tgz ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-18 11:44 Message: Logged In: YES user_id=1115903 Originator: YES Thanks, glyph; I'll definitely have a look and see what I can steal. :-) ---------------------------------------------------------------------- Comment By: Glyph Lefkowitz (glyf) Date: 2007-02-16 22:48 Message: Logged In: YES user_id=226807 Originator: NO Twisted also contains an implementation of this functionality, available from http://twistedmatrix.com/trac/browser/trunk/twisted/python/zipstream.py As far as I can tell it doesn't have anything to recommend it over the attached patch, however (in fact, the test coverage of the attached patch looks better), but perhaps it has some behavior which might be desirable to steal. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-02-14 12:13 Message: Logged In: YES user_id=1115903 Originator: YES I will see if I can make some progress on this over the weekend. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-13 04:14 Message: Logged In: YES user_id=21627 Originator: NO Can you please update the patch to the current subversion trunk? I'd like to apply it, but the code of zipfile has changed so that the patch is currently out-of-date. When redoing it, notice that the read implementation has changed (I couldn't figure out how you moved code around). Please do use the trunk (not Python 2.5), and please submit the patch as a single 'svn diff' output (rather than a tar file containing multiple individual diff files). ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-05-30 21:56 Message: Logged In: YES user_id=1115903 Revision 5 of this patch has been in constant use with Python 2.4.1 in an application at my job for about a month; it seems to be stable and useful in that regard. If anybody has time to review and accept (or reject) it I would appreciate it. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-04-26 21:23 Message: Logged In: YES user_id=1115903 After testing on my large batch of large Zip files, I made one fix (version 4 of the patch didn't read all the content of large compressed archive items). The current set of changes is attached as zipfile_patch5.tgz. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-04-13 11:34 Message: Logged In: YES user_id=1115903 I found a problem with my universal newline handling code in readline(); if the first byte of an '\r\n' pair was read from file but the second byte didn't come in on that same read, it resulted in the next line having an inappropriate '\n' prepended to it. zipfile_patch4.tgz has a fix for this included (with everything else, of course). I'm going to test the open() capability in a real application with some reasonably large zip files (containing files up to just short of 2GB) over the next few days, so if any bugs or performance problems show up I may have some more changes. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-04-13 00:58 Message: Logged In: YES user_id=1115903 Uploaded the third revision of this patch; passes all regression tests against current CVS on WinXP. I think all the issues Martin brought up have been addressed except perhaps for the case of compression rate <1. I will have a look at that when I have time; just wanted to get an update here before the patch started to look abandoned. :) ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-03-14 09:37 Message: Logged In: YES user_id=1115903 Hmm...I could have sworn I did the diff in the correct order. I'll make sure next time. :) Here's my comments on your remarks (in order): - I'm adding support for universal newlines, and will reject all modes that aren't legal combinations of r, U, and b. - I'll see if I can make a Zip file store something with compression < 1, and if I can I'll add a test case for it. - I'll try work a .flush() in there on the compression object and come up with a test case if possible - .read(0) and .readline(0) will both return an empty string with no side-effects, since this seems to be what builtin files do. Right now ZipExtFile uses the ZipFile's file object, so you pretty much have to do whatever you're going to do with the ZipExtFile instance you get back from .open() before you use that ZipFile instance in a way that moves the file pointer around. I'm sure that somebody will eventually try to use the ZipFile in this way, so it appears my options are either to (1) give the ZipExtFile its own file object to use (when possible), or (2) make sure this limitation is documented. #1 feels (to me) to be the "right thing" to do, so that's what I'll try unless there's a good reason I shouldn't. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-01 02:59 Message: Logged In: YES user_id=21627 The patch is reversed: usually, diff is invoked as "-c old new". I think it is almost right, but I have a few remarks: - by tradition, open() should have a mode argument, defaulting to 'r'; it would be ok to raise exceptions if it is anything else. However, do consider implementing universal newlines; allowing 'b' as a no-op might also be reasonable. - I wonder what happens if the compression rate is < 1. It would appear that the code might use too few rawbytes. I suggest to recursively invoke read in this case. - I wonder whether it could ever happen that there is still data to uncompress in the zlib object, ie. whether it might be necessary to invoke .flush() after exhausting the rawbytes (and discard the zlib object afterwards) - it appears that atleast the builtin file object implements .read(0) as returning an empty string; the manual says that the entire file is meant only if size is omitted or negative. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2005-02-27 01:28 Message: Logged In: YES user_id=1115903 zipfile_patch2.tgz: I updated the file-like object to support readline, readlines, __iter__ and next(). Added tests for those new methods. Also added a patch for the documentation. Passes regression tests on 2.5a0 built from CVS HEAD with MSVC .NET on Windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1121142&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:46:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:46:18 -0800 Subject: [Patches] [ python-Patches-912410 ] HTMLParser should support entities in attributes Message-ID: Patches item #912410, was opened at 2004-03-09 02:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=912410&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Aaron Swartz (aaronsw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: HTMLParser should support entities in attributes Initial Comment: HTMLParser doesn't currently support entities in attributes, like this: foo This patch fixes that. Simply replace the unescape in HTMLParser.py with: import htmlentitydefs def unescape(self, s): def replaceEntities(s): s = s.groups()[0] if s[0] == "#": s = s[1:] if s[0] in ['x','X']: c = int(s[1:], 16) else: c = int(s) return unichr(c) else: return unichr(htmlentitydefs.name2codepoint[c]) return re.sub(r"&(#?[xX]?(?:[0-9a-fA-F]+|\w{1,8}));", replaceEntities, s) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:46 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54165, with the following changes: - added documentation changes - added testsuite changes - fixed incorrect usage of c in name2codepoint[c] (should be [s]) - included ' in the list of supported entities, for compatibility with older versions of HTMLParser - fall back to replacing an unsupported entity reference with &name; ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2004-03-09 02:21 Message: Logged In: YES user_id=122141 Argh. Hopefully now. ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2004-03-09 02:21 Message: Logged In: YES user_id=122141 Oops. The replacement function is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=912410&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:48:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:48:06 -0800 Subject: [Patches] [ python-Patches-914096 ] Little (improvement and standarization) to asyncore. Message-ID: Patches item #914096, was opened at 2004-03-11 13:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914096&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: alejandro david weil (aweil) >Assigned to: Josiah Carlson (josiahcarlson) Summary: Little (improvement and standarization) to asyncore. Initial Comment: changes: 1- uses add/del_channel/setup_socket functions. Adding calls to them instead of pasting its functionallity inside dispatcher's code. 2- added dispatcher's handle_connect_event() function. It's now, one place to overwrite when transparent wrapping dispatcher. And replaced code like: self.handle_connect() self.connected = 1 to: handle_connect_event() 3- looponce() function added. 2 allowes to implement ssldispatcher, with little work. And, of course, it seems to be usefull for anyone who wants to subclass dispatcher. 3 I used it for when I don't want to keep looping until connections are finished. Don't know if it's against the asyncore principies. Also, I decided to make this changes because I found things like: handle_connect() was called, and sometimes connected were setup to 1 before, and sometimes after the call. I'll expect these changes could make it work in a predecible way! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:48 Message: Logged In: YES user_id=21627 Originator: NO As Andrew didn't respond positively, trying somebody else: Josiah, is it your? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 21:30 Message: Logged In: YES user_id=80475 Andrew, is this module your baby now? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914096&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:50:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:50:19 -0800 Subject: [Patches] [ python-Patches-1335812 ] Patch to implement PEP 351 Message-ID: Patches item #1335812, was opened at 2005-10-23 18:33 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335812&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to implement PEP 351 Initial Comment: PEP 351 proposes the freeze protocol. Here is a patch that implements the proposed builtin, as well as __freeze__() methods for lists and sets. Dictionaries are not yet implemented. Unit tests and documentation are also necessary. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-03-06 09:50 Message: Logged In: YES user_id=12800 Originator: YES The PEP was rejected, so this patch is closed. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 08:06 Message: Logged In: YES user_id=1326842 Originator: NO Can this patch be closed? The PEP was rejected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1335812&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:51:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:51:28 -0800 Subject: [Patches] [ python-Patches-914340 ] gzip.GzipFile to accept stream as fileobj. Message-ID: Patches item #914340, was opened at 2004-03-11 19:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile to accept stream as fileobj. Initial Comment: When gzip.GzipFile is initialized with a fileobj which does not have tell() and seek() methods (non-rewinding stream) it throws exception. The interesting thing is that it doesn't have to. The following patch updates gzip.py to allow any stream with just a read() method to be used. This is helpful if you want to be able to do something like: gzip.GzipFile(fileobj=urllib.urlopen("file:///README.gz")).readlines() or use GzipFile with sys.stdin stream. But keep in mind that seek() and rewind() methond of the GzipFile() won't for such stream even with the patch. Igor ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:51 Message: Logged In: YES user_id=21627 Originator: NO The patch in this form is incomplete: it lacks test suite changes. Can somebody please provide patches to Lib/test/test_gzip.py that exercises this new functionality? ---------------------------------------------------------------------- Comment By: Jakob Truelsen (antialize) Date: 2006-06-19 10:35 Message: Logged In: YES user_id=379876 Is there any reson this patch is not accepted? If this patch is accepted then I have a patch to urlib2 to (automaticaly) accept gzipped content as described here http://www.http-compression.com/#client_request, if there is some reson this patch is not acceptable please detail, so it can be fixed, in tired of using popen and gunzip :) ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 15:14 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 05:27 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-11 21:04 Message: Logged In: YES user_id=995711 Previous revision of the patch does not work correctly with mutliple compressed members in one stream. I've updated the patch file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 From noreply at sourceforge.net Tue Mar 6 15:53:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 06:53:06 -0800 Subject: [Patches] [ python-Patches-922167 ] Patch to 742342 Crash on recursive reload Message-ID: Patches item #922167, was opened at 2004-03-24 05:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to 742342 Crash on recursive reload Initial Comment: Modules that causes a recursive reload cause a program abort. Easy for python developer to fix in their code, but the python interpreter shouldn't crash. This patch guards against circular reloading. This protection comes by an additional dictionary stored in the interpreter state to keep trakc of modules that are reloading. Recursive imports are protected against in a similar manner ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:53 Message: Logged In: YES user_id=21627 Originator: NO Can you please also provide a test suite change to demonstrate the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 From noreply at sourceforge.net Tue Mar 6 16:42:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 07:42:45 -0800 Subject: [Patches] [ python-Patches-1673619 ] Identify modules which couldn't be built Message-ID: Patches item #1673619, was opened at 2007-03-04 15:31 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.6 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Identify modules which couldn't be built Initial Comment: A user has been moaning on c.l.py that Python's setup.py doesn't bail out when the necessary bits can't be found to build a particular extension module (curses in this case). For reasons that should be obvious to this crowd you simply can't have it stop if a particular module can't be built. This patch is a compromise. It enumerates the modules for which the necessary build mojo exists and those modules for which it doesn't. I'm personally a bit ambivalent about it, both the need for it and my particular implementation. An alternate implementation might create a set of all module names at the start of the run then subtract the modules which could be built from that. This implementation has the slight advantage that all the fiddling for a particular module occurs near the tests for that module. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-06 09:42 Message: Logged In: YES user_id=44345 Originator: YES Checked in as r54166. I applied the sort() change but not the max() change. Note that self.extensions is a list of Extension instances while self.failed is a list of strings. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 04:15 Message: Logged In: YES user_id=21627 Originator: NO Some nits: - the max computation can be simplified as longest = max(len(e.name) for e in self.extensions+self.failed) - The sort can be simplified as lst.sort(key=str.lower) There is a change to xmlrpclib in this patch that probably isn't meant to be part of it. Otherwise, it looks fine, please apply. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 08:25 Message: Logged In: YES user_id=44345 Originator: YES Tweak summary. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-03-05 08:24 Message: Logged In: YES user_id=44345 Originator: YES Martin, Thanks for the feedback. Attached is an updated diff. It defers the report until build_ext is finished and reports only on what couldn't be built, either because the environment was missing something or because the compile/link phase failed. These two different problems are reported in different paragraphs, e.g.: Failed to find the necessary bits to build these modules: _md5 _sha _sha256 _sha512 gdbm linuxaudiodev ossaudiodev spwd sunaudiodev Failed to build these modules: _elementtree File Added: missing.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 03:18 Message: Logged In: YES user_id=21627 Originator: NO I don't think the modules that it builds successfully need to be printed - the build messages will tell, anyway. I'm not sure when it prints these things. IMO, they should be printed at the end of the build (i.e. after all modules have been built). It should also print out, in summary, modules that had been attempted to build, but where building failed for some reason. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673619&group_id=5470 From noreply at sourceforge.net Tue Mar 6 16:43:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 07:43:55 -0800 Subject: [Patches] [ python-Patches-1644818 ] Allow importing built-in submodules Message-ID: Patches item #1644818, was opened at 2007-01-25 23:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miguel Lobo (mlobo) Assigned to: Nobody/Anonymous (nobody) Summary: Allow importing built-in submodules Initial Comment: At the moment importing built-in submodules (in my case PyQt4.QtCore and PyQt4.QtGui) does not work. This seems to be because find_module in import.c checks only the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. Python.QtCore) instead. Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case. By moving the is_builtin() check to earlier in find_module and using fullname instead of name, I can build PyQt4.QtCore and PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen. I have run the regression tests and everything seems Ok. I am completely new to CPython development so it is quite possible that my solution is undesirable or that I have done something incorrectly. Please let me know if that is the case. Finally, the attached patch is for Python-2.5, but I have checked it also applies to current svn trunk with only a one-line offset. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 16:43 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a test case? Put the module in Modules/Setup, then have a test case that tries importing it. The test case should check whether the module is in builtin_module_names, and, if it is, try importing it. (Ideally, it should only make the module builtin if debug is enabled, but I can't see how that can be achieved. Perhaps some trickery in config.c could do that, and #ifdefing out the body of the module if debug is disabled). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 01:23 Message: Logged In: YES user_id=1344176 Originator: NO This is the kind of thing you should bring up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). Please subscribe to the list and send in a post with your problem and proposed solution. Thanks for your effort! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 From noreply at sourceforge.net Tue Mar 6 17:04:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 08:04:56 -0800 Subject: [Patches] [ python-Patches-1654417 ] operator.c slice functions need to parse ssize_t Message-ID: Patches item #1654417, was opened at 2007-02-07 18:58 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andy Wingo (wingo) Assigned to: Nobody/Anonymous (nobody) Summary: operator.c slice functions need to parse ssize_t Initial Comment: To reproduce, on a system with 64 bits in sys.maxint: $ python x = [3,4,5] del x[1:] x = [3,4,5] from operator import delslice import sys delslice(x, 1, sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 17:04 Message: Logged In: YES user_id=1326842 Originator: NO The patch looks correct to me, but I can't test it since I don't have a 64 bit system. I posted the patch with added tests here: http://freeweb.siol.net/chollus/ Can someone with the right privileges attach that file here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 From noreply at sourceforge.net Tue Mar 6 17:15:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 08:15:00 -0800 Subject: [Patches] [ python-Patches-1654417 ] operator.c slice functions need to parse ssize_t Message-ID: Patches item #1654417, was opened at 2007-02-07 12:58 Message generated for change (Comment added) made by wingo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andy Wingo (wingo) Assigned to: Nobody/Anonymous (nobody) Summary: operator.c slice functions need to parse ssize_t Initial Comment: To reproduce, on a system with 64 bits in sys.maxint: $ python x = [3,4,5] del x[1:] x = [3,4,5] from operator import delslice import sys delslice(x, 1, sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- >Comment By: Andy Wingo (wingo) Date: 2007-03-06 11:15 Message: Logged In: YES user_id=268660 Originator: YES File Added: operator_slice.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 11:04 Message: Logged In: YES user_id=1326842 Originator: NO The patch looks correct to me, but I can't test it since I don't have a 64 bit system. I posted the patch with added tests here: http://freeweb.siol.net/chollus/ Can someone with the right privileges attach that file here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 From noreply at sourceforge.net Tue Mar 6 17:15:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 08:15:30 -0800 Subject: [Patches] [ python-Patches-1654417 ] operator.c slice functions need to parse ssize_t Message-ID: Patches item #1654417, was opened at 2007-02-07 12:58 Message generated for change (Comment added) made by wingo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andy Wingo (wingo) Assigned to: Nobody/Anonymous (nobody) Summary: operator.c slice functions need to parse ssize_t Initial Comment: To reproduce, on a system with 64 bits in sys.maxint: $ python x = [3,4,5] del x[1:] x = [3,4,5] from operator import delslice import sys delslice(x, 1, sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- >Comment By: Andy Wingo (wingo) Date: 2007-03-06 11:15 Message: Logged In: YES user_id=268660 Originator: YES Updated the patch, thanks for the tests, zseil. ---------------------------------------------------------------------- Comment By: Andy Wingo (wingo) Date: 2007-03-06 11:15 Message: Logged In: YES user_id=268660 Originator: YES File Added: operator_slice.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 11:04 Message: Logged In: YES user_id=1326842 Originator: NO The patch looks correct to me, but I can't test it since I don't have a 64 bit system. I posted the patch with added tests here: http://freeweb.siol.net/chollus/ Can someone with the right privileges attach that file here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 From noreply at sourceforge.net Tue Mar 6 17:33:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 08:33:07 -0800 Subject: [Patches] [ python-Patches-914096 ] Little (improvement and standarization) to asyncore. Message-ID: Patches item #914096, was opened at 2004-03-11 04:55 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914096&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: alejandro david weil (aweil) Assigned to: Josiah Carlson (josiahcarlson) Summary: Little (improvement and standarization) to asyncore. Initial Comment: changes: 1- uses add/del_channel/setup_socket functions. Adding calls to them instead of pasting its functionallity inside dispatcher's code. 2- added dispatcher's handle_connect_event() function. It's now, one place to overwrite when transparent wrapping dispatcher. And replaced code like: self.handle_connect() self.connected = 1 to: handle_connect_event() 3- looponce() function added. 2 allowes to implement ssldispatcher, with little work. And, of course, it seems to be usefull for anyone who wants to subclass dispatcher. 3 I used it for when I don't want to keep looping until connections are finished. Don't know if it's against the asyncore principies. Also, I decided to make this changes because I found things like: handle_connect() was called, and sometimes connected were setup to 1 before, and sometimes after the call. I'll expect these changes could make it work in a predecible way! ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-06 08:33 Message: Logged In: YES user_id=341410 Originator: NO Yes, this would be my baby now. A brief reading of the description of the patch suggests that portions were previously committed. Will look at later today. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 06:48 Message: Logged In: YES user_id=21627 Originator: NO As Andrew didn't respond positively, trying somebody else: Josiah, is it your? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 12:30 Message: Logged In: YES user_id=80475 Andrew, is this module your baby now? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914096&group_id=5470 From noreply at sourceforge.net Tue Mar 6 18:15:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 09:15:13 -0800 Subject: [Patches] [ python-Patches-1666625 ] Allow specifying headers for MIME parts Message-ID: Patches item #1666625, was opened at 2007-02-22 19:18 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1666625&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: J?rg Sonnenberger (jsonn) Assigned to: Nobody/Anonymous (nobody) Summary: Allow specifying headers for MIME parts Initial Comment: The patch is needed to allow specification e.g. of content-transfer-encoding. I couldn't find a way with the existing infrastructure to do that. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 12:15 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for contributing! While I can't speak to whether this patch is a good idea, here are some things you need to fix: 1) Your patch introduces incorrect indentation at line 136 and 137 of Lib/MimeWriter.py (run your updated MimeWriter.py with "python -tt"). 2) The patch lacks test cases (add them to Lib/test/test_MimeWriter.py) and documentation (update Doc/lib/libmimewriter.tex). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1666625&group_id=5470 From noreply at sourceforge.net Tue Mar 6 18:24:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 09:24:15 -0800 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 10:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 12:24 Message: Logged In: YES user_id=1344176 Originator: NO They can stay out; I just wanted to know the reason. This patch looks good to me. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-06 00:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 13:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Tue Mar 6 18:24:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 09:24:20 -0800 Subject: [Patches] [ python-Patches-1675118 ] Epoll wrapper Message-ID: Patches item #1675118, was opened at 2007-03-06 17: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=1675118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Epoll wrapper Initial Comment: epoll is a I/O event loop available on several *nix systems. Some third-party libraries to access it in Python have been available around the web, but I think it would be great to have it in stdlib. Furthermore, it'll be available for using it in _socketmodule in place of poll, if there is an interest. Attached a simple C version, and tests mostly extracted from twisted (where we use a pyrex version). If it seems to be useful, I'd be glad to make the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675118&group_id=5470 From noreply at sourceforge.net Tue Mar 6 18:33:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 09:33:46 -0800 Subject: [Patches] [ python-Patches-1646432 ] ConfigParser getboolean() consistency Message-ID: Patches item #1646432, was opened at 2007-01-28 09:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1646432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 1 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser getboolean() consistency Initial Comment: Minor code change - made getboolean() implementation more consistent with other get...() methods. (i.e. uses _get) (functionality unchanged) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 12:33 Message: Logged In: YES user_id=1344176 Originator: NO I think the original way of expressing this was cleaner and easier to follow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1646432&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:00:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:00:52 -0800 Subject: [Patches] [ python-Patches-1673355 ] change repr(...) from 'Ellipsis' to '...' Message-ID: Patches item #1673355, was opened at 2007-03-04 03:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: John Reese (johnreese) Assigned to: Nobody/Anonymous (nobody) Summary: change repr(...) from 'Ellipsis' to '...' Initial Comment: Given that in Python 3000 you can now use ... as an expression, it seemed like its repr might as well be ... too. The thread quoted in pep 3100 as the reason for the decision suggested using '(int, ...)' as a type annotation; in such expressions, having ... print as ... would be more readable. Note that this would break any doctests including ellipses; none of the Lib/test tests do, and the non-doctests don't care about the repr and still pass. Since prior to Python 3000 ... could only be used in slices, it's unlikely this will break much. I have now written about 100 times more characters than are changed by the patch. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-06 13:00 Message: Logged In: YES user_id=6380 Originator: NO Let's not do this. When I type this at the prompt at least I get a response that might help me understand what's going on: >>> ... Ellipsis >>> Imagine someone's surprise with this session though: >>> ... ... >>> ---------------------------------------------------------------------- Comment By: John Reese (johnreese) Date: 2007-03-04 20:14 Message: Logged In: YES user_id=1734721 Originator: YES (Continuing to talk to myself) It's funny, I mentioned doctest already, thinking just that 'Ellipsis' would now print as '...' and the difference would cause incompatibilities; i.e. the same problem you get any time a __repr__ changes. But there's a worse problem, which is that '...' looks almost exactly like sys.PS2, so a doctest like this will mistake the output for a continuation line and fail: """ >>> Ellipsis ... """ ********************************************************************** File "./doctesterr.py", line 6, in __main__ Failed example: Ellipsis Expected nothing Got: ... ********************************************************************** In light of which grossness this trivial patch is probably not worth it. ---------------------------------------------------------------------- Comment By: John Reese (johnreese) Date: 2007-03-04 03:43 Message: Logged In: YES user_id=1734721 Originator: YES > The thread quoted is http://mail.python.org/pipermail/python-3000/2006-April/000951.html just so you don't have to hunt around. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673355&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:07:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:07:09 -0800 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 12:48 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 19:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 14:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:30:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:30:23 -0800 Subject: [Patches] [ python-Patches-1602128 ] clarify comparison return values Message-ID: Patches item #1602128, was opened at 2006-11-24 07:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602128&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: clarify comparison return values Initial Comment: In the Language Reference section 3.4.1 (http://docs.python.org/ref/customization.html for version 2.5), in the first paragraph where it describes __lt__, __le__, __eq__, __ne__, __gt__, and __ge__, It should mention the special case of NotImplemented, so that people will not be reluctant to return it. (The fourth paragraph suggests returning NotImplemented, but the first suggests that *any* return value will be converted to a boolean, so that NotImplented would mean "True") Please change: """These methods can return any value, but if the comparison operator is used in a Boolean context, the return value should be interpretable as a Boolean value, else a TypeError will be raised. By convention, False is used for false and True for true.""" to: """When an object does not know how to compute a meaningful result, it should return the singleton NotImplemented, in case the other object implements the reflected comparison. By convention, a successful comparison should return either True or False. If any other object is returned in a Boolean context, python will implicitly call bool(result). """ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54171, 54172 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1602128&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:39:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:39:48 -0800 Subject: [Patches] [ python-Patches-1578643 ] various datetime methods fail in restricted mode Message-ID: Patches item #1578643, was opened at 2006-10-17 06:04 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578643&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: various datetime methods fail in restricted mode Initial Comment: The following methods fail in restricted execution mode, because they try to import the time module: datetime.datetime.strftime datetime.datetime.strptime datetime.datetime.timetuple datetime.datetime.utctimetuple datetime.time.time datetime.date.timetuple Example of the problem: >>> import datetime >>> script = 'print dt; print dt.strftime("x")' >>> exec script in {'dt':datetime.datetime(2006,1,1)} 2006-01-01 00:00:00 x >>> exec script in {'dt':datetime.datetime(2006,1,1),'__builtins__':{}} 2006-01-01 00:00:00 Traceback (most recent call last): File "", line 1, in ? File "", line 1, in ? KeyError: '__import__' The attached adjusts the datetime module so that the time module is imported in the initialisation of the datetime module. This allows these methods to be used in restricted execution mode. If the time module is not available, then the datetime module will not be importable either after this patch. Previously the datetime module would be importable but the methods listed above would raise exceptions. If this situation is worth considering then I can adjust the patch accordingly. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:39 Message: Logged In: YES user_id=1326842 Originator: NO I don't think that this is a good solution; datetime is not the only module that does an import in such a way (even some parts of typeobject.c are doing imports). Note that some of the functions in time module that datetime is calling are actually implemented in Python and are also imported. Your patch also introduces a memory leak (the time module is never decrefed) and is missing tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1578643&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:45:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:45:00 -0800 Subject: [Patches] [ python-Patches-1638879 ] Fix to the long("123\0", 10) problem Message-ID: Patches item #1638879, was opened at 2007-01-18 19:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1638879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Fix to the long("123\0", 10) problem Initial Comment: This is a simple patch adapted from the int_new function to the long_new function. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:44 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54173, 54174 (2.5). ---------------------------------------------------------------------- Comment By: Lutz Horn (lhorn) Date: 2007-01-25 09:00 Message: Logged In: YES user_id=96760 Originator: NO This patch compiles and passes all tests against revisions 53406 and 53549 on Ubuntu 6.06.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1638879&group_id=5470 From noreply at sourceforge.net Tue Mar 6 19:47:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 10:47:53 -0800 Subject: [Patches] [ python-Patches-1673121 ] README update: Bash default on Mac OS X Message-ID: Patches item #1673121, was opened at 2007-03-03 20:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673121&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 1 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: README update: Bash default on Mac OS X Initial Comment: The bash shell has been the default on Mac OS X since 10.3, and this patch updates the readme. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:47 Message: Logged In: YES user_id=849994 Originator: NO Untabified and committed as rev. 54175, 54176 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673121&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:00:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:00:19 -0800 Subject: [Patches] [ python-Patches-1654417 ] operator.c slice functions need to parse ssize_t Message-ID: Patches item #1654417, was opened at 2007-02-07 17:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Andy Wingo (wingo) Assigned to: Nobody/Anonymous (nobody) Summary: operator.c slice functions need to parse ssize_t Initial Comment: To reproduce, on a system with 64 bits in sys.maxint: $ python x = [3,4,5] del x[1:] x = [3,4,5] from operator import delslice import sys delslice(x, 1, sys.maxint) Traceback (most recent call last): File "", line 1, in OverflowError: signed integer is greater than maximum ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 19:00 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54177, 54178 (2.5). ---------------------------------------------------------------------- Comment By: Andy Wingo (wingo) Date: 2007-03-06 16:15 Message: Logged In: YES user_id=268660 Originator: YES Updated the patch, thanks for the tests, zseil. ---------------------------------------------------------------------- Comment By: Andy Wingo (wingo) Date: 2007-03-06 16:15 Message: Logged In: YES user_id=268660 Originator: YES File Added: operator_slice.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 16:04 Message: Logged In: YES user_id=1326842 Originator: NO The patch looks correct to me, but I can't test it since I don't have a 64 bit system. I posted the patch with added tests here: http://freeweb.siol.net/chollus/ Can someone with the right privileges attach that file here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654417&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:16:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:16:31 -0800 Subject: [Patches] [ python-Patches-1669633 ] methods for bytes Message-ID: Patches item #1669633, was opened at 2007-02-27 03:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669633&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Pete Shinners (shredwheat) Assigned to: Neal Norwitz (nnorwitz) Summary: methods for bytes Initial Comment: This adds the methods for bytes objects as listed in PEP 358. It includes tests for the newly added methods. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 19:16 Message: Logged In: YES user_id=849994 Originator: NO Committed the new tests as rev. 54179 ---------------------------------------------------------------------- Comment By: Pete Shinners (shredwheat) Date: 2007-02-27 22:23 Message: Logged In: YES user_id=1076442 Originator: YES File Added: bytestests.diff ---------------------------------------------------------------------- Comment By: Pete Shinners (shredwheat) Date: 2007-02-27 22:23 Message: Logged In: YES user_id=1076442 Originator: YES This patch adds many more tests for bytes. It breaks the common string_tests into a lower level base class that can support bytes and strings. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-27 19:02 Message: Logged In: YES user_id=33168 Originator: NO Thanks Pete! Committed revision 54000. ---------------------------------------------------------------------- Comment By: Pete Shinners (shredwheat) Date: 2007-02-27 16:41 Message: Logged In: YES user_id=1076442 Originator: YES Attached is the updated patch. This should apply clean after the "fromhex" patch that was recently applied. This ignores the previous whitespace cleanup patch. Most of this code was copied from string. Minor modifications were made on these, but no real code changes. The following list of new methods are mostly modelled after list methods. extend, insert, append, reverse, pop, remove This adds an Init method to match the Fini. Also added a comment stating partition is the only dependency of all this init. If partiion is removed from bytes, so should this global stuff. _adjust_indices was copied directly from str. This is not used anywhere else in the codebase, so it should be unique again when str is removed. Added comment about this. Switched new single argument methods to METH_O. The 0-255 range is enforced on insert, append, and remove. Outside results in ValueError. File Added: bytesmethods2.diff ---------------------------------------------------------------------- Comment By: Pete Shinners (shredwheat) Date: 2007-02-27 07:28 Message: Logged In: YES user_id=1076442 Originator: YES This is a split of the whitespacing. This matches the PEP7 style guide for 4-space indentation in C code. File Added: bytesspace.diff ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-02-27 05:35 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the patch. I'd like to try to focus on reviewing only new code. How much of this code was copied straight from string, how much was modified and how much was new? There are a bunch of formatting changes. Could you revert those portions and add them to a separate patch (the file can be attached here if you want). Since you are adding a Fini method, I wonder if you ought to add a corresponding Init method. This would init nullbytes and save a comparison on each instantiation of a bytes object. _adjust_indices() looks generic, does this code exist elsewhere/can it be reused? All the methods that take a single argument should use METH_O (e.g., bytes_extend). Shouldn't value in bytes_remove(), bytes_insert(), and possibly elsewhere be limited to 0..255? If the value is > 255, it will traverse the entire bytes, then raise an exception rather than fail early. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669633&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:21:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:21:03 -0800 Subject: [Patches] [ python-Patches-1646432 ] ConfigParser getboolean() consistency Message-ID: Patches item #1646432, was opened at 2007-01-28 14:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1646432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 1 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser getboolean() consistency Initial Comment: Minor code change - made getboolean() implementation more consistent with other get...() methods. (i.e. uses _get) (functionality unchanged) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 19:21 Message: Logged In: YES user_id=849994 Originator: NO I agree with Collin, there's not much point in it. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 17:33 Message: Logged In: YES user_id=1344176 Originator: NO I think the original way of expressing this was cleaner and easier to follow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1646432&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:30:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:30:08 -0800 Subject: [Patches] [ python-Patches-1544909 ] Implementation of PEP 362 Message-ID: Patches item #1544909, was opened at 2006-08-22 14:36 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Brett Cannon (bcannon) Assigned to: Brett Cannon (bcannon) Summary: Implementation of PEP 362 Initial Comment: This patch holds the current implementation of PEP 362 (Signature objects). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-06 11:30 Message: Logged In: YES user_id=357491 Originator: YES Code has moved into the sandbox in the pep362 directory. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-25 23:36 Message: Logged In: YES user_id=357491 I just like to try to reuse the built-in exceptions as much as possible. But you are right, a new exception is the right solution. I added a BindError exception that inherits from TypeError. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:44 Message: Logged In: YES user_id=357491 OK, fixed the bug. Problem was that I had a bogus test that was testing for your example to fail. Oops. =) All fixed in the newest version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 14:34 Message: Logged In: YES user_id=764593 (4) Is there any reason you can't define a new exception type, perhaps as a subclass of TypeError? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 14:23 Message: Logged In: YES user_id=357491 (2) I don't want to do that because it isn't like you can't call bind() multiple times. I would hate to get a Parameter object with some suggested argument value, and then while I had it have that value change because in another thread someone called bind() on the Signature object again. (3) Fair enough. Changed to your suggestion in my version. (4) OK, I see what you are getting at. Changed in my version. I still wish there was a different exception that I could use to flag that the binding didn't fail but that the code couldn't figure out one without being destructive. (5) Yep, that's a bug. I have a test case for it now and will work on fixing it. (7) Fair enough. Code changed and docstring updated. I will work on fixing the bug I have that you reported. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:49 Message: Logged In: YES user_id=764593 For question (5) def f(a): pass sig=inspect.getsignature(f) myargs=() mykwargs=dict(a=1) sig.bind(myargs, mykwargs) Parameter 'a' has been passed, but it is part of the keywords mapping, rather than part of the positional tuple. Right now, this would raise TypeError("too few positional arguments provided") I believe the python parser will normalize calls so that a typical call f(a=6) would would end up seeing args=(6) kwargs={} but I didn't see anything explaining that as a precondition. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-24 10:37 Message: Logged In: YES user_id=764593 (2) I agree that the current-binding information shouldn't be cached; I just think it should be available through the Parameter if it does exist. On the other hand, I do see that it might cause confusion to have a property that is normally unavailable. (3) I think the reason it bugs me is that the same expression is used for both test and true, and so I keep expecting it to be a guard clause of some sort. Something like argspec[1] if (argspec[1] is not None) else "" would also clear up my concerns. (4) That makes sense, except that you don't catch TypeError. So if you just changed it to a TypeError in __tuple_bind_OK raise and stopped catching IndexError, it would have the same effect. (5) I'll try to deal with separately. (7) My thought is that it should always be OK to call inspect.getsignature, even if the callable happens to be a write-only proxy. I'm not saying you shouldn't cache the Signature; I just don't think that a failure to cache should raise an exception if everything else worked. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 10:14 Message: Logged In: YES user_id=357491 In response to Jim: (1) Yes. (2) I don't want to cache it. Remember this is not meant to be used on a per-call basis, but for introspection before calling the functin. (3) Felt like using the new 'if' expression and I never liked using the short-circuit of 'or' for assignment. I can change it to an 'if' statement if it really bugs you. (4) Because I didn't want a TypeError that was caused because of an error in the code to act as an accidental signal that the check won't work. I added a comment about that. (5) I don't quite follow what your problem is here. Can you give me an example function def and call that you think is a problem? (6) No, that will be added when function annotations/tags/whatever get added. No need to prematurely optimize. (7) If it fails it should raise an exception, just like it does now. If you don't want it stored on the object, call Signature's constructor directly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-23 16:58 Message: Logged In: YES user_id=764593 (1) Shouldn't classmethod Parameter.__tuple2param use cls rather than self? (2) Should Parameter objects have an (optional, but standardizing a name) current_value attribute, so that they can be used to describe an execution frame as well as function objects? (Or does the desire not to cache this information mean that bindings is is the best available API?) (3) Why >>> self.var_args = argspec[1] if argspec[1] else '' instead of just >>> self.var_args = argspec[1] or '' (I keep expecting the if argspec[1] to be if argspec[1:] verifying that something is there.) (4) Why does (private) __tuple_bind_OK raise IndexError just so that its only caller (private __positional_bind) can catch and raise TypeError instead? (5) Why does bind insist that non-default arguments be passed as positionally (parts of *args) rather than by name (part of **kwargs)? Is this safe because of how/when it gets called? (6) Should signature objects have a returns attribute for the (parameter object representing the) return value, just to standardize the name? (7) Can getsignature assume that it can create a new attribute on func (or im_func)? Or should it use a temp variable, and wrap the caching inside a try-except? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-23 15:14 Message: Logged In: YES user_id=357491 Add methods to Signature and Parameter. It implements __str__() on both and Signature.bind(). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 15:10 Message: Logged In: YES user_id=357491 Change implementation of Signature.name so as to not try to be fully qualified. It's not possible with methods when passed to a decorator since there is not back-reference to the class it is being defined in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-22 14:44 Message: Logged In: YES user_id=357491 Changed getsignature() to attach the object to the im_func object for methods instead of the method itself since decorators will work with the function object directly and not the method attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1544909&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:48:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:48:31 -0800 Subject: [Patches] [ python-Patches-1644818 ] Allow importing built-in submodules Message-ID: Patches item #1644818, was opened at 2007-01-25 22:12 Message generated for change (Comment added) made by mlobo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miguel Lobo (mlobo) Assigned to: Nobody/Anonymous (nobody) Summary: Allow importing built-in submodules Initial Comment: At the moment importing built-in submodules (in my case PyQt4.QtCore and PyQt4.QtGui) does not work. This seems to be because find_module in import.c checks only the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. Python.QtCore) instead. Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case. By moving the is_builtin() check to earlier in find_module and using fullname instead of name, I can build PyQt4.QtCore and PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen. I have run the regression tests and everything seems Ok. I am completely new to CPython development so it is quite possible that my solution is undesirable or that I have done something incorrectly. Please let me know if that is the case. Finally, the attached patch is for Python-2.5, but I have checked it also applies to current svn trunk with only a one-line offset. ---------------------------------------------------------------------- >Comment By: Miguel Lobo (mlobo) Date: 2007-03-06 19:48 Message: Logged In: YES user_id=1701711 Originator: YES Ok, I have added a test case and it has actually allowed me to fix a small bug: I had tested the case where the parent of the submodule is a normal Python module and the case where it is a frozen module, but another small fix was needed to make it work if the parent is built-in itself. Please be aware that I have only run the regression tests under Windows, as at the moment I don't have a suitable Unix box available. Also, I have uploaded the test case file (test_submodule.py) separately, as I don't know how to convince SVN to put this file in the patch. The new patch is against current trunk. File Added: import.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:43 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a test case? Put the module in Modules/Setup, then have a test case that tries importing it. The test case should check whether the module is in builtin_module_names, and, if it is, try importing it. (Ideally, it should only make the module builtin if debug is enabled, but I can't see how that can be achieved. Perhaps some trickery in config.c could do that, and #ifdefing out the body of the module if debug is disabled). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 00:23 Message: Logged In: YES user_id=1344176 Originator: NO This is the kind of thing you should bring up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). Please subscribe to the list and send in a post with your problem and proposed solution. Thanks for your effort! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 From noreply at sourceforge.net Tue Mar 6 20:49:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 11:49:52 -0800 Subject: [Patches] [ python-Patches-1644818 ] Allow importing built-in submodules Message-ID: Patches item #1644818, was opened at 2007-01-25 22:12 Message generated for change (Comment added) made by mlobo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miguel Lobo (mlobo) Assigned to: Nobody/Anonymous (nobody) Summary: Allow importing built-in submodules Initial Comment: At the moment importing built-in submodules (in my case PyQt4.QtCore and PyQt4.QtGui) does not work. This seems to be because find_module in import.c checks only the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. Python.QtCore) instead. Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case. By moving the is_builtin() check to earlier in find_module and using fullname instead of name, I can build PyQt4.QtCore and PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen. I have run the regression tests and everything seems Ok. I am completely new to CPython development so it is quite possible that my solution is undesirable or that I have done something incorrectly. Please let me know if that is the case. Finally, the attached patch is for Python-2.5, but I have checked it also applies to current svn trunk with only a one-line offset. ---------------------------------------------------------------------- >Comment By: Miguel Lobo (mlobo) Date: 2007-03-06 19:49 Message: Logged In: YES user_id=1701711 Originator: YES File Added: test_submodule.py ---------------------------------------------------------------------- Comment By: Miguel Lobo (mlobo) Date: 2007-03-06 19:48 Message: Logged In: YES user_id=1701711 Originator: YES Ok, I have added a test case and it has actually allowed me to fix a small bug: I had tested the case where the parent of the submodule is a normal Python module and the case where it is a frozen module, but another small fix was needed to make it work if the parent is built-in itself. Please be aware that I have only run the regression tests under Windows, as at the moment I don't have a suitable Unix box available. Also, I have uploaded the test case file (test_submodule.py) separately, as I don't know how to convince SVN to put this file in the patch. The new patch is against current trunk. File Added: import.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:43 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a test case? Put the module in Modules/Setup, then have a test case that tries importing it. The test case should check whether the module is in builtin_module_names, and, if it is, try importing it. (Ideally, it should only make the module builtin if debug is enabled, but I can't see how that can be achieved. Perhaps some trickery in config.c could do that, and #ifdefing out the body of the module if debug is disabled). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 00:23 Message: Logged In: YES user_id=1344176 Originator: NO This is the kind of thing you should bring up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). Please subscribe to the list and send in a post with your problem and proposed solution. Thanks for your effort! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 From noreply at sourceforge.net Tue Mar 6 21:12:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 12:12:40 -0800 Subject: [Patches] [ python-Patches-1449244 ] email.message.py charset can be unicode instance Message-ID: Patches item #1449244, was opened at 2006-03-13 23:55 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.message.py charset can be unicode instance Initial Comment: *_charset in Charset become unicode instance in email-4.0a. message.py should add this for type test. --- email-4.0a2/email/message.py Mon Mar 6 04:58:33 2006 +++ email/message.py Mon Mar 6 14:59:04 2006 @@ -238,7 +238,7 @@ self.del_param('charset') self._charset = None return - if isinstance(charset, str): + if isinstance(charset, str) or isinstance(charset, unicode): charset = email.charset.Charset(charset) if not isinstance(charset, email.charset.Charset): raise TypeError(charset) ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-03-06 20:12 Message: Logged In: YES user_id=67709 Originator: YES Here is a revised patch with a test case. I've found another unicode charset bug in the code and it was fixed also. File Added: email.1449244.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 13:17 Message: Logged In: YES user_id=21627 Originator: NO Can you please include a test case for this, as a patch to the current test suite, using the unittest framework? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 From noreply at sourceforge.net Tue Mar 6 21:16:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 12:16:43 -0800 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 18:05 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 21:16 Message: Logged In: YES user_id=1326842 Originator: NO Can this patch be closed? Python 2.5 has a new cProfile module, which AFAIK, was derived from this patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-27 23:03 Message: Logged In: YES user_id=4771 1 The Py_INCREF(_code) at line 86 is the same as in your original code; it should guarantee that the code object doesn't go away. However, I forgot the corresponding Py_DECREF()... 2 It was a quick hack to have help(lsprof) display these types as well. Now I'm no longer sure that we need help(lsprof) to display them anyway, so let's use the standard '_lsprof.XXX' names. 3 Profiling a large program took forever. I interrupted it after 30 minutes when it showed no sign of wanting to go past the initial step that normally takes only a few minutes. With rotating trees this step is fast again. Maybe they are not an optimal structure, though, because it still takes something like three times longer to finish the whole program (normally takes half an hour). 4 No. Checked in your proposed changes. What is still missing: deciding how much similar to the profiler.py and pstats.py API we need to be, and writing some tests (ideally, having good test coverage would be nice). ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-26 15:54 Message: Logged In: YES user_id=1289249 I looked over the changes so far and they look reasonable. I did have a few questions though: 1 Do we not need to Increment/Decrement references to the code objects? We are using them as keys in the trees as well as payload data later on, but I don't see how we are guaranteed that they won't be reaped. (although it seems unlikely) 2 Is it deliberate to use lsprof.YYY style names for some of the objects (ie lsprof.Profiler) instead of _lsprof ? (is this the normal convention?) 3 Do you have a feel for the performance differences of using the tree instead of the lists? Doing the simple benchmark test they seemed to be comparable, but that test is pretty simple. I'm assuming tht in a large program, the tree approach will be considerably faster? 4 In lsprof.py, is there a reason that the Stats class does not derive from object? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-23 09:46 Message: Logged In: YES user_id=4771 I replaced the linked lists with some kind of auto-balacing trees; the linked lists were creating a huge overhead to profile large programs. The reason for not using plain Python dicts instead is that PyCodeObjects are not very good at being keys in dicts -- their hash computation takes ages, and we'd prefer an identity mapping anyway. The current SVN version is now the first profiler that works and gives sensible results when profiling the PyPy translation process. getstats() is now producing tuples-with-attribute-names instead of dicts (similar to os.stat()). This was mostly motivated by a lack of motivation to introduce error checking everywhere in the dict-building code, but I think it's a reasonable change. There are only a couple of places left in profile.c still missing checks for error results or out-of-memory conditions. The lsprof.py module exposes a simple but minimalistic interface. I suggest we keep and document it or a similar one, but also support -- for compatibility -- the convoluted interface of the existing profile.py/pstats.py and/or hotshot, with the option to dump the stats to a file and reload them. However I don't think it makes sense to use exactly the same format as pstats does (as far as I can guess it doesn't support per-caller information). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-21 20:35 Message: Logged In: YES user_id=6656 Well, you can see what we've done to your baby: http://codespeak.net/svn/user/arigo/hack/misc/lsprof/profile.c Mostly it's just C style conformance so far, though we've fixed a couple of little bugs too. ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 19:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 17:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 17:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 17:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Tue Mar 6 22:30:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 13:30:54 -0800 Subject: [Patches] [ python-Patches-1644818 ] Allow importing built-in submodules Message-ID: Patches item #1644818, was opened at 2007-01-25 22:12 Message generated for change (Comment added) made by mlobo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miguel Lobo (mlobo) Assigned to: Nobody/Anonymous (nobody) Summary: Allow importing built-in submodules Initial Comment: At the moment importing built-in submodules (in my case PyQt4.QtCore and PyQt4.QtGui) does not work. This seems to be because find_module in import.c checks only the module name (e.g. QtCore) against the built-in list, which should contain the full name (e.g. Python.QtCore) instead. Also, the above check is performed after the code to check if the parent module is frozen, which would have already exited in that case. By moving the is_builtin() check to earlier in find_module and using fullname instead of name, I can build PyQt4.QtCore and PyQt4.QtGui into the interpreter and import and use them with no problem whatsoever, even if their parent module (PyQt4) is frozen. I have run the regression tests and everything seems Ok. I am completely new to CPython development so it is quite possible that my solution is undesirable or that I have done something incorrectly. Please let me know if that is the case. Finally, the attached patch is for Python-2.5, but I have checked it also applies to current svn trunk with only a one-line offset. ---------------------------------------------------------------------- >Comment By: Miguel Lobo (mlobo) Date: 2007-03-06 21:30 Message: Logged In: YES user_id=1701711 Originator: YES Argh, I've just realized I forgot to upload the built-in submodule itself. This obviously goes in Modules. File Added: xxsubmoduletest.c ---------------------------------------------------------------------- Comment By: Miguel Lobo (mlobo) Date: 2007-03-06 19:49 Message: Logged In: YES user_id=1701711 Originator: YES File Added: test_submodule.py ---------------------------------------------------------------------- Comment By: Miguel Lobo (mlobo) Date: 2007-03-06 19:48 Message: Logged In: YES user_id=1701711 Originator: YES Ok, I have added a test case and it has actually allowed me to fix a small bug: I had tested the case where the parent of the submodule is a normal Python module and the case where it is a frozen module, but another small fix was needed to make it work if the parent is built-in itself. Please be aware that I have only run the regression tests under Windows, as at the moment I don't have a suitable Unix box available. Also, I have uploaded the test case file (test_submodule.py) separately, as I don't know how to convince SVN to put this file in the patch. The new patch is against current trunk. File Added: import.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:43 Message: Logged In: YES user_id=21627 Originator: NO Can you come up with a test case? Put the module in Modules/Setup, then have a test case that tries importing it. The test case should check whether the module is in builtin_module_names, and, if it is, try importing it. (Ideally, it should only make the module builtin if debug is enabled, but I can't see how that can be achieved. Perhaps some trickery in config.c could do that, and #ifdefing out the body of the module if debug is disabled). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 00:23 Message: Logged In: YES user_id=1344176 Originator: NO This is the kind of thing you should bring up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). Please subscribe to the list and send in a post with your problem and proposed solution. Thanks for your effort! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 From noreply at sourceforge.net Tue Mar 6 23:57:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 14:57:38 -0800 Subject: [Patches] [ python-Patches-1675334 ] Draft implementation for PEP 364 Message-ID: Patches item #1675334, was opened at 2007-03-06 17:57 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=1675334&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Brett Cannon (bcannon) Summary: Draft implementation for PEP 364 Initial Comment: PEP 364 describes (or very shortly, /will/ describe :) a mechanism for forward compatibility with PEP 3108 standard library renaming. This is the reference implementation for that PEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675334&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:21:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:21:26 -0800 Subject: [Patches] [ python-Patches-1675363 ] PEP 3114 -- next() -> __next__() Message-ID: Patches item #1675363, was opened at 2007-03-07 00: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=1675363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Ka-Ping Yee (ping) Summary: PEP 3114 -- next() -> __next__() Initial Comment: This patch implements PEP 3114. It renames all next() methods to __next__, introduces the new builtin next() with one or two arguments and updates the documentation accordingly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675363&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:35:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:35:06 -0800 Subject: [Patches] [ python-Patches-697613 ] fix bug #670311: sys.exit and PYTHONINSPECT Message-ID: Patches item #697613, was opened at 2003-03-04 23:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=697613&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: fix bug #670311: sys.exit and PYTHONINSPECT Initial Comment: So we want to stop SystemExit from causing an actual exit() when using python -i. This patch introduces two new API calls, PyRun_BlockSysExit and PyRun_UnblockSysExit, to set a flag toavoid the exit() call in PyErr_PrintEx. There are several other ways to fix this bug, but I think all of the others I came up with would cause more backwards compatibilty problems and/or be a lot more work. Some possibilities, if anyone is interested, would be: 1) Add a new PyCompilerFlags flag This seems a bit ugly, as it's not really a "compile flag". 2) Add some special run routines that block the exit. 3) Add another parameter to existing run routines. 4) Change PyErr_PrintEx so it doesn't exit when printing a SystemError, instead having the run routines responsible for exiting when catching that exception. What do you think? Is my patch good enough, or would you like something else? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 00:35 Message: Logged In: YES user_id=849994 Originator: NO Committed a variant as rev. 54188. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-02-23 18:29 Message: Logged In: YES user_id=1188172 While it works for me, I am not sure whether this is too much overhead for fixing a glitch no one else complained about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=697613&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:40:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:40:41 -0800 Subject: [Patches] [ python-Patches-703779 ] Fix strange warnings from interpreter if PYTHONSTARTUP used Message-ID: Patches item #703779, was opened at 2003-03-14 18:52 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703779&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: Fix strange warnings from interpreter if PYTHONSTARTUP used Initial Comment: If the PYTHONSTARTUP environment variable is used, warnings will look strange. The warnings module uses __file__ to try to find the line causing the warning and print it out. __file__ is never reset after being set when processing the startup file. The attached patch fixes this by changing PyRun_SimpleFileExFlags to unset __file__ in the __main__ module dictionary entry after running a file, when it had been set by the routine in the first place. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 00:40 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54189. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-22 18:15 Message: Logged In: YES user_id=11375 Originator: NO The patch looks reasonable, and should be applied. I don't think this API change (no longer setting __file__) matters to callers of PyRun_SimpleFileExFlags ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:29 Message: Logged In: YES user_id=33168 Moving to patches ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=703779&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:45:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:45:50 -0800 Subject: [Patches] [ python-Patches-700858 ] Replacing and deleting files in a zipfile archive. Message-ID: Patches item #700858, was opened at 2003-03-10 15:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=700858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.2.x >Status: Pending >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nev Delap (nevdelap) Assigned to: Nobody/Anonymous (nobody) Summary: Replacing and deleting files in a zipfile archive. Initial Comment: Addition of replace, replacestr and delete methods into zipfile.py. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 00:45 Message: Logged In: YES user_id=849994 Originator: NO This patch doesn't apply anymore to current SVN, so it's going to be closed unless someone updates it. ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-05-11 14:57 Message: Logged In: YES user_id=221678 Note that there is a problem with using StringIO files as zipfiles with this as they fail to truncate properly - see bug 951915 ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-05-11 10:24 Message: Logged In: YES user_id=221678 This patch works fine on Python 2.3, if you just add the line del self.NameToInfo[name] before the return in delete (and the first HUNK with author info isn't applied) Unfortunately I can't add a file for some reason... nevdelap, could you update the bug for Python 2.3? ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 15:19 Message: Logged In: YES user_id=730416 OK, so after refreshing it finally decided to show the files I'd added. ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 15:16 Message: Logged In: YES user_id=730416 . ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 15:15 Message: Logged In: YES user_id=730416 The file upload say "Successful" but the file isn't listed!? I've tried it several times and yes I've checked the checkbox. ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 15:14 Message: Logged In: YES user_id=730416 The file upload say "Successful" but the file isn't listed!? I've tried it several times and yes I've checked the checkbox. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=700858&group_id=5470 From noreply at sourceforge.net Wed Mar 7 01:59:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 16:59:01 -0800 Subject: [Patches] [ python-Patches-1535659 ] NNTPS support in nntplib Message-ID: Patches item #1535659, was opened at 2006-08-07 01:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 4 Private: No Submitted By: Aurojit Panda (aurojit) Assigned to: Nobody/Anonymous (nobody) Summary: NNTPS support in nntplib Initial Comment: This patch adds SSL support for nntplib, since it really isn't that simple to just extend the class and add such support, and there are plenty of NNTP servers out there which can only be accessed over SSL. Should be backwards compatible with nntplib, and has been tested to be as such. Of course this library faces limitations on how well it can authenticate SSL certificates due to current limitations (as of 2.4) in socket.ssl, no new additions seem to have been made in 2.5, at least none are listed ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 00:59 Message: Logged In: YES user_id=849994 Originator: NO This patch lacks documentation changes. Also, "self.ssl" doesn't seem to get set when usessl is False, so this will result in an AttributeError in the two changed methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535659&group_id=5470 From oefbhwrl at charter.com Wed Mar 7 01:53:33 2007 From: oefbhwrl at charter.com (Dixie Guerra) Date: Tue, 06 Mar 2007 16:53:33 -0800 Subject: [Patches] Melody, 1200.- start bonus, play 1 hour for free and keep all wins Message-ID: <054a01c7604f$300279e0$621cbc86@qzpwv> I've been thinking of you Melody, Melody, 1200.- start bonus, play 1 hour for free and keep all wins Get your start bonus now: - Visit our website http://learruk.com/micro/16/ and download the playing module in your language (no installation needed) - Register as guest or player......and start winning Cheers Dixie Guerra -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070306/0461642f/attachment.htm From noreply at sourceforge.net Wed Mar 7 02:03:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 17:03:13 -0800 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 22:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 01:03 Message: Logged In: YES user_id=849994 Originator: NO Note that you don't need the global statement for callLst as you aren't rebinding it in the function. ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-06 06:38 Message: Logged In: YES user_id=584997 Originator: YES Hi collin, * I improved testMixIntsAndLongs. It now asserts things * assert is banished, replaced by the correct calls * the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect. * assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test. Let me know if you have further suggestions. File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 00:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Wed Mar 7 02:19:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 17:19:50 -0800 Subject: [Patches] [ python-Patches-1001604 ] glob doesn't return unicode with no dir in unicode filename Message-ID: Patches item #1001604, was opened at 2004-08-01 19:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with no dir in unicode filename Initial Comment: #Here is the script #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # #The second line should be too. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 01:19 Message: Logged In: YES user_id=849994 Originator: NO Shouldn't the conversion to Unicode use the filesystem encoding? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 14:58 Message: Logged In: YES user_id=21627 The patch in itself is fine - it is policy that file name functions return Unicode strings for unicode arguments. The test is flawed, though: there is no guarantee that the string and the Unicode result compare equal (see nyamatongwe's message) - there isn't even a guarantee that they compare without raising an exception. Also, there is currently no guarantee that unicode-in-unicode-out works on all platforms. For example, on Windows 95, this hasn't been implemented (and neither on OS/2). So I would: a) drop the test checking for equality b) consider returns-not-unicode a failure only if os.listdir does return unicode for unicode arguments. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2004-08-02 00:09 Message: Logged In: YES user_id=12579 I wrote a slightly different patch that converts the os.curdir to Unicode inside glob but the patch here is just as good. The nnorwitz patch works well for me on Windows with Unicode file names: >>> glob.glob("*") ['a.bat', 'abc', 'ascii', 'b.bat', 'fileobject.c', 'fileobject.c.diff', 'Gr\xfc\xdf-Gott', 'pep-0277.txt', 'posixmodule.c', 'posixmodule.c.diff', 'uni.py', 'winunichanges.zip', 'Ge??-sa?', '????????????', '??????', '???', '????G\xdf', '???'] >>> glob.glob(u"*") [u'a.bat', u'abc', u'ascii', u'b.bat', u'fileobject.c', u'fileobject.c.diff', u'Gr\xfc\xdf-Gott', u'pep-0277.txt', u'posixmodule.c', u'posixmodule.c.diff', u'uni.py', u'winunichanges.zip', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] Here is my patch if you are interested: --- glob.py Wed Jun 06 06:24:38 2001 +++ g:\Python23\Lib\glob.py Sun Aug 01 23:50:43 2004 @@ -19,7 +19,10 @@ return [] dirname, basename = os.path.split(pathname) if not dirname: - return glob1(os.curdir, basename) + # Use the current directory but match the argument + # string form, either unicode or string. + dirname = type(dirname)(os.curdir) + return glob1(dirname, basename) elif has_magic(dirname): list = glob(dirname) else: @@ -40,7 +43,7 @@ return result def glob1(dirname, pattern): - if not dirname: dirname = os.curdir + assert dirname try: names = os.listdir(dirname) except os.error: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-01 22:31 Message: Logged In: YES user_id=33168 The attached patch fixes the problem and all tests pass on Linux. But I'm not really sure if this should be fixed or not. Perhaps someone more familiar with unicode and filenames (like Martin or Marc-Andre?) could provide feedback. I don't know if this could create any problems on Windows. Changing to a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 From noreply at sourceforge.net Wed Mar 7 02:28:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 17:28:55 -0800 Subject: [Patches] [ python-Patches-997726 ] dircache fix; raise like os.listdir, plus optimization Message-ID: Patches item #997726, was opened at 2004-07-25 22:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997726&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Carl Henrik Holth Lunde (chlunde) Assigned to: Nobody/Anonymous (nobody) Summary: dircache fix; raise like os.listdir, plus optimization Initial Comment: I think it would be better if dircache.listdir acts like os.listdir on missing directories; raise os.error Additionally, I rewrote the logic so it's about 15% faster. If you remove the outer try-except-block which purges the cache for a folder on a miss it's 30% faster. This makes if five times as fast as os.listdir (with my program). Not sure if anybody cares about the speed, the thing I was surprised about was that dircache wasn't a drop-in replacement for listdir. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 01:28 Message: Logged In: YES user_id=849994 Originator: NO Closing as "out of date". ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-21 11:11 Message: Logged In: YES user_id=469548 Could you take a look at the latest CVS revision? I think rev 1.12 and patch #707167 already make dircache raise os.error on missing directories. The optimization would be interesting, but you should post a diff against latest CVS (see http://python.org/dev/devfaq.html#how-to-make-a-patch) instead of a replacement file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=997726&group_id=5470 From noreply at sourceforge.net Wed Mar 7 04:03:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 19:03:08 -0800 Subject: [Patches] [ python-Patches-1675423 ] Make PyComplex_AsCComplex use __complex__ Message-ID: Patches item #1675423, was opened at 2007-03-07 03: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=1675423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: Make PyComplex_AsCComplex use __complex__ Initial Comment: The functions in the math module have the (pleasantly) surprising and apparently undocumented property that they'll accept not just floats, but any Python object having a float method: >>> class test1(object): ... def __float__(self): ... return 3. ... >>> from math import sqrt >>> sqrt(test1()) 1.7320508075688772 Based on this, one might expect the functions in the complex math module cmath to have the same property with respect to __complex__. But this isn't so: >>> class test2(object): ... def __complex__(self): ... return -3 + 0j ... >>> from cmath import sqrt as csqrt >>> csqrt(test2()) Traceback (most recent call last): File "", line 1, in TypeError: a float is required The real surprise is that the cmath functions *will* call the __float__ method, if it's available: >>> csqrt(test1()) (1.7320508075688772+0j) This patch expands the PyComplex_AsCComplex method so that it looks for a __complex__ method before looking for the __float__ method. This `fixes' the above behaviour. Should it be a documented feature that the math functions will make use of __float__? If so, and if the patched behaviour seems desirable, I'll add suitable tests to test_math and test_cmath. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 From noreply at sourceforge.net Wed Mar 7 04:09:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 19:09:59 -0800 Subject: [Patches] [ python-Patches-700858 ] Replacing and deleting files in a zipfile archive. Message-ID: Patches item #700858, was opened at 2003-03-10 10:08 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=700858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.2.x Status: Pending Resolution: Out of Date Priority: 5 Private: No Submitted By: Nev Delap (nevdelap) Assigned to: Nobody/Anonymous (nobody) Summary: Replacing and deleting files in a zipfile archive. Initial Comment: Addition of replace, replacestr and delete methods into zipfile.py. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-06 22:09 Message: Logged In: YES user_id=1115903 Originator: NO Since it seems I'm poking around in the zipfile module quite a bit lately, I'll see if I can update this patch, and add some tests and documentation updates. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 19:45 Message: Logged In: YES user_id=849994 Originator: NO This patch doesn't apply anymore to current SVN, so it's going to be closed unless someone updates it. ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-05-11 09:57 Message: Logged In: YES user_id=221678 Note that there is a problem with using StringIO files as zipfiles with this as they fail to truncate properly - see bug 951915 ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-05-11 05:24 Message: Logged In: YES user_id=221678 This patch works fine on Python 2.3, if you just add the line del self.NameToInfo[name] before the return in delete (and the first HUNK with author info isn't applied) Unfortunately I can't add a file for some reason... nevdelap, could you update the bug for Python 2.3? ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 10:19 Message: Logged In: YES user_id=730416 OK, so after refreshing it finally decided to show the files I'd added. ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 10:16 Message: Logged In: YES user_id=730416 . ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 10:15 Message: Logged In: YES user_id=730416 The file upload say "Successful" but the file isn't listed!? I've tried it several times and yes I've checked the checkbox. ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 10:14 Message: Logged In: YES user_id=730416 The file upload say "Successful" but the file isn't listed!? I've tried it several times and yes I've checked the checkbox. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=700858&group_id=5470 From noreply at sourceforge.net Wed Mar 7 04:14:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 19:14:33 -0800 Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test coverage improvement Message-ID: Patches item #1675424, was opened at 2007-03-06 22:14 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=1675424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile tweaks and test coverage improvement Initial Comment: This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests: - appending to an existing zipfile - appending to an existing file that is not a zipfile - check that calling ZipFile.write without arcname specified produces the expected result - check that files within a Zip archive can have different compression options - check that trying to call write() on a readonly ZipFile object raises a RuntimeError - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension - check that bad modes passed to ZipFile constructor are caught - check that bad modes passed to ZipFile.open are caught - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError - check that bad compression methods passed to ZipFile.open are caught - check that a filename containing a null byte is properly terminated These other miscellaneous changes were made to test_zipfile.py: - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142) - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr. - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data. The following changes were made to zipfile.ZipFile: - A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation) - ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError) - checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant) There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-) If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know. I can add such documentation changes if necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 From noreply at sourceforge.net Wed Mar 7 05:01:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 20:01:28 -0800 Subject: [Patches] [ python-Patches-1669539 ] Change (fix!) os.path.isabs() semantics on Win32 Message-ID: Patches item #1669539, was opened at 2007-02-26 18:07 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: Change (fix!) os.path.isabs() semantics on Win32 Initial Comment: Hi, I consider this to be a bug in os.path.isabs(): PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32. >>> import os.path >>> s = '\\Python25' >>> os.path.isabs(s) True >>> os.path.abspath(s) 'C:\\Python25' >>> os.chdir('d:') >>> os.path.abspath(s) 'D:\\Python25' >>> If s is really an absolute path as isabs() claims, then why does abspath() return a different path (i.e. not s)? And worse, note that a call to os.chdir() changes the meaning of s! So s is clearly not an absolute path, and isabs() is wrong. It turns out that on Windows there are really 4 different kinds of paths: 1) Completely relative, e.g. foo\bar 2) Completely absolute, e.g. c:\foo\bar or \\server\share 3) Halfbreeds with no drive, e.g. \foo\bar 4) Halfbreeds relative to the current working directory on a specific drive, e.g. c:foo\bar Python 2.5's os.path.isabs() method considers both (2) and (3) to be absolute; I agree with the classification of (2) but strongly disagree about case (3). Oh, and os.path.join is also broken, e.g. os.path.join('foo', 'a:bar') gives 'foo\\a:bar', which is an invalid path. Another consequence of this is that os.path.isabs() is not enough to classify paths. Sometimes you really need a relative path, so we really need (at least) a new os.path.isrelative(), which can return "not isabs(s)" on POSIX platforms, and do the right thing on Win32. The attached patch: - Changes the behaviour of os.path.isabs() and os.path.join() on Win32, to classify pathnames as described above (including adding UNC support) - Adds os.path.isrelative() on all platforms - Changes a couple of Win32 os.path tests where I have deliberately broken backward compatibility - Adds lots of new tests for these 3 functions on Win32 This does change the behaviour of isabs(), and it is possible that existing applications might be depending on the current behaviour. Silently changing the behaviour might break those applications. I'm not sure what the best course of action is - applying this for 2.6, putting a new API in (os.path.isreallyabs()?), or waiting for Python 3000...? Kind regards, Jon Foster ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-06 23:01 Message: Logged In: YES user_id=18139 Originator: NO Thanks for submitting this. Nice summary of the different cases. I think very few people have given this that much thought. :) You need a patch for the docs if you want this to even get considered. Then the main obstacle is convincing the team that the nice new logical behavior is worth the breakage. I would be surprised if it got through. And Python 3000 is not going to be the "subtle breakage" release. I would give you better odds if your patch created new APIs instead, and *documented* exactly what's useful about the model you're suggesting. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-02-26 18:15 Message: Logged In: YES user_id=199289 Originator: YES P.S. The patch is against Python SVN trunk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 From noreply at sourceforge.net Wed Mar 7 06:19:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 21:19:06 -0800 Subject: [Patches] [ python-Patches-1675455 ] Use getaddrinfo() in urllib2.py for IPv6 support Message-ID: Patches item #1675455, was opened at 2007-03-07 00: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=1675455&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Cantrell (dcantrell-rh) Assigned to: Nobody/Anonymous (nobody) Summary: Use getaddrinfo() in urllib2.py for IPv6 support Initial Comment: A number of base Python modules use gethostbyname() when they should be using getaddrinfo(). The big limitation hit when using gethostbyname() is the lack of IPv6 support. This first patch is for urllib2.py. It replaces all uses of gethostbyname() with getaddrinfo() instead. getaddrinfo() returns a 5-tuple, so additional code needs to wrap a getaddrinfo() call when replacing gethostbyname() calls. Still should be pretty simple to read. I'd like to see this patch added to the next stable release of Python, if at all possible. I am working up patches for the other modules I see in the Lib/ subdirectory that could use getaddrinfo() instead of gethostbyname(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675455&group_id=5470 From noreply at sourceforge.net Wed Mar 7 06:43:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 21:43:01 -0800 Subject: [Patches] [ python-Patches-1675471 ] Refactor test_pty.py to use unittest. Message-ID: Patches item #1675471, was opened at 2007-03-06 22: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=1675471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_pty.py to use unittest. Initial Comment: This patch turns test_pty.py into a unittest test file. There should be no changes in what the file tests. Lib/test/output/test_pty should be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675471&group_id=5470 From noreply at sourceforge.net Wed Mar 7 08:12:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 23:12:45 -0800 Subject: [Patches] [ python-Patches-1212837 ] Improved profiler Message-ID: Patches item #1212837, was opened at 2005-06-01 16:05 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Improved profiler Initial Comment: I tried using both hotshot and the old python profiler and found them both to be inadequate. The old python profiler seems to give accurate results for timing, but is slow enough that it adds significant overhead to what it is measuing (approximately 10 times). Furthermore, it has no ability to give detailed stats about children. (how much of the cumulative time was taken up by each function called by a function) The hotshot profiler is much faster (profiling) adding only 30% overhead. However, it is extremely slow to load the results from the log file. It does not currently support detailed child stats, although I imagine that it could be made to do so using the information in the log file. The biggest problem with it, is that the time results seem to be highly inaccurate. (doesn't correspond to actual seconds, although they seem to be proportionally wrong) To address these shortcomings, I wrote a new profiling module. It adds about the same overhead (30%) as hotshot, but is much faster in retrieving results. It supports detailed child stats and gives accurate timing information in milliseconds. The accompanying .py module could use additional work though - because of the child stats, I was not able to reuse the stats module like hotshot does. I've included a simple test script that runs pystone for all 3 profilers (and without the profiler) to give a better idea of the differences. I've also included a dump of the output of the script running under Windows XP with python 2.4.1 ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2007-03-07 07:12 Message: Logged In: YES user_id=4771 Originator: NO Yes, this profiler is now available as the cProfile module of Python 2.5. For older Python versions, it is not packaged but can be checked out from my svn repository at http://codespeak.net/svn/user/arigo/hack/misc/lsprof . ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 20:16 Message: Logged In: YES user_id=1326842 Originator: NO Can this patch be closed? Python 2.5 has a new cProfile module, which AFAIK, was derived from this patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-27 21:03 Message: Logged In: YES user_id=4771 1 The Py_INCREF(_code) at line 86 is the same as in your original code; it should guarantee that the code object doesn't go away. However, I forgot the corresponding Py_DECREF()... 2 It was a quick hack to have help(lsprof) display these types as well. Now I'm no longer sure that we need help(lsprof) to display them anyway, so let's use the standard '_lsprof.XXX' names. 3 Profiling a large program took forever. I interrupted it after 30 minutes when it showed no sign of wanting to go past the initial step that normally takes only a few minutes. With rotating trees this step is fast again. Maybe they are not an optimal structure, though, because it still takes something like three times longer to finish the whole program (normally takes half an hour). 4 No. Checked in your proposed changes. What is still missing: deciding how much similar to the profiler.py and pstats.py API we need to be, and writing some tests (ideally, having good test coverage would be nice). ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-26 13:54 Message: Logged In: YES user_id=1289249 I looked over the changes so far and they look reasonable. I did have a few questions though: 1 Do we not need to Increment/Decrement references to the code objects? We are using them as keys in the trees as well as payload data later on, but I don't see how we are guaranteed that they won't be reaped. (although it seems unlikely) 2 Is it deliberate to use lsprof.YYY style names for some of the objects (ie lsprof.Profiler) instead of _lsprof ? (is this the normal convention?) 3 Do you have a feel for the performance differences of using the tree instead of the lists? Doing the simple benchmark test they seemed to be comparable, but that test is pretty simple. I'm assuming tht in a large program, the tree approach will be considerably faster? 4 In lsprof.py, is there a reason that the Stats class does not derive from object? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-23 07:46 Message: Logged In: YES user_id=4771 I replaced the linked lists with some kind of auto-balacing trees; the linked lists were creating a huge overhead to profile large programs. The reason for not using plain Python dicts instead is that PyCodeObjects are not very good at being keys in dicts -- their hash computation takes ages, and we'd prefer an identity mapping anyway. The current SVN version is now the first profiler that works and gives sensible results when profiling the PyPy translation process. getstats() is now producing tuples-with-attribute-names instead of dicts (similar to os.stat()). This was mostly motivated by a lack of motivation to introduce error checking everywhere in the dict-building code, but I think it's a reasonable change. There are only a couple of places left in profile.c still missing checks for error results or out-of-memory conditions. The lsprof.py module exposes a simple but minimalistic interface. I suggest we keep and document it or a similar one, but also support -- for compatibility -- the convoluted interface of the existing profile.py/pstats.py and/or hotshot, with the option to dump the stats to a file and reload them. However I don't think it makes sense to use exactly the same format as pstats does (as far as I can guess it doesn't support per-caller information). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-09-21 18:35 Message: Logged In: YES user_id=6656 Well, you can see what we've done to your baby: http://codespeak.net/svn/user/arigo/hack/misc/lsprof/profile.c Mostly it's just C style conformance so far, though we've fixed a couple of little bugs too. ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-21 17:43 Message: Logged In: YES user_id=1289249 I welcome any additional changes (and help making those changes) that would improve the patch and help get it ready for inclusion in CPython. The main detail that I knew that would need to be addressed was lspstats.py. I didn't spend a lot of time working on it because I generally use a wx TreeListCtrl object to view/sort the results. What other details need to be addressed? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-21 15:57 Message: Logged In: YES user_id=4771 Thanks for your work. The two existing profilers are definitely not satisfactory in my opinion too (I am also encountering crashes with profile.py). There are a number of details that should be addressed before your profiler can be a replacement for the existing ones, e.g. providing simple entry points and documentations, and having the C code reviewed. I am willing to help with all this. I hope you won't mind that I have checked your source code in a public Subversion repository, where I am working a bit on it together with Michael Hudson. (Obviously, the goal is to have the code eventually in the CPython CVS.) http://codespeak.net/svn/user/arigo/hack/misc/lsprof/ ---------------------------------------------------------------------- Comment By: Laura Creighton (lcreighton) Date: 2005-09-21 15:18 Message: Logged In: YES user_id=376262 We've been using Hotshot at Strakt for a while now. We tried your patch and it worked precisely as advertised. Thank you for writing it. Laura Creighton ---------------------------------------------------------------------- Comment By: Brett Rosen (bdrosen) Date: 2005-09-08 15:25 Message: Logged In: YES user_id=1289249 I've enclosed an updated version of profile.c that fixes a problem in the original patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1212837&group_id=5470 From noreply at sourceforge.net Wed Mar 7 08:39:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 06 Mar 2007 23:39:29 -0800 Subject: [Patches] [ python-Patches-812285 ] More precise realm parsing in AbstractBasicAuthHandler Message-ID: Patches item #812285, was opened at 2003-09-25 08:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812285&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Federico Di Carlo (federicodc) Assigned to: Nobody/Anonymous (nobody) Summary: More precise realm parsing in AbstractBasicAuthHandler Initial Comment: AbstractBasicAuthHandler class parses headers to search for a scheme and its realm. "rx" is the compiled regular expression that is used to match these items. But it doesn't work on multiple auth-schemes (as stated in urllib2.py source code). Since I HAD to work around this issue (we have NTLM authentication first in our proxy) I managed a bit the regular expression (rx) and its groups. The auth-request I had to face is: < NTLM, Basic realm="something" >, so I created a RE with named groups to find exactly the type of request that has a "realm" after the scheme, and that can contain commas, in this way: < ([ \t]+|(.*,)+)*(?P<scheme>[^ \t]+)[ \t]+realm="(?P<realm>[^"]*)"' > Matching groups "scheme" and "realm" will contain right values as parsed. This will NOT fix issue with multiple realm-based requests (it will return only last one), but seems to handle well requests like the one specified. Diff attached for Python 2.3 Hope this helps, Federico Di Carlo ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 07:39 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed a similar one as rev. 54195, 54196 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=812285&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:10:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:10:25 -0800 Subject: [Patches] [ python-Patches-1001604 ] glob doesn't return unicode with no dir in unicode filename Message-ID: Patches item #1001604, was opened at 2004-08-01 21:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with no dir in unicode filename Initial Comment: #Here is the script #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # #The second line should be too. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-07 09:10 Message: Logged In: YES user_id=21627 Originator: NO gbrandl: you are right, it should. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 02:19 Message: Logged In: YES user_id=849994 Originator: NO Shouldn't the conversion to Unicode use the filesystem encoding? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 16:58 Message: Logged In: YES user_id=21627 The patch in itself is fine - it is policy that file name functions return Unicode strings for unicode arguments. The test is flawed, though: there is no guarantee that the string and the Unicode result compare equal (see nyamatongwe's message) - there isn't even a guarantee that they compare without raising an exception. Also, there is currently no guarantee that unicode-in-unicode-out works on all platforms. For example, on Windows 95, this hasn't been implemented (and neither on OS/2). So I would: a) drop the test checking for equality b) consider returns-not-unicode a failure only if os.listdir does return unicode for unicode arguments. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2004-08-02 02:09 Message: Logged In: YES user_id=12579 I wrote a slightly different patch that converts the os.curdir to Unicode inside glob but the patch here is just as good. The nnorwitz patch works well for me on Windows with Unicode file names: >>> glob.glob("*") ['a.bat', 'abc', 'ascii', 'b.bat', 'fileobject.c', 'fileobject.c.diff', 'Gr\xfc\xdf-Gott', 'pep-0277.txt', 'posixmodule.c', 'posixmodule.c.diff', 'uni.py', 'winunichanges.zip', 'Ge??-sa?', '????????????', '??????', '???', '????G\xdf', '???'] >>> glob.glob(u"*") [u'a.bat', u'abc', u'ascii', u'b.bat', u'fileobject.c', u'fileobject.c.diff', u'Gr\xfc\xdf-Gott', u'pep-0277.txt', u'posixmodule.c', u'posixmodule.c.diff', u'uni.py', u'winunichanges.zip', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] Here is my patch if you are interested: --- glob.py Wed Jun 06 06:24:38 2001 +++ g:\Python23\Lib\glob.py Sun Aug 01 23:50:43 2004 @@ -19,7 +19,10 @@ return [] dirname, basename = os.path.split(pathname) if not dirname: - return glob1(os.curdir, basename) + # Use the current directory but match the argument + # string form, either unicode or string. + dirname = type(dirname)(os.curdir) + return glob1(dirname, basename) elif has_magic(dirname): list = glob(dirname) else: @@ -40,7 +43,7 @@ return result def glob1(dirname, pattern): - if not dirname: dirname = os.curdir + assert dirname try: names = os.listdir(dirname) except os.error: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-02 00:31 Message: Logged In: YES user_id=33168 The attached patch fixes the problem and all tests pass on Linux. But I'm not really sure if this should be fixed or not. Perhaps someone more familiar with unicode and filenames (like Martin or Marc-Andre?) could provide feedback. I don't know if this could create any problems on Windows. Changing to a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:18:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:18:42 -0800 Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test coverage improvement Message-ID: Patches item #1675424, was opened at 2007-03-07 03:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile tweaks and test coverage improvement Initial Comment: This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests: - appending to an existing zipfile - appending to an existing file that is not a zipfile - check that calling ZipFile.write without arcname specified produces the expected result - check that files within a Zip archive can have different compression options - check that trying to call write() on a readonly ZipFile object raises a RuntimeError - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension - check that bad modes passed to ZipFile constructor are caught - check that bad modes passed to ZipFile.open are caught - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError - check that bad compression methods passed to ZipFile.open are caught - check that a filename containing a null byte is properly terminated These other miscellaneous changes were made to test_zipfile.py: - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142) - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr. - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data. The following changes were made to zipfile.ZipFile: - A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation) - ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError) - checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant) There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-) If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know. I can add such documentation changes if necessary. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 08:18 Message: Logged In: YES user_id=849994 Originator: NO I'd continue raising KeyError in the case the info wasn't found, but set a different message so that backwards compatibility doesn't break. In any case, it would be good to document it. Isn't raising IOError customary for writing to closed files? (If zipfile never raises IOError elsewhere, this is probably not applicable.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:32:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:32:41 -0800 Subject: [Patches] [ python-Patches-1001604 ] glob doesn't return unicode with no dir in unicode filename Message-ID: Patches item #1001604, was opened at 2004-08-01 19:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: leve (leve) Assigned to: Nobody/Anonymous (nobody) Summary: glob doesn't return unicode with no dir in unicode filename Initial Comment: #Here is the script #Python 2.3 on W2K import glob name = glob.glob(u"./*.mp3")[0] print type(name) name = glob.glob(u"*.mp3")[0] print type(name) ##OUTPUT## # # #The second line should be too. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 08:32 Message: Logged In: YES user_id=849994 Originator: NO Committed corrected patch as rev. 54197, 54198 (2.5). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-07 08:10 Message: Logged In: YES user_id=21627 Originator: NO gbrandl: you are right, it should. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 01:19 Message: Logged In: YES user_id=849994 Originator: NO Shouldn't the conversion to Unicode use the filesystem encoding? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-08-12 14:58 Message: Logged In: YES user_id=21627 The patch in itself is fine - it is policy that file name functions return Unicode strings for unicode arguments. The test is flawed, though: there is no guarantee that the string and the Unicode result compare equal (see nyamatongwe's message) - there isn't even a guarantee that they compare without raising an exception. Also, there is currently no guarantee that unicode-in-unicode-out works on all platforms. For example, on Windows 95, this hasn't been implemented (and neither on OS/2). So I would: a) drop the test checking for equality b) consider returns-not-unicode a failure only if os.listdir does return unicode for unicode arguments. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2004-08-02 00:09 Message: Logged In: YES user_id=12579 I wrote a slightly different patch that converts the os.curdir to Unicode inside glob but the patch here is just as good. The nnorwitz patch works well for me on Windows with Unicode file names: >>> glob.glob("*") ['a.bat', 'abc', 'ascii', 'b.bat', 'fileobject.c', 'fileobject.c.diff', 'Gr\xfc\xdf-Gott', 'pep-0277.txt', 'posixmodule.c', 'posixmodule.c.diff', 'uni.py', 'winunichanges.zip', 'Ge??-sa?', '????????????', '??????', '???', '????G\xdf', '???'] >>> glob.glob(u"*") [u'a.bat', u'abc', u'ascii', u'b.bat', u'fileobject.c', u'fileobject.c.diff', u'Gr\xfc\xdf-Gott', u'pep-0277.txt', u'posixmodule.c', u'posixmodule.c.diff', u'uni.py', u'winunichanges.zip', u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435', u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1', u'\u306b\u307d\u3093', u'\u66e8\u05e9\u3093\u0434\u0393\xdf', u'\u66e8\u66e9\u66eb'] Here is my patch if you are interested: --- glob.py Wed Jun 06 06:24:38 2001 +++ g:\Python23\Lib\glob.py Sun Aug 01 23:50:43 2004 @@ -19,7 +19,10 @@ return [] dirname, basename = os.path.split(pathname) if not dirname: - return glob1(os.curdir, basename) + # Use the current directory but match the argument + # string form, either unicode or string. + dirname = type(dirname)(os.curdir) + return glob1(dirname, basename) elif has_magic(dirname): list = glob(dirname) else: @@ -40,7 +43,7 @@ return result def glob1(dirname, pattern): - if not dirname: dirname = os.curdir + assert dirname try: names = os.listdir(dirname) except os.error: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-08-01 22:31 Message: Logged In: YES user_id=33168 The attached patch fixes the problem and all tests pass on Linux. But I'm not really sure if this should be fixed or not. Perhaps someone more familiar with unicode and filenames (like Martin or Marc-Andre?) could provide feedback. I don't know if this could create any problems on Windows. Changing to a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1001604&group_id=5470 From noreply at sourceforge.net Wed Mar 7 09:46:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 00:46:09 -0800 Subject: [Patches] [ python-Patches-914096 ] Little (improvement and standarization) to asyncore. Message-ID: Patches item #914096, was opened at 2004-03-11 04:55 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914096&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: alejandro david weil (aweil) Assigned to: Josiah Carlson (josiahcarlson) Summary: Little (improvement and standarization) to asyncore. Initial Comment: changes: 1- uses add/del_channel/setup_socket functions. Adding calls to them instead of pasting its functionallity inside dispatcher's code. 2- added dispatcher's handle_connect_event() function. It's now, one place to overwrite when transparent wrapping dispatcher. And replaced code like: self.handle_connect() self.connected = 1 to: handle_connect_event() 3- looponce() function added. 2 allowes to implement ssldispatcher, with little work. And, of course, it seems to be usefull for anyone who wants to subclass dispatcher. 3 I used it for when I don't want to keep looping until connections are finished. Don't know if it's against the asyncore principies. Also, I decided to make this changes because I found things like: handle_connect() was called, and sometimes connected were setup to 1 before, and sometimes after the call. I'll expect these changes could make it work in a predecible way! ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-07 00:46 Message: Logged In: YES user_id=341410 Originator: NO Changes to the poll method were done at least a year and a half ago that *added* actual error checking, rather than removing the stub. The looponce() function is unnecessary due to changes for 2.4 or 2.5 that added an optional "count" argument to loop(). There is some positive stuff in the create_socket/set_socket stuff, but I've integrated it with some other changes I'm going to be posting shortly. A variant of the close() modifications were done a while ago. The handle_connect_event is an idea, I had included equivalent semantics in other code I had written, but moving it to a method is better. I'm going to reject the patch as out of date, as most of the issues were previously taken care of. Those ideas that help, I have added them to an updated asyncore that I will be posting soon. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-06 08:33 Message: Logged In: YES user_id=341410 Originator: NO Yes, this would be my baby now. A brief reading of the description of the patch suggests that portions were previously committed. Will look at later today. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 06:48 Message: Logged In: YES user_id=21627 Originator: NO As Andrew didn't respond positively, trying somebody else: Josiah, is it your? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-03-13 12:30 Message: Logged In: YES user_id=80475 Andrew, is this module your baby now? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914096&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:11:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:11:45 -0800 Subject: [Patches] [ python-Patches-1550272 ] Add a test suite for unittest Message-ID: Patches item #1550272, was opened at 2006-09-01 02:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550272&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add a test suite for unittest Initial Comment: This file replaces the current version Lib/test/test_unittest.py, which only contains a single test. The attached suite contains 128 tests for the mission-critical parts of unittest. A patch will follow shortly that fixes the bugs in unittest uncovered by this test suite. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:11 Message: Logged In: YES user_id=849994 Originator: NO Committed as part of rev. 54199. Not backporting to 2.5. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-01-30 06:30 Message: Logged In: YES user_id=1344176 Originator: YES Point 1: I vaguely remember having a reason for not doing 'del sys.modules[module_name]' back when I wrote the suite, but I can't think of what it is now. I've amended the suite to use that line. Point 2: I've added a list at the top of things that have yet to be tested. The TestCase.assert* and TestCase.fail* methods still need explicit tests, though most are tested implicitly in the test suite itself. Point 3: I think assertRaises is ugly : ) Point 4: I've given up on resolving a number of the XXXs in 2.x, though I'm working on a rewrite of unittest for 3.x that will resolve all such issues. Thanks! File Added: test_unittest.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-01-30 02:15 Message: Logged In: YES user_id=261020 Originator: NO Oh the irony. :) This is good stuff. I have not reviewed the whole patch, but sampling bits of it it looks fine. No great danger in committing this, so why not let's commit it? Of the following points, I think only the first should block commit of this patch. Any comments on that first point? 1. test_loadTestsFromName__module_not_loaded() and test_loadTestsFromNames__module_not_loaded() -- these may break in future, and may break e.g. only when running tests in random order, which is sometimes done when debugging obscure stuff. Better to introduce a module of your own in Lib/test that's guaranteed not to be loaded already -- maybe test_unittest_fodder.py . Still, that wouldn't help the case where somebody is running the tests in a loop, which would cause failures already (again, this is something people do as part of bug detection / removal). I don't know the import internals and I hear they're messy, but perhaps just del sys.modules[module_name] at the start of each of those two methods is at least an improvement over what they do now. 2. Would be helpful to list what remains to be tested (for example, there is no test of assertRaises) 3. Why no use of .assertRaises? 4. Would be nice to resolve some of the XXXes, but I realise that this may be difficult/impossible given the requirement for backwards-compatibility ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 02:52 Message: Logged In: YES user_id=1344176 That promised patch for unittest is #1550273. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550272&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:12:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:12:00 -0800 Subject: [Patches] [ python-Patches-1550273 ] Fix numerous bugs in unittest Message-ID: Patches item #1550273, was opened at 2006-09-01 02:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix numerous bugs in unittest Initial Comment: Following from the test suite for unittest that I uploaded as SF #1550272, this patch fixes the bugs that were uncovered while writing the tests. 1) TestLoader.loadTestsFromName() failed to return a suite when resolving a name to a callable that returns a TestCase instance. 2) Fix a bug in both TestSuite.addTest() and TestSuite.addTests() concerning a lack of input checking on the input test case(s)/suite(s). 3) Fix a bug in both TestLoader.loadTestsFromName() and TestLoader.loadTestsFromNames() that had ValueError being raised instead of TypeError. The problem occured when the given name resolved to a callable and the callable returned something of the wrong type. 4) When a name resolves to a method on a TestCase subclass, TestLoader.loadTestsFromName() did not return a suite as promised. 5) TestLoader.loadTestsFromName() would raise a ValueError (rather than a TypeError) if a name resolved to an invalid object. This has been fixed so that a TypeError is raised. 6) TestResult.shouldStop was being initialised to 0 in TestResult.__init__. Since this attribute is always used in a boolean context, it's better to use the False spelling. In addition, all uses of the name PyUnit were changed to unittest. With these changes, the uploaded test suite passes. The Python test suite still passes all tests, as do all the unittest-based test suites I tested the module against. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:12 Message: Logged In: YES user_id=849994 Originator: NO Committed most of the patch as part of rev. 54199. Not backporting to 2.5. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-11-11 21:49 Message: Logged In: YES user_id=1344176 I'd be perfectly happy to have the obvious parts applied as soon as possible. I'm hoping to get back to working on Python -- including this patch -- soon; three successive computer failures have thrown a bit of a kink in my free-time coding. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-11-11 00:27 Message: Logged In: YES user_id=764593 Doing the obvious parts first makes sense to me, because it leaves a cleaner slate for comparisons. On the other hand, the job still won't be done, so if Collin wants it all at once, that would be up to him. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 21:25 Message: Logged In: YES user_id=11375 Some bits of this patch (the URL change, using True/False and sys.exc_info()) are uncontroversial. Shall I go ahead and try to apply those bits, or can the debate on the changes converge to a decision? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 22:31 Message: Logged In: YES user_id=764593 (Responding to the patch, not directly to the conversation) (1) (around lines 234) Do you really want two test cases to compare equal because they have the same name, even if that name is the default runTest? (2) Have you made sense of the UnboundMethodType case? As nearly as I can figure, the old behavior was to run call the test case with a method name (which by default tried to run it, using that string as a TestResult?!?, and then returned None), and the new behavior just wraps this None in a TestSuite. (3) After patch, the callable case has a "return test" which is dead code, because the other branches either raised or returned on their own. (4) Changing the raise from ValueError to TypeError would make sense if not for backwards compatibility. Could you use a custom error that inherits from both? Please don't let these comments get you down; this is code that needs cleaning. (The changes to not special-case jython and to not rewalk the mro are particularly good -- because they don't do anything, having them in the code is misleading.) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 21:39 Message: Logged In: YES user_id=1344176 Jim: > (Is there something they could do to the TestCase() that > would start to fail if you wrap it in a TestSuite()? > Remember that they might have local standards saying "only > one test class per file" or something, so they might never > have gotten a real suite back in the past.) Off the top of my head: - TestSuite.run() requires a TestResult instance to be passed in where TestCase.run()'s result parameter is optional. - TestSuite doesn't have TestCase's shortDescription() or id() method. - Assignment to a TestCase instance's failureException attribute will affect the object's run() method, whereas the same assignment on a TestSuite will have no effect. IMHO none of these is significant enough to block that particular section of the patch. Remember that we're talking about a behaviour that's only triggered when the given name resolves to a callable and that callable returns a TestCase instance when invoked. I don't like the idea of keeping around long-standing minor bugs just because someone, somewhere might be using them. Can anyone produce a real example where someone is relying on this behaviour? I'll send a message to c.l.p on Monday and see if anyone in that wider audience can come up with concrete cases where these behaviours are mission-critical. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 21:18 Message: Logged In: YES user_id=764593 To clarify: It would be wrong to put in checks that refuse to run an invalid test that would have run today. But wrapping TestCase in a TestSuite before returning it is probably OK, since it fixes the list(x) bug you mentioned; you just need to be sure that it won't break something else. Unfortunately, it might. (Is there something they could do to the TestCase() that would start to fail if you wrap it in a TestSuite()? Remember that they might have local standards saying "only one test class per file" or something, so they might never have gotten a real suite back in the past.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-09-01 21:08 Message: Logged In: YES user_id=764593 >> The type checking in TestLoader is only >> there to *find* the tests. ... doesn't >> mean the limitations should be forced >> down to TestSuite. > The important thing is that unittest > presents a unified view of what is and > what is not a test case. Why? If you were designing from scratch, I would agree, because it would make understanding the module easier. But once the module has been deployed this long -- particularly with the various confusing aspects -- people have gotten used to treating it as a black box. If they go through the full procedure, then it won't matter that the runner could have handled something else too. If they go around the loader, then this change will break their regression testing. At a minimum, it needs to be something that can be shut off again easily (such as a strict option), but in that case ... why bother to enforce it at all? >> ... docs ... for the last _five years_ >> -- I'd say this is a long-standing bug >> in the code, not the documentation. The disagreement between them is a long-standing bug. But this can be resolved by changing either. A feature is a bug with seniority. After this long, even a bad decision needs to be respected for backwards compatibility. (It could certainly be changed for Py3K, though.) > Your position seems to be "the code > works as written; who cares what the > intention was". Close. The code is _in_use_ as written, and is in use by people who don't fully understand the intent. Honoring the developers' original intent would break things for users. > ... core idea behind the TestLoader > methods is to return something that can be run()"; > ... the addition of __iter__ to TestSuite > ... ``list(loader.loadTestsFromName("foo.bar"))'' > raised unexpected TypeErrors, complaining that > the return value from loadTestsFromName() wasn't > iterable. So the change to TestSuite wasn't as compatible as expected, nor as tested and documented as desired. :{ The docs should definately be changed to mention this requirement, and the code should probably be changed to make your code work. That could mean adding iteration to TestCase, or it could mean fixing loadTests... to wrap individual cases in a suite, or, for safety, it could mean both. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 16:40 Message: Logged In: YES user_id=1344176 > Consistency within the module is not the important thing > here. TestLoader and TestSuite are separate components. > The type checking in TestLoader is only there to *find* > the tests. > > Just because TestLoader is inherently limited doesn't mean > the limitations should be forced down to TestSuite. The important thing is that unittest presents a unified view of what is and what is not a test case. Having one component take a much wider view of test-case-ness than another component would be confusing. >> Given that the docs for TestLoader.loadTestsFrom*() have >> begun with "Return a suite of all test cases" since >> r20345 >> -- that is, for the last _five years_ -- I'd say this is >> a long-standing bug in the code, not the documentation. > > If the documentation has been wrong for five years, then > the correct thing to do is fix the documentation, not the > code. Why do you assume that it's the documentation that's wrong? Of all the code paths through loadTestsFromName(), only one returns something other than a suite. Your position seems to be "the code works as written; who cares what the intention was". You said that "[t]he core idea behind the TestLoader methods is to return something that can be run()"; ignoring the fact that there's no basis in the documentation or code for this assertion, the addition of __iter__ to TestSuite has enlarged this imaginary guarantee of "run()-able-ness" to "run()-able and iter()-able". I ran across this issue when code like ``list(loader.loadTestsFromName("foo.bar"))'' raised unexpected TypeErrors, complaining that the return value from loadTestsFromName() wasn't iterable. TestCase does not conform to the expectations set up by the use of the word "suite" in the docs. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 04:39 Message: Logged In: YES user_id=602096 > I added these checks in order to be consistent with the rest > of the module, where inheritance from TestCase is required > (TestLoader.loadTestsFromModule(), > TestLoader.loadTestsFromName(), > TestLoader.loadTestsFromNames()). This policy should be > enforced throughout the module, not piecemeal. Consistency within the module is not the important thing here. TestLoader and TestSuite are separate components. The type checking in TestLoader is only there to *find* the tests. Just because TestLoader is inherently limited doesn't mean the limitations should be forced down to TestSuite. > Given that the docs for TestLoader.loadTestsFrom*() have > begun with "Return a suite of all test cases" since > r20345 > -- that is, for the last _five years_ -- I'd say this is a > long-standing bug in the code, not the documentation. If the documentation has been wrong for five years, then the correct thing to do is fix the documentation, not the code. As I said, it doesn't change behaviour significantly, so I lack concern. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-09-01 04:19 Message: Logged In: YES user_id=1344176 Jonathan, > I don't think addTest should check the type of test -- > duck typing is sufficient here. Other testing frameworks > should not have to subclass unittest.TestCase in order to be > able to add their test cases to a unittest.TestSuite. I added these checks in order to be consistent with the rest of the module, where inheritance from TestCase is required (TestLoader.loadTestsFromModule(), TestLoader.loadTestsFromName(), TestLoader.loadTestsFromNames()). This policy should be enforced throughout the module, not piecemeal. > In loadTestsFromName, it's not strictly necessary to > return TestSuite([test]). The core idea behind the > TestLoader methods is to return something that can be > run(). Also, it's generally not a good idea to change > long-standing behaviour to match documentation. It should > be the other way around. Given that the docs for TestLoader.loadTestsFrom*() have begun with "Return a suite of all test cases" since r20345 -- that is, for the last _five years_ -- I'd say this is a long-standing bug in the code, not the documentation. ---------------------------------------------------------------------- Comment By: Jonathan Lange (mumak) Date: 2006-09-01 03:40 Message: Logged In: YES user_id=602096 G'day Collin, I've just had a look at the patch -- looks pretty good. A couple of things though: I don't think addTest should check the type of test -- duck typing is sufficient here. Other testing frameworks should not have to subclass unittest.TestCase in order to be able to add their test cases to a unittest.TestSuite. In loadTestsFromName, it's not strictly necessary to return TestSuite([test]). The core idea behind the TestLoader methods is to return something that can be run(). Also, it's generally not a good idea to change long-standing behaviour to match documentation. It should be the other way around. It's really good to see unittest finally getting some love -- thanks Collin. jml ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1550273&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:21:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:21:39 -0800 Subject: [Patches] [ python-Patches-787789 ] unittest.py: Custom TestRunners and --verbose Message-ID: Patches item #787789, was opened at 2003-08-13 03:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787789&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 3 Private: No Submitted By: Matthew Barnes (mfbarnes) Assigned to: Steve Purcell (purcell) Summary: unittest.py: Custom TestRunners and --verbose Initial Comment: The unittest.TestProgram class accepts a "--verbose" command-line argument. But the setting only gets applied if the testRunner argument to unittest.TestProgram.__init__ is None. There is no clean way of creating a custom TestRunner class and passing it to unittest.TestProgram such that the correct verbosity is picked up. This patch slightly alters the interface to unittest.TestProgram.__init__ by allowing a class to be passed as the testRunner argument (defaulting to TextTestRunner instead of None). Then the runTests method of unittest.TestProgram checks whether self.testRunner is a class, and if so creates an instance of it, passing the correct verbosity setting to the TestRunner class' __init__ method. The patch should still allow a custom TestRunner class _instance_ to be passed to unittest.TestProgram.__init__. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:21 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed a variant as rev. 54201. ---------------------------------------------------------------------- Comment By: Steve Purcell (purcell) Date: 2003-09-10 16:20 Message: Logged In: YES user_id=21477 I can see your point, but this requres every test runner to accept the 'verbosity' keyword argument. I'm worried that this will break a large number of custom test runners. Another approach might be to change TextTestRunner so that 'verbosity' is an instance attribute that is set by TestProgram after the test runner instance is created. Then existing custom test runners will not break, unless they already have a 'verbosity' attribute, which is unlikely. I'll bear this patch in mind; I'm looking at a few pending minor changes to the module, and this area is one that I'm covering. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=787789&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:23:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:23:00 -0800 Subject: [Patches] [ python-Patches-1548388 ] set comprehensions Message-ID: Patches item #1548388, was opened at 2006-08-29 08:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Georg Brandl (gbrandl) Summary: set comprehensions Initial Comment: This is a big one: * cleanup grammar; unifies listcomp/genexp grammar which means that [x for x in 1, 2] is no longer valid * cleanup comprehension compiling code (unifies all AST code for the three comprehensions and most of the compile.c code) * add set comprehensions This patch modifies list comprehensions to be implemented more like generator expressions: in a separate function, which means that the loop variables will not leak any more. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 09:23 Message: Logged In: YES user_id=849994 Originator: YES This patch is now superseded by #1660500. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-01-04 04:57 Message: Logged In: YES user_id=6380 Originator: NO There was some discussion on the py3k list about Raymond's suggestion. Are you thinking of doing that? I'd really like to see the syntactic changes and additions from this patch, but I agree that for list/set comps we can do without the extra stack frame. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-08 17:13 Message: Logged In: YES user_id=80475 Genexps necessarily need a separate stack frame to achieve saved execution state (including the instruction pointer and local variable). Also, it was simplest to implement genexps in terms of the existing and proven code for regular generators. For list and set comps, I think you can take a simpler approach and just rename the inner loop variable to something invisible. That will make it faster, make the disassemby readable, and make it easier to follow in pdb. Also, we get to capitalize on proven code -- they only difference is that the induction variable won't be visible to surrounding code. Since what you have works, I would say just check it in; however, it would probably never get touched again and an early, arbitrary design choice would get set in stone. My bet is that the renaming approach will result in a much simpler patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 15:36 Message: Logged In: YES user_id=6380 I always assumed that the genexps *require* being a function because that's the only way to create a generator. But that argument doesn't apply to listcomps. That's about all I know of the implementation of these.. :-( Have you asked python-dev? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-06 07:03 Message: Logged In: YES user_id=849994 It is complete, it works and it does not leak the loop variable(s). The question is whether it is okay for listcomps and setcomps to be in their own anonymous function, which slows listcomps down compared to the 2.x branch. I don't know why the function approach was taken for genexps, but I suspect it was because who implemented it then saw this as the best way to hide the loop variable. Perhaps somebody else more familiar with the internals and the previous discussions can look over it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-09-06 06:48 Message: Logged In: YES user_id=6380 Do you think this is ready to be checked in, or are you still working on it? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-09-01 09:38 Message: Logged In: YES user_id=849994 Since you can put anything usable as an assignment target after the "for" of a listcomp, just renaming might be complicated. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-31 23:40 Message: Logged In: YES user_id=6380 +1. Would this cause problems for abominations like this though? >>> a=[1] >>> list(tuple(a) for a[0] in "abc") [('a',), ('b',), ('c',)] >>> a ['c'] >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-31 23:15 Message: Logged In: YES user_id=80475 Would it be an oversimplfication for list and set comps to keep everything in one code block and just hide the list loop variables by renaming them: x --> __[x] That approach would only require a minimal patch, and it would make for a cleaner disassembly. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 19:55 Message: Logged In: YES user_id=849994 Attaching slightly revised patch and bytecode comparison. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-29 22:30 Message: Logged In: YES user_id=80475 Can you post a before and disassembly of some list and set comprehensions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 19:09 Message: Logged In: YES user_id=849994 test_compiler and test_transformer fail because the compiler package hasn't been updated yet. test_dis fails because list comprehensions now generate different bytecode. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-29 17:59 Message: Logged In: YES user_id=6380 Nice! I see failures in 4 tests: test_compiler test_dis test_transformer test_univnewlines test_univnewlines is trivial (it's deleting a variable leaked out of a list comprehension); haven't looked at the rest in detail ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-29 08:34 Message: Logged In: YES user_id=849994 The previously attached patch contains only the important files. The FULL patch (attached now) also contains syntax fixes in python files so that the test suite is mostly passing. Note that the compiler package isn't ready yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1548388&group_id=5470 From noreply at sourceforge.net Wed Mar 7 10:41:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 01:41:06 -0800 Subject: [Patches] [ python-Patches-1673007 ] urllib2 requests history + HEAD support Message-ID: Patches item #1673007, was opened at 2007-03-03 16:01 Message generated for change (Comment added) made by koder_ua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 requests history + HEAD support Initial Comment: 1)Add history off all sent and received headers/requests to addinfourl object. Save redirections history too. >>> fd = urllib2.urlopen("http://www.python.org/") >>> print fd.history[0].request_line GET / HTTP/1.1 >>> print fd.history[0].sended [('Accept-Encoding', 'identity'), ('Host', 'www.python.org'), ('Connection', 'cl ose'), ('User-Agent', 'Python-urllib/2.6')] 2)Add support for HEAD (and other) requests: >>> fd = urllib2.urlopen("http://www.python.org/", request_cmd = "HEAD") >>> print len(fd.read()) 0 Please send email here: koder_dot_mail_at_gmail_dot_com ---------------------------------------------------------------------- >Comment By: KDanilov aka koder (koder_ua) Date: 2007-03-07 11:41 Message: Logged In: YES user_id=1620221 Originator: YES Make diff file with svn and delete previos File Added: http_history_and_rtype_svn.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673007&group_id=5470 From noreply at sourceforge.net Wed Mar 7 11:32:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 02:32:05 -0800 Subject: [Patches] [ python-Patches-1669539 ] Change (fix!) os.path.isabs() semantics on Win32 Message-ID: Patches item #1669539, was opened at 2007-02-26 18:07 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: Change (fix!) os.path.isabs() semantics on Win32 Initial Comment: Hi, I consider this to be a bug in os.path.isabs(): PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32. >>> import os.path >>> s = '\\Python25' >>> os.path.isabs(s) True >>> os.path.abspath(s) 'C:\\Python25' >>> os.chdir('d:') >>> os.path.abspath(s) 'D:\\Python25' >>> If s is really an absolute path as isabs() claims, then why does abspath() return a different path (i.e. not s)? And worse, note that a call to os.chdir() changes the meaning of s! So s is clearly not an absolute path, and isabs() is wrong. It turns out that on Windows there are really 4 different kinds of paths: 1) Completely relative, e.g. foo\bar 2) Completely absolute, e.g. c:\foo\bar or \\server\share 3) Halfbreeds with no drive, e.g. \foo\bar 4) Halfbreeds relative to the current working directory on a specific drive, e.g. c:foo\bar Python 2.5's os.path.isabs() method considers both (2) and (3) to be absolute; I agree with the classification of (2) but strongly disagree about case (3). Oh, and os.path.join is also broken, e.g. os.path.join('foo', 'a:bar') gives 'foo\\a:bar', which is an invalid path. Another consequence of this is that os.path.isabs() is not enough to classify paths. Sometimes you really need a relative path, so we really need (at least) a new os.path.isrelative(), which can return "not isabs(s)" on POSIX platforms, and do the right thing on Win32. The attached patch: - Changes the behaviour of os.path.isabs() and os.path.join() on Win32, to classify pathnames as described above (including adding UNC support) - Adds os.path.isrelative() on all platforms - Changes a couple of Win32 os.path tests where I have deliberately broken backward compatibility - Adds lots of new tests for these 3 functions on Win32 This does change the behaviour of isabs(), and it is possible that existing applications might be depending on the current behaviour. Silently changing the behaviour might break those applications. I'm not sure what the best course of action is - applying this for 2.6, putting a new API in (os.path.isreallyabs()?), or waiting for Python 3000...? Kind regards, Jon Foster ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 05:32 Message: Logged In: YES user_id=18139 Originator: NO There is an interesting thread on python-dev right now about possibly tweaking the behavior of splitext() in 2.6. So maybe there is hope after all. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-06 23:01 Message: Logged In: YES user_id=18139 Originator: NO Thanks for submitting this. Nice summary of the different cases. I think very few people have given this that much thought. :) You need a patch for the docs if you want this to even get considered. Then the main obstacle is convincing the team that the nice new logical behavior is worth the breakage. I would be surprised if it got through. And Python 3000 is not going to be the "subtle breakage" release. I would give you better odds if your patch created new APIs instead, and *documented* exactly what's useful about the model you're suggesting. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-02-26 18:15 Message: Logged In: YES user_id=199289 Originator: YES P.S. The patch is against Python SVN trunk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 From noreply at sourceforge.net Wed Mar 7 12:00:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 03:00:43 -0800 Subject: [Patches] [ python-Patches-1462106 ] Patch for 1115886 - splitext incorrectly handles filenames l Message-ID: Patches item #1462106, was opened at 2006-03-31 15:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Mike Foord (mjfoord) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for 1115886 - splitext incorrectly handles filenames l Initial Comment: Patch attached which modifies behaviour in macpath, posixpath, and ntpath - and modifies tests as well. Change is desirable, the intention is to split the extension from the filename. A fiel called '.foo' does not have an extension. There is the possibility that this change will break code where workarounds have been made. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-07 12:00 Message: Logged In: YES user_id=21627 Originator: NO The patch is incomplete: it would still split '..' to ('.', '.'), hence I'm rejecting it. A more complete patch will be committed shortly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462106&group_id=5470 From noreply at sourceforge.net Wed Mar 7 12:27:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 03:27:16 -0800 Subject: [Patches] [ python-Patches-1675363 ] PEP 3114 -- next() -> __next__() Message-ID: Patches item #1675363, was opened at 2007-03-07 00:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Ka-Ping Yee (ping) Summary: PEP 3114 -- next() -> __next__() Initial Comment: This patch implements PEP 3114. It renames all next() methods to __next__, introduces the new builtin next() with one or two arguments and updates the documentation accordingly. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 11:27 Message: Logged In: YES user_id=849994 Originator: YES Version 2 adds tests for the new builtin next(). File Added: __next__.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675363&group_id=5470 From noreply at sourceforge.net Wed Mar 7 12:37:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 03:37:57 -0800 Subject: [Patches] [ python-Patches-1675471 ] Refactor test_pty.py to use unittest. Message-ID: Patches item #1675471, was opened at 2007-03-07 05:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675471&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_pty.py to use unittest. Initial Comment: This patch turns test_pty.py into a unittest test file. There should be no changes in what the file tests. Lib/test/output/test_pty should be removed when this patch is applied. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 11:37 Message: Logged In: YES user_id=849994 Originator: NO Committed a slightly revised version as rev. 54206. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675471&group_id=5470 From noreply at sourceforge.net Wed Mar 7 13:25:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 04:25:09 -0800 Subject: [Patches] [ python-Patches-1597850 ] Cross compiling patches for MINGW Message-ID: Patches item #1597850, was opened at 2006-11-16 17:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Han-Wen Nienhuys (hanwen) Assigned to: Nobody/Anonymous (nobody) Summary: Cross compiling patches for MINGW Initial Comment: Hello, attached tarbal is a patch bomb of 32 patches against python 2.5, that we lilypond developers use for crosscompiling python. The patches were originally written by Jan Nieuwenhuizen, my codeveloper. These patches have been tested with Linux/x86, linux/x64 and macos 10.3 as build host and linux-{ppc,x86,x86_64}, freebsd, mingw as target platform. All packages at lilypond.org/install/ except for darwin contain the x-compiled python. Each patch is prefixed with a small comment, but for reference, I include a snippet from the readme. It would be nice if at least some of the patches were included. In particular, I think that X-compiling is a common request, so it warrants inclusion. Basically, what we do is override autoconf and Makefile settings through setting enviroment variables. **README section** Cross Compiling --------------- Python can be cross compiled by supplying different --build and --host parameters to configure. Python is compiled on the "build" system and executed on the "host" system. Cross compiling python requires a native Python on the build host, and a natively compiled tool `Pgen'. Before cross compiling, Python must first be compiled and installed on the build host. The configure script will use `cc' and `python', or environment variables CC_FOR_BUILD or PYTHON_FOR_BUILD, eg: CC_FOR_BUILD=gcc-3.3 \ PYTHON_FOR_BUILD=python2.4 \ .../configure --build=i686-linux --host=i586-mingw32 Cross compiling has been tested under linux, mileage may vary for other platforms. A few reminders on using configure to cross compile: - Cross compile tools must be in PATH, - Cross compile tools must be prefixed with the host type (ie i586-mingw32-gcc, i586-mingw32-ranlib, ...), - CC, CXX, AR, and RANLIB must be undefined when running configure, they will be auto-detected. If you need a cross compiler, Debian ships several several (eg: avr, m68hc1x, mingw32), while dpkg-cross easily creates others. Otherwise, check out Dan Kegel's crosstool: http://www.kegel.com/crosstool . ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-07 13:25 Message: Logged In: YES user_id=21627 Originator: NO A few more comments: 1. Specifying --build should not be necessary, as it should default to config.guess, right? If so, we should document that you cross-compile by passing --host. OTOH, I see it is a bug that you cannot just specify --host... 2. what are the implications of AC_CHECK_TOOLS wrt. the current AC_CHECK_PROGS invocations? There is a lot of logic to determine the C++ compiler... 3. should we include config.sub? Can we share it easily with the libffi one? Where do I get the most recent version of it? 4. Where does the mapping of system names from -dumpmachine come from? What would need to be done to eliminate this altogether? What about ac_sys_release? 5. Isn't there some autoconf way for detecting a C compiler for the build system? It shouldn't default to 'cc'. 6. I don't think the "skipping import check" warning is needed. Just silently don't perform this check. 7. What is the meaning of CROSS_TARGET? In some place, it is used like sys.platform (so it should take one of the possible values for sys.platform), in configure.in, it is set to ac_sys_system. I think you should just use MACHDEP here. 8. Why is /usr/local/lib excluded when cross-compiling? Please add a comment (likewise for lib64) Otherwise, it looks fine; I haven't been able to test it yet, though. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-01-08 08:59 Message: Logged In: YES user_id=161998 Originator: YES Regarding --config-cache, yes you're correct. Regarding extending configure.in, it does already say "configure: error: cannot check for file existence when cross compiling" and exit. What more would you like it to do? I could add a check that the --config-cache is given, although that is not strictly necessary (You can also set the variables in the environment.) ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2007-01-07 23:03 Message: Logged In: YES user_id=1417949 Originator: NO config.cache is not generated or used on my Windows installation of MinGW unless --config-cache is also given as argument to configure, and from the autoconf documentation this seems to be the default behaviour. So you might want to amend the instructions to take that into account. Isn't requiring the user to manually create and edit config.cache resulting in unnecessary work and confusion for the them when it can be addressed in configure.in? Given that checking files is an operation which does not work when cross_compiling is set and checking them results in configure exiting because of this, configure.in can check cross_compiling before trying these checks and avoid them allowing configure to complete. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-01-07 03:37 Message: Logged In: YES user_id=161998 Originator: YES "checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling" You need to set up a config.cache file that contains the correct entry for ac_cv_file__dev_ptmx ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2007-01-07 03:37 Message: Logged In: YES user_id=161998 Originator: YES "checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling" You need to set up a config.cache file that contains the correct entry for ac_cv_file__dev_ptmx ---------------------------------------------------------------------- Comment By: Richard Tew (rmt38) Date: 2007-01-07 02:50 Message: Logged In: YES user_id=1417949 Originator: NO This: AC_CHECK_FILE(/dev/ptmx, AC_DEFINE(HAVE_DEV_PTMX, 1, [Define if we have /dev/ptmx.])) Is being translated into: echo "$as_me:$LINENO: checking for /dev/ptmx" >&5 echo $ECHO_N "checking for /dev/ptmx... $ECHO_C" >&6 if test "${ac_cv_file__dev_ptmx+set}" = set; then echo $ECHO_N "(cached) $ECHO_C" >&6 else test "$cross_compiling" = yes && { { echo "$as_me:$LINENO: error: cannot check for file existence when cross compiling" >&5 echo "$as_me: error: cannot check for file existence when cross compiling" >&2;} { (exit 1); exit 1; }; } if test -r "/dev/ptmx"; then ac_cv_file__dev_ptmx=yes else ac_cv_file__dev_ptmx=no fi fi Which exits when I do: $ export CC_FOR_BUILD=gcc $ sh configure --host=arm-eabi With an error like: checking for /dev/ptmx... configure: error: cannot check for file existence when cross compiling I am using the latest version of msys/mingw with devkitarm to cross compile. Is this supposed to happen? ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-12-10 00:50 Message: Logged In: YES user_id=161998 Originator: YES this is a patch against a SVN checkout of last week. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-12-10 00:48 Message: Logged In: YES user_id=161998 Originator: YES With cross.patch I've been able to build a working freebsd python on linux. Since you had little problems with the X-compile patches, I'm resubmitting those first. I'd like to give our (admittedly: oddball) mingw version another go when the X-compile patches are in python SVN. Regarding your comments: * what would be a better to import the SO setting? the most reliable way to get something out of a makefile into python is VAR=foo export VAR .. os.environ['VAR'] this doesn't introduce any fragility in parsing/expanding/(un)quoting, so it's actually pretty good. Right now, I'm overriding sysconfig wholesale in setup.py with a sysconfig._config_vars.update (os.environ) but I'm not sure that this affects the settings in build_ext.py. A freebsd -> linux compile does not touch that code, so if you dislike it, we can leave it out. * I've documented the .x extension File Added: cross.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 21:12 Message: Logged In: YES user_id=21627 Originator: NO One more note: it would be best if the patches were against the subversion trunk. They won't be included in the 2.5 maintenance branch (as they are a new feature), so they need to be ported to the trunk, anyway. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-06 21:06 Message: Logged In: YES user_id=21627 Originator: NO I'll add my comments as I go through the patches. cab1e7d1e54d14a8aab52f0c3b3073c93f75d4fc: - why is there now a mingw32msvc2 platform? If the target is mingw (rather than Cygwin), I'd expect that the target is just Win32/Windows, and that all symbolic constants provided be usable across all Win32 Pythons. - why is h2py run for /usr/include/netinet/in.h? Shouldn't it operate on a target header file? - please include any plat-* files that you generate in the patch. - why do you need dl_nt.c in Modules? Please make it use the one from PC (consider updating the comment about calling initall) b52dbbbbc3adece61496b161d8c22599caae2311 - please combine all patches adding support for __MINGW32__ into a single one. Why is anything needed here at all? I thought Python compiles already with mingw32 (on Windows)? - what is the exclusion of freezing for? 059af829d362b10bb5921367c93a56dbb51ef31b - Why are you taking timeval from winsock2.h? It should come from sys/time.h, and does in my copy of Debian mingw32-runtime. 6a742fb15b28564f9a1bc916c76a28dc672a9b2c - Why are these changes needed? It's Windows, and that is already supported. a838b4780998ef98ae4880c3916274d45b661c82 - Why doesn't that already work on Windows+cygwin+mingw32? f452fe4b95085d8c1ba838bf302a6a48df3c1d31 - I think this should target msvcr71.dll, not msvcrt.dll Please also combine the cross-compilation patches into a single one. - there is no need to provide pyconfig.h.in changes; I'll regenerate that, anyway. 9c022e407c366c9f175e9168542ccc76eae9e3f0 - please integrate those into the large AC_CHECK_FUNCS that already exists 540684d696df6057ee2c9c4e13e33fe450605ffa - Why are you stripping -Wl? 64f5018e975419b2d37c39f457c8732def3288df - Try getting SO from the Makefile, not from the environment (I assume this is also meant to support true distutils packages some day). 7a4e50fb1cf5ff3481aaf7515a784621cbbdac6c - again: what is the "mingw" platform? 7d3a45788a0d83608d10e5c0a34f08b426d62e92 - is this really necessary? I suggest to drop it 23a2dd14933a2aee69f7cdc9f838e4b9c26c1eea - don't include bits/time.h; it's not meant for direct inclusion 6689ca9dea07afbe8a77b7787a5c4e1642f803a1 - what's a .x file? ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-25 16:12 Message: Logged In: YES user_id=161998 Originator: YES I've sent the agreement by snailmail. ---------------------------------------------------------------------- Comment By: Jan Nieuwenhuizen (janneke-sf) Date: 2006-11-17 20:57 Message: Logged In: YES user_id=1368960 Originator: NO I do not mind either. I've just signed and faxed contrib-form.html. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 01:33 Message: Logged In: YES user_id=161998 Originator: YES note that not all of the patch needs to go in its current form. In particular, setup.py should be much more clever to look into build-root for finding libs and include files. ---------------------------------------------------------------------- Comment By: Han-Wen Nienhuys (hanwen) Date: 2006-11-17 01:32 Message: Logged In: YES user_id=161998 Originator: YES I don't mind, and I expect Jan won't have a problem either. What's the procedure: do we send the disclaimer first, or do you do the review, or does everything happen in parallel? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 22:47 Message: Logged In: YES user_id=21627 Originator: NO Would you and Jan Nieuwenhuizen be willing to sign the contributor agreement, at http://www.python.org/psf/contrib.html I haven't reviewed the patch yet; if they can be integrated, that will only happen in the trunk (i.e. not for 2.5.x). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1597850&group_id=5470 From noreply at sourceforge.net Wed Mar 7 14:04:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 05:04:22 -0800 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 11:48 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: TH (therve) Date: 2007-03-07 13:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 18:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 18:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 13:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 00:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Wed Mar 7 14:05:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 05:05:13 -0800 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 11:48 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: TH (therve) Date: 2007-03-07 13:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 18:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 18:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 13:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 00:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Wed Mar 7 14:41:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 05:41:40 -0800 Subject: [Patches] [ python-Patches-1410680 ] Add 'surgical editing' to ConfigParser Message-ID: Patches item #1410680, was opened at 2006-01-20 11:12 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'surgical editing' to ConfigParser Initial Comment: See also: [ 1399309 ] ConfigParser to save with order [ 1371075 ] ConfigParser to accept a custom dict to allow ordering The attached patch adds a new method, update_file, to RawConfigParser. This method is similar to the existing write method, but preserves blank lines, comments, and ordering, as requested many times on python-dev and python-list. These are the three requirements that Guido specified in January 2005. IMO the attached patch is better than 1399309 because it includes all the functionality (passing a pointer to an empty file results in a sorted write() output), but is completely backwards compatible as write() is unchanged. The addition of preserving comments is also essential for many applications. IMO the attached patch is better than 1371075 because the latter really requires a custom class (e.g. the third party one suggested) in order to be useful. It also doesn't address the issue of preserving comments. The attached patch is essentially a tidied up version of the one included with SpamBayes (in the OptionClass.py module), which is used extensively within SpamBayes (and has been for several years). Also attached are additional unittests for the new method, and a documentation patch. Please let me know if there are recommended changes. This patch does not address any of the additional ConfigParser improvements that have been suggested at various times. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2007-03-07 13:41 Message: Logged In: YES user_id=113328 Originator: NO I've looked at the patches attached here. They look reasonable, and in isolation I would be happy for them to be accepted, although I have no personal use for the functionality. However, patch 131075 (ConfigParser to accept a custom dict to allow ordering) has since been accepted, and in the light of that, this patch may no longer be appropriate. From the descriptions, and a review of the code, I am not clear how the two are related. The justification should be updated to reflect the fact that patch 131075 has been accepted - or if there is no longer sufficient justification for what may well be a second way to do the same thing, then this patch should be withdrawn. I have looked at Scott Dial's updated patches, but I am not clear on what they add. There has obviously been some discussion which happened off the tracker - as a result I can't comment on the DEFAULTSECT issue. The whitespace stripping issue needs a clearer description. I don't see what is happening here. One or other of the patches is presumably mishandling leading or trailing whitespace in options, but I can't tell which. The "growing blank lines" fix sounds sensible. Recommendation: 1. The OP should review the justification in the light of the acceptance of patch 1371075. 2. Scott should clarify the issues around the 2 areas I mentioned. 3. An updated patch should be submitted, either by the OP against this tracker, or by someone else (Scott, perhaps) under a new tracker item, pointing back to this one. Otherwise, I would recommend rejection on the grounds that the functionality now appears to be available via the acceptance of 1371075 (albeit in a form that this patch claims is inferior). Paul Moore ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-08 08:15 Message: Logged In: YES user_id=383208 Before I lose track of the updated patches I made.. They can be found here: http://scottdial.com/python-dev/ConfigParser.diff http://scottdial.com/python-dev/test_cfgparser.diff The notes I emailed Tony were: * I have modified the OPTCRE matching to not just throw away the whitespace after a [=:]. Second, I have modified the opt.rstrip(), again so that the whitespace isn't just thrown away. A new variable padded_vi then appears which is a formatting-preserved version of vi. * I have removed at least one erroneous write('\n'), and changed the pattern for adding newlines to missing sections, such that the newlines are added /before/ the section heading (and only if there are lines appearing before). These together solve the growing blank lines phenomena. * I have modified the add_missing section to deal with DEFAULTSECT appropriately. Which solves the appearing/disappearing act that I had mentioned. * I have updated the test's to match the new expected output. --- And in reponse to Jim's comment, such a feature is not in the scope of the patch. The patch is to explicitly leave things the way they are, so any sort of sorting would make no sense. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-20 15:11 Message: Logged In: YES user_id=764593 Wanting to keep the whole thing (except defaultsection) in sorted order will probably be a common use case. It sounds like you can do this by "updating" to an empty file, but it isn't the obvious solution. Could you either add an option to sort the whole thing (so inserts may not be at the end) or an explicit mention in the docstring of how to get this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 From noreply at sourceforge.net Wed Mar 7 14:47:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 05:47:04 -0800 Subject: [Patches] [ python-Patches-1399309 ] ConfigParser to save with order Message-ID: Patches item #1399309, was opened at 2006-01-07 18:11 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser to save with order Initial Comment: ConfigParser saves the data in a not-predefined order. This is because it keeps, internally, the information in dictionaries. This patch orders the info to be saved in the file through the ConfigParser write() method. This patch does not let the user to specify the order. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2007-03-07 13:47 Message: Logged In: YES user_id=113328 Originator: NO This patch should probably be rejected now, as patch 1371075 (which seems to be a superset of this) has been accepted. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2006-01-12 21:59 Message: Logged In: YES user_id=552329 Note that the patch is backwards (new old instead of old new). IMO the 'surgical' editing that has been proposed many times on python-dev and c.l.p would be superior to this. IOW, the original order of the file should be retained (any new entries could be added alphabetically, as here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 From noreply at sourceforge.net Wed Mar 7 14:55:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 05:55:53 -0800 Subject: [Patches] [ python-Patches-1399309 ] ConfigParser to save with order Message-ID: Patches item #1399309, was opened at 2006-01-07 15:11 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser to save with order Initial Comment: ConfigParser saves the data in a not-predefined order. This is because it keeps, internally, the information in dictionaries. This patch orders the info to be saved in the file through the ConfigParser write() method. This patch does not let the user to specify the order. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-07 10:55 Message: Logged In: YES user_id=752496 Originator: YES Closing it, because after the patch 1371075, you can control ConfigParser behaviour regarding order. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2007-03-07 10:47 Message: Logged In: YES user_id=113328 Originator: NO This patch should probably be rejected now, as patch 1371075 (which seems to be a superset of this) has been accepted. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2006-01-12 18:59 Message: Logged In: YES user_id=552329 Note that the patch is backwards (new old instead of old new). IMO the 'surgical' editing that has been proposed many times on python-dev and c.l.p would be superior to this. IOW, the original order of the file should be retained (any new entries could be added alphabetically, as here). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399309&group_id=5470 From noreply at sourceforge.net Wed Mar 7 16:38:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 07:38:52 -0800 Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool Message-ID: Patches item #1673122, was opened at 2007-03-03 15:33 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: libtool Initial Comment: When the framewok is built on Mac OS X, the Mac OS X specific libtool is used. However, if the GNU libtool is on the PATH first, python refuses to build. This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file. That way, someone can have GNU libtool on the PATH first and still build python. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 10:38 Message: Logged In: YES user_id=18139 Originator: NO OK, I don't see why not. I'll try this out tonight, just to make sure it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 From noreply at sourceforge.net Wed Mar 7 18:07:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 09:07:51 -0800 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 12:48 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 18:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 19:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 14:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Wed Mar 7 18:54:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 09:54:40 -0800 Subject: [Patches] [ python-Patches-1628205 ] socket.readline() interface doesn't handle EINTR properly Message-ID: Patches item #1628205, was opened at 2007-01-04 16:37 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1628205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: socket.readline() interface doesn't handle EINTR properly Initial Comment: The socket.readline() interface doesn't handle EINTR properly. Currently, when EINTR received exception is not handled and all data that has been in the buffer is lost. There is no way to recover that data from the code that uses the interface. Correct behaviour would be to catch EINTR and restart recv(). Patch is attached. Following is the real world example of how it affects httplib module: File "/usr/local/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/local/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/local/lib/python2.4/xmlrpclib.py", line 1131, in request errcode, errmsg, headers = h.getreply() File "/usr/local/lib/python2.4/httplib.py", line 1137, in getreply response = self._conn.getresponse() File "/usr/local/lib/python2.4/httplib.py", line 866, in getresponse response.begin() File "/usr/local/lib/python2.4/httplib.py", line 336, in begin version, status, reason = self._read_status() File "/usr/local/lib/python2.4/httplib.py", line 294, in _read_status line = self.fp.readline() File "/usr/local/lib/python2.4/socket.py", line 325, in readline data = recv(1) error: (4, 'Interrupted system call') -Maxim ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 12:54 Message: Logged In: YES user_id=18139 Originator: NO loewis: I think your idea is the right answer. I'm not worried about select/poll. Surely no one uses select/poll and socket._fileobject.readline() on the same socket. select/poll are for nonblocking sockets; this readline() method doesn't even catch EWOULDBLOCK. ...In fact even if you did use select/poll on the (blocking) socket after readline() threw EINTR--which no one should do--I think it would still work just as expected unless you were doing something truly weird. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-16 08:05 Message: Logged In: YES user_id=21627 Originator: NO I agree that this should be fixed; I'm not sure I like the proposed fixed, though. It discards the exception and keeps running. What it (IMO) should do instead is abort, then return the data on the next invocation. Of course, this may have problems in itself, since the file descriptor might not report read-ready when passed to select or poll, even though data are available. Please discuss this on python-dev (and elsewhere), and report what recommendations people made. ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2007-01-08 05:51 Message: Logged In: YES user_id=24670 Originator: YES Well, it's not quite correct since for example httplib.py tries to handle EINTR. The fundamental problem with socket.readline() is that it does internal buffering so that getting EINTR results in data being lost. I don't think it has to be fixed in C, since recv() is very low-level interface and it is expected to return EINTR on signal, so that "fixing" it there could possibly break software that relies on this behaviour. And I don't quite buy your reasoning - "since it's broken in few more places let's keep it consistently broken everywhere". To me it sounds like attempt to hide the head in the sand instead of facing the problem at hand. Fixing socket.readline() may be the first step in improvind the library to handle this condition properly. ---------------------------------------------------------------------- Comment By: Oren Tirosh (orenti) Date: 2007-01-07 13:24 Message: Logged In: YES user_id=562624 Originator: NO You may have encountered this on sockets but *all* Python I/O does not handle restart on EINTR. The right place to fix this is probably in C, not the Python library. The places where an I/O operation could be interrupted are practically anywhere the GIL is released. This kind of change is likely to be controversial. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1628205&group_id=5470 From noreply at sourceforge.net Wed Mar 7 18:57:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 09:57:09 -0800 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 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=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Wed Mar 7 18:58:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 09:58:27 -0800 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Wed Mar 7 19:01:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 10:01:23 -0800 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Wed Mar 7 19:24:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 10:24:29 -0800 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Wed Mar 7 19:34:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 10:34:08 -0800 Subject: [Patches] [ python-Patches-1675981 ] Remove dead code in typeobject's type_new() Message-ID: Patches item #1675981, was opened at 2007-03-07 19: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=1675981&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Remove dead code in typeobject's type_new() Initial Comment: The code that this patch removes can never be reached; __dict__ and __weakref__ are removed from the slots tuple earlier in the code, in the loop that mangles slot names, around line 1850. I think that this code was just overlooked in the last refactoring, in revision 28166. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675981&group_id=5470 From noreply at sourceforge.net Wed Mar 7 19:55:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 10:55:39 -0800 Subject: [Patches] [ python-Patches-1576313 ] os.execvp[e] on win32 fails for current directory Message-ID: Patches item #1576313, was opened at 2006-10-12 19:57 Message generated for change (Comment added) made by mcmahon_m You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.execvp[e] on win32 fails for current directory Initial Comment: By convention when program is executed by searching path, the first directory to be searched should be the current directory. However on python this is not true: 1.c: int main() { return 1; } test.py: import os os.execvp('1', ('1',)) result: Traceback (most recent call last): File "C:\1\test.py", line 2, in os.execvp('1',('1',)) File "D:\Programs\ActiveState\Python25\lib\os.py", line 348, in execvp _execvpe(file, args) File "D:\Programs\ActiveState\Python25\lib\os.py", line 386, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory Attached patch fixes this. ---------------------------------------------------------------------- Comment By: Mark Mc Mahon (mcmahon_m) Date: 2007-03-07 13:55 Message: Logged In: YES user_id=1424947 Originator: NO I don't know about OS/2 but standard windows definitely looks in the current folder first. Should the patch insert "." rather then ""? >>> import os.path >>> os.path.join("", "test") 'test' >>> os.path.join(".", "test") '.\\test' >>> ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-14 15:15 Message: Logged In: YES user_id=1197042 On win32 it is not so, execlp() in msvcrt, for example, will always looks in current directory before looking on PATH (and if I remember correctly OS/2 has the same rules, I don't remember PATH on OS/2 ever needing . in the PATH), so does CreateFile, so on win32 it's just what is expected. Sorry if I'm wrong though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 14:51 Message: Logged In: YES user_id=21627 What convention are you referring to? By convention, you have to specify executables in the current directory with ./ if you don't have "." in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 From noreply at sourceforge.net Wed Mar 7 20:15:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 11:15:00 -0800 Subject: [Patches] [ python-Patches-1576313 ] os.execvp[e] on win32 fails for current directory Message-ID: Patches item #1576313, was opened at 2006-10-13 04:57 Message generated for change (Comment added) made by snaury You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.execvp[e] on win32 fails for current directory Initial Comment: By convention when program is executed by searching path, the first directory to be searched should be the current directory. However on python this is not true: 1.c: int main() { return 1; } test.py: import os os.execvp('1', ('1',)) result: Traceback (most recent call last): File "C:\1\test.py", line 2, in os.execvp('1',('1',)) File "D:\Programs\ActiveState\Python25\lib\os.py", line 348, in execvp _execvpe(file, args) File "D:\Programs\ActiveState\Python25\lib\os.py", line 386, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory Attached patch fixes this. ---------------------------------------------------------------------- >Comment By: Alexey Borzenkov (snaury) Date: 2007-03-07 22:15 Message: Logged In: YES user_id=1197042 Originator: YES No, inserting '.' is unnecessary exactly because ntpath.join is working the way you described. On Windows and OS/2 'test' will mean 'test' in current directory, i.e. the expected result without any unnecessary characters prepended and without any unnecessary cycles since ntpath.join("", "whatever") is optimized in ntpath.join. ---------------------------------------------------------------------- Comment By: Mark Mc Mahon (mcmahon_m) Date: 2007-03-07 21:55 Message: Logged In: YES user_id=1424947 Originator: NO I don't know about OS/2 but standard windows definitely looks in the current folder first. Should the patch insert "." rather then ""? >>> import os.path >>> os.path.join("", "test") 'test' >>> os.path.join(".", "test") '.\\test' >>> ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-15 00:15 Message: Logged In: YES user_id=1197042 On win32 it is not so, execlp() in msvcrt, for example, will always looks in current directory before looking on PATH (and if I remember correctly OS/2 has the same rules, I don't remember PATH on OS/2 ever needing . in the PATH), so does CreateFile, so on win32 it's just what is expected. Sorry if I'm wrong though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 23:51 Message: Logged In: YES user_id=21627 What convention are you referring to? By convention, you have to specify executables in the current directory with ./ if you don't have "." in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 From noreply at sourceforge.net Wed Mar 7 20:38:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 11:38:31 -0800 Subject: [Patches] [ python-Patches-1576313 ] os.execvp[e] on win32 fails for current directory Message-ID: Patches item #1576313, was opened at 2006-10-12 19:57 Message generated for change (Comment added) made by mcmahon_m You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Borzenkov (snaury) Assigned to: Nobody/Anonymous (nobody) Summary: os.execvp[e] on win32 fails for current directory Initial Comment: By convention when program is executed by searching path, the first directory to be searched should be the current directory. However on python this is not true: 1.c: int main() { return 1; } test.py: import os os.execvp('1', ('1',)) result: Traceback (most recent call last): File "C:\1\test.py", line 2, in os.execvp('1',('1',)) File "D:\Programs\ActiveState\Python25\lib\os.py", line 348, in execvp _execvpe(file, args) File "D:\Programs\ActiveState\Python25\lib\os.py", line 386, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory Attached patch fixes this. ---------------------------------------------------------------------- Comment By: Mark Mc Mahon (mcmahon_m) Date: 2007-03-07 14:38 Message: Logged In: YES user_id=1424947 Originator: NO Yes of course! I had slightly misunderstood the original problem. I had thought it was execv/execve that had to have the full path, but I see that it is actually os._execvpe() that is only looking in explicit path entry locations for the file (and we need to add the implicit by allowing `file` to be found). ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2007-03-07 14:15 Message: Logged In: YES user_id=1197042 Originator: YES No, inserting '.' is unnecessary exactly because ntpath.join is working the way you described. On Windows and OS/2 'test' will mean 'test' in current directory, i.e. the expected result without any unnecessary characters prepended and without any unnecessary cycles since ntpath.join("", "whatever") is optimized in ntpath.join. ---------------------------------------------------------------------- Comment By: Mark Mc Mahon (mcmahon_m) Date: 2007-03-07 13:55 Message: Logged In: YES user_id=1424947 Originator: NO I don't know about OS/2 but standard windows definitely looks in the current folder first. Should the patch insert "." rather then ""? >>> import os.path >>> os.path.join("", "test") 'test' >>> os.path.join(".", "test") '.\\test' >>> ---------------------------------------------------------------------- Comment By: Alexey Borzenkov (snaury) Date: 2006-10-14 15:15 Message: Logged In: YES user_id=1197042 On win32 it is not so, execlp() in msvcrt, for example, will always looks in current directory before looking on PATH (and if I remember correctly OS/2 has the same rules, I don't remember PATH on OS/2 ever needing . in the PATH), so does CreateFile, so on win32 it's just what is expected. Sorry if I'm wrong though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-14 14:51 Message: Logged In: YES user_id=21627 What convention are you referring to? By convention, you have to specify executables in the current directory with ./ if you don't have "." in your path. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1576313&group_id=5470 From noreply at sourceforge.net Wed Mar 7 21:08:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 12:08:04 -0800 Subject: [Patches] [ python-Patches-1521051 ] Extra configurability for doctest TestCases Message-ID: Patches item #1521051, was opened at 2006-07-12 04:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Keith-Magee (freakboy) Assigned to: Nobody/Anonymous (nobody) Summary: Extra configurability for doctest TestCases Initial Comment: DocTestRunner can be modified by end users to override default testing behaviour when executing doctests. Similarly, DocTestCase can be extended to override default setup/teardown behaviour. However, when a DocTestSuite is used to discover doctests, it is not possible to specify a user-modified Runner or TestCase. This patch (against svn revision 46884 of Lib/doctest.py) enables end users to specify the class that is used to construct DocTest test cases, and the runner that is used to run DocTest test cases. By default, DocTestSuite will continue to instantiate DocTestRunner and DocTestCase instances as before. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-07 15:08 Message: Logged In: YES user_id=1344176 Originator: NO This looks good to me. Could you add some tests (to Lib/test/test_doctest.py) and update the docs (Doc/lib/libdoctest.tex)? Thanks for your contribution! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521051&group_id=5470 From noreply at sourceforge.net Wed Mar 7 21:14:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 12:14:29 -0800 Subject: [Patches] [ python-Patches-1545011 ] Fixes SocketServer Bug 1531963 Message-ID: Patches item #1545011, was opened at 2006-08-22 21:35 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Damon Kohler (damonkohler) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes SocketServer Bug 1531963 Initial Comment: Bug 1531963 is fixed by setting SocketServer.server_address = SocketServer.socket.getsockname() when the socket is bound. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-07 15:14 Message: Logged In: YES user_id=1344176 Originator: NO Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 From noreply at sourceforge.net Wed Mar 7 22:07:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 13:07:34 -0800 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 15:38 Message generated for change (Comment added) made by jyzude You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- >Comment By: Mike Verdone (jyzude) Date: 2007-03-07 14:07 Message: Logged In: YES user_id=584997 Originator: YES Removed unnecessary global statement in trackCall. Anything else? :-) File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:03 Message: Logged In: YES user_id=849994 Originator: NO Note that you don't need the global statement for callLst as you aren't rebinding it in the function. ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-05 23:38 Message: Logged In: YES user_id=584997 Originator: YES Hi collin, * I improved testMixIntsAndLongs. It now asserts things * assert is banished, replaced by the correct calls * the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect. * assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test. Let me know if you have further suggestions. File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 17:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Wed Mar 7 23:30:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 14:30:39 -0800 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23: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=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Wed Mar 7 23:56:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 14:56:07 -0800 Subject: [Patches] [ python-Patches-1660500 ] Hide iteration variable in list comprehensions Message-ID: Patches item #1660500, was opened at 2007-02-15 06:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1660500&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Coghlan (ncoghlan) Assigned to: Georg Brandl (gbrandl) Summary: Hide iteration variable in list comprehensions Initial Comment: This patch hides the iteration variable in list comprehensions. It adds new tests (modelled on the generator expression tests) and also removes some del statements from the standard library (where code previously cleaned up its own namespace). The changes to symtable.[ch] are more significant than strictly necessary - I found it necessary to spend some time cleaning up the code in order to understand what was needed for the list comprehension changes. Given that the 2.x and 3.0 compilers have already diverged fairly significantly, I don't believe this will make the process of keeping them in sync any more difficult than it is already. Assigning to Georg for initial review (as his set comprehensions patch provided a great deal of inspiration for this one). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 17:56 Message: Logged In: YES user_id=6380 Originator: NO Can't say that slowdown bothers me much, if it's typical. However I think you need to do a svn up in your workspace and regenerate the patch; I get FAILED message from patch on all the generated files and a few others: graminit.[ch], symtable.[ch], Python-ast.c, symbol.py. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-26 05:30 Message: Logged In: YES user_id=849994 Originator: NO Okay, I looked at the patch, and apart from a refleak in one of the compiler methods I couldn't find anything wrong. I then manually applied the rest of my set comprehension patch. The result is attached. Grammar, AST and compilation for comprehensions are now really unified. It passes the tests for listcomps, genexps and setcomps. I couldn't check properly for refleaks since e.g. test_genexps leaks in the branch head, as well as some other tests. I'm currently searching for the offending revision(s)... File Added: new-set-comps.diff ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-02-15 07:13 Message: Logged In: YES user_id=1038590 Originator: YES For reference, the original set comprehensions patch & the py3k list discussion: http://www.python.org/sf/1548388 http://mail.python.org/pipermail/python-3000/2006-December/005188.html Note that the current patch ended up looking a *lot* like the original one (the main difference specific to list comprehensions is that the temporary list is built in the inner scope and then returned rather than being passed in as an argument. Additionally, the code has been unified only for the symtable stage - the AST and compilation stages still use separate code for listcomps and genexps). It turns out that there are some really curly scoping problems that using a nested function deals with automatically (see the new test_listcomps.py in the patch for examples). Having a more efficient mechanism specifically for 'transient' scopes like this is an interesting idea, but it's far from easy (mainly because the variables in the scope still need to be properly visible in scopes it *contains*). Adding set comprehensions on top of this patch should be pretty straightforward. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-02-15 06:53 Message: Logged In: YES user_id=1038590 Originator: YES Speed measurements show a significant speed up over trunk & Python 2.4 for module/class level code: (Python 2.4)$ python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 239 msec per loop (Python 2.x trunk)$ ./python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 193 msec per loop (Python 3000)$ ./python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 176 msec per loop This is almost certainly due to the variables and the list object becoming function locals. There is a slowdown inside a function (but we are still faster than Python 2.4): (Python 2.4)$ python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 259 msec per loop (Python 2.x trunk)$ ./python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 176 msec per loop (Python 3000)$ ./python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 185 msec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1660500&group_id=5470 From noreply at sourceforge.net Thu Mar 8 00:09:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 15:09:22 -0800 Subject: [Patches] [ python-Patches-1492509 ] Unification of list-comp and for syntax Message-ID: Patches item #1492509, was opened at 2006-05-21 11:06 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492509&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Unification of list-comp and for syntax Initial Comment: The following patch adds the ability for: for in if : to the Python core. This unifies the syntax of list/generator comprehensions and the for statement somewhat, because both now accept conditions which produce an immediate continue. I've posted a PEP to python-dev, which details the changes this patch makes (which are all backwards-compatible). The patch doesn't try to address more than the actual code required to make this feature work yet (except for changes to Modules/parsermodule.c and Doc/ref/ref7.tex, which details the for statement). If there's consensus on this feature, I'll gladly produce more documentation. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-07 18:09 Message: Logged In: YES user_id=1344176 Originator: NO This was rejected by the BDFL in http://mail.python.org/pipermail/python-dev/2006-May/065090.html; closing. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-24 02:10 Message: Logged In: YES user_id=791932 Sure, you can wrap the iterable, or you can even do: if x in y: if not x: continue ... or if x in y: if x: ... without using any form of "iterator magic". Read my PEP-xxx on py-dev, and my explanation there of why I think this is a "good thing"(TM), but I won't go explain it here again, because generally people have told be to drop it. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-23 16:14 Message: Logged In: YES user_id=764593 It seems I misread what the intent was -- I was thinking of the if as guarding the entire for loop, not just a single iteration. Because of this confusion, I have to be -1. Is there a reason you can't just wrap your iterable sequence with another iterator? for x in (candidate for candidate in fullseq if test): ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-23 15:53 Message: Logged In: YES user_id=764593 I'm not loving the interaction with conditional expressions. for x in (1,2,3) if test else (3,2,1): I suppose this techically isn't ambiguous because else is a keyword. On the other hand, you could do it now using he if-else for x in real_seq if test else (): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492509&group_id=5470 From noreply at sourceforge.net Thu Mar 8 00:09:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 15:09:38 -0800 Subject: [Patches] [ python-Patches-1669539 ] Change (fix!) os.path.isabs() semantics on Win32 Message-ID: Patches item #1669539, was opened at 2007-02-26 23:07 Message generated for change (Comment added) made by jongfoster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: Change (fix!) os.path.isabs() semantics on Win32 Initial Comment: Hi, I consider this to be a bug in os.path.isabs(): PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32. >>> import os.path >>> s = '\\Python25' >>> os.path.isabs(s) True >>> os.path.abspath(s) 'C:\\Python25' >>> os.chdir('d:') >>> os.path.abspath(s) 'D:\\Python25' >>> If s is really an absolute path as isabs() claims, then why does abspath() return a different path (i.e. not s)? And worse, note that a call to os.chdir() changes the meaning of s! So s is clearly not an absolute path, and isabs() is wrong. It turns out that on Windows there are really 4 different kinds of paths: 1) Completely relative, e.g. foo\bar 2) Completely absolute, e.g. c:\foo\bar or \\server\share 3) Halfbreeds with no drive, e.g. \foo\bar 4) Halfbreeds relative to the current working directory on a specific drive, e.g. c:foo\bar Python 2.5's os.path.isabs() method considers both (2) and (3) to be absolute; I agree with the classification of (2) but strongly disagree about case (3). Oh, and os.path.join is also broken, e.g. os.path.join('foo', 'a:bar') gives 'foo\\a:bar', which is an invalid path. Another consequence of this is that os.path.isabs() is not enough to classify paths. Sometimes you really need a relative path, so we really need (at least) a new os.path.isrelative(), which can return "not isabs(s)" on POSIX platforms, and do the right thing on Win32. The attached patch: - Changes the behaviour of os.path.isabs() and os.path.join() on Win32, to classify pathnames as described above (including adding UNC support) - Adds os.path.isrelative() on all platforms - Changes a couple of Win32 os.path tests where I have deliberately broken backward compatibility - Adds lots of new tests for these 3 functions on Win32 This does change the behaviour of isabs(), and it is possible that existing applications might be depending on the current behaviour. Silently changing the behaviour might break those applications. I'm not sure what the best course of action is - applying this for 2.6, putting a new API in (os.path.isreallyabs()?), or waiting for Python 3000...? Kind regards, Jon Foster ---------------------------------------------------------------------- >Comment By: Jon Foster (jongfoster) Date: 2007-03-07 23:09 Message: Logged In: YES user_id=199289 Originator: YES Thanks for the comments. Updated patch attached, which includes the doc changes. File Added: win32_absolute_paths_2.patch ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 10:32 Message: Logged In: YES user_id=18139 Originator: NO There is an interesting thread on python-dev right now about possibly tweaking the behavior of splitext() in 2.6. So maybe there is hope after all. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 04:01 Message: Logged In: YES user_id=18139 Originator: NO Thanks for submitting this. Nice summary of the different cases. I think very few people have given this that much thought. :) You need a patch for the docs if you want this to even get considered. Then the main obstacle is convincing the team that the nice new logical behavior is worth the breakage. I would be surprised if it got through. And Python 3000 is not going to be the "subtle breakage" release. I would give you better odds if your patch created new APIs instead, and *documented* exactly what's useful about the model you're suggesting. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-02-26 23:15 Message: Logged In: YES user_id=199289 Originator: YES P.S. The patch is against Python SVN trunk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 From noreply at sourceforge.net Thu Mar 8 00:11:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 15:11:19 -0800 Subject: [Patches] [ python-Patches-1669481 ] subprocess: Support close_fds on Win32 Message-ID: Patches item #1669481, was opened at 2007-02-26 21:47 Message generated for change (Comment added) made by jongfoster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: Support close_fds on Win32 Initial Comment: There is an existing close_fds parameter to the subprocess.Popen() constructor that prevents FDs being copied to the child process on UNIX. This patch makes that parameter also work on Windows (with a caveat). Setting this parameter on Windows was explicitly prohibited by the code, because it prevents redirecting stdin/stdout/stderr. However, the check is too restrictive; it is perfectly reasonable to set this flag if you are not redirecting anything. That is what this patch does. The behaviour is unchanged if you are on Windows, set this flag, and simultaneously try to redirect stdin/stdout/stderr: the call will fail with an exception. This patch is against Python SVN trunk. Kind regards, Jon Foster ---------------------------------------------------------------------- >Comment By: Jon Foster (jongfoster) Date: 2007-03-07 23:11 Message: Logged In: YES user_id=199289 Originator: YES I've been reading the general discussion on python-dev about patches needing documentation and tests. So here's an updated patch that includes docs and tests. File Added: subprocess_win32_close_handles_2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470 From noreply at sourceforge.net Thu Mar 8 00:29:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 15:29:43 -0800 Subject: [Patches] [ python-Patches-1517586 ] Patch to commands.py to enable callback support Message-ID: Patches item #1517586, was opened at 2006-07-05 17:31 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517586&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brad Doctor (bdoctor) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to commands.py to enable callback support Initial Comment: This is a patch to commands.py to enable callback support, which is very useful for long-running commands. Whenever there is stdout from the process the callback is fed whatever it got. Example usage: import commands cmd = 'top -b -n2' def fancy(out): print 'GOT(%s)' % out.strip() commands.cb = fancy (s,o) = commands.getstatusoutput(cmd) print 'OUTPUT (%s)' % o Please consider adding this. The existing API is not changed, however as you can see it is simple to use the callback. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 00:29 Message: Logged In: YES user_id=51702 Originator: NO Your semantic for the cb name seems kind of arbitrary. Why is it called for each line of the output and only once with all the output. Plus, iterating through the output line for line can make it much slower than reading it all at once. Also, the next time you run getstatusoutput(), maybe even from another module, the callback will still be called. That could be unexpected. Plus commands is almost deprecated in favour of subprocess. I recommend rejecting this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517586&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:04:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:04:28 -0800 Subject: [Patches] [ python-Patches-1491866 ] Complex representation Message-ID: Patches item #1491866, was opened at 2006-05-19 23:27 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491866&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Complex representation Initial Comment: As per request on c.l.p: http://groups.google.de/group/comp.lang.python/browse_thread/thread/26c93fefefd3a100/bf1924ce28fac1ac?hl=de#bf1924ce28fac1ac I've implemented a small patch to change the output of repr(x) for complex variables, so that complex(repr(x)) works for any complex x. This changes the output of repr(x) to '+j' without brackets, but leaves the string output untouched. This change of behaviour would be in line with int(repr(x)) and float(repr(x)) being defined for any int or float x, repectively. I don't know whether this patch is sensible, and whether it breaks any current code, because (for example) eval("5*%r" % (1+2j,)) won't work properly anymore, or whether it'd be more sensible to change the complex constructor to also accept a bracketed expression. I'll attach a patch to do the latter later. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 01:04 Message: Logged In: YES user_id=51702 Originator: NO I have applied this patch in 2.6 and it seem to work as intended. The test_complex.py unit tests all pass. I guess the change could be useful if you are are serializing and desearializing lists of complex numbers. I think it should be applied. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-20 13:20 Message: Logged In: YES user_id=791932 The attached patch is a revised version of the patch to the complex constructor to accept bracketed string expressions, which also adds documentation changes (whatsnew25). Anyway, I personally also find this to be the "better" way, so I've removed the repr-changing patch. And, calling it a bug was by accident: I should've rather called it tracker item, which is pretty synonymous for me. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-05-20 07:24 Message: Logged In: YES user_id=593130 (The current behavior is not a bug, nor is this patch submission a bug report, so let us omit that word.) I think your example suggests why complexes are printed in parens, so I think enhancing complex() to accept such is the better approach if any change is to be made. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-20 00:28 Message: Logged In: YES user_id=791932 The second patch (python-complex-constructor.diff) changes the constructor to accept bracketed complex numbers which are enclosed in a single bracket. I'd rather say this is the better appropach to have complex(repr(x)) work, but I leave both patches attached to this bug. The latter patch also creates test cases testing for formatting errors with bracketed expressions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491866&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:28:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:28:13 -0800 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:36:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:36:58 -0800 Subject: [Patches] [ python-Patches-1669539 ] Change (fix!) os.path.isabs() semantics on Win32 Message-ID: Patches item #1669539, was opened at 2007-02-27 10:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: Change (fix!) os.path.isabs() semantics on Win32 Initial Comment: Hi, I consider this to be a bug in os.path.isabs(): PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32. >>> import os.path >>> s = '\\Python25' >>> os.path.isabs(s) True >>> os.path.abspath(s) 'C:\\Python25' >>> os.chdir('d:') >>> os.path.abspath(s) 'D:\\Python25' >>> If s is really an absolute path as isabs() claims, then why does abspath() return a different path (i.e. not s)? And worse, note that a call to os.chdir() changes the meaning of s! So s is clearly not an absolute path, and isabs() is wrong. It turns out that on Windows there are really 4 different kinds of paths: 1) Completely relative, e.g. foo\bar 2) Completely absolute, e.g. c:\foo\bar or \\server\share 3) Halfbreeds with no drive, e.g. \foo\bar 4) Halfbreeds relative to the current working directory on a specific drive, e.g. c:foo\bar Python 2.5's os.path.isabs() method considers both (2) and (3) to be absolute; I agree with the classification of (2) but strongly disagree about case (3). Oh, and os.path.join is also broken, e.g. os.path.join('foo', 'a:bar') gives 'foo\\a:bar', which is an invalid path. Another consequence of this is that os.path.isabs() is not enough to classify paths. Sometimes you really need a relative path, so we really need (at least) a new os.path.isrelative(), which can return "not isabs(s)" on POSIX platforms, and do the right thing on Win32. The attached patch: - Changes the behaviour of os.path.isabs() and os.path.join() on Win32, to classify pathnames as described above (including adding UNC support) - Adds os.path.isrelative() on all platforms - Changes a couple of Win32 os.path tests where I have deliberately broken backward compatibility - Adds lots of new tests for these 3 functions on Win32 This does change the behaviour of isabs(), and it is possible that existing applications might be depending on the current behaviour. Silently changing the behaviour might break those applications. I'm not sure what the best course of action is - applying this for 2.6, putting a new API in (os.path.isreallyabs()?), or waiting for Python 3000...? Kind regards, Jon Foster ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-03-08 11:36 Message: Logged In: YES user_id=14198 Originator: NO I agree the current behaviour is not ideal - but the right way forward isn't clear. Note the existing (strange) behaviour of os.path.join: >>> os.path.join("c:\\", "\\a") 'c:\\a' >>> os.path.join("c:\\foo", "\\a") '\\a' if isabs('\\a') returns False, there is almost an expectation that the last example should return 'c:\\foo\\a' - but that would almost never give what was expected. 'c:\\a' seems the correct result, but my quick scan of the test code in the patch shows this isn't exercised. FWIW, about the only common use of isabs() in my code is something like: log_directory = get_option_from_config_file(...) if not os.path.isabs(log_directory): # make log_directory absolute based on app directory. log_directory = os.path.join(app_directory, log_directory) Best I can tell, the above would not break if isabs('/foo') started returning False, so long as os.path.join('c:\\foo', '\\bar') resulted in 'c:\\bar'. Off the top-of-my-head, another strategy may be to introduce isrelative() in 2.6, and in 2.7 introduce a warning when isabs() is passed one of the halfbreeds, warning that 2.8 will return a different value, and pointing to the new isrelative(). 2.8 then gets the full, 'correct' implementation as described here. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-03-08 10:09 Message: Logged In: YES user_id=199289 Originator: YES Thanks for the comments. Updated patch attached, which includes the doc changes. File Added: win32_absolute_paths_2.patch ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 21:32 Message: Logged In: YES user_id=18139 Originator: NO There is an interesting thread on python-dev right now about possibly tweaking the behavior of splitext() in 2.6. So maybe there is hope after all. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 15:01 Message: Logged In: YES user_id=18139 Originator: NO Thanks for submitting this. Nice summary of the different cases. I think very few people have given this that much thought. :) You need a patch for the docs if you want this to even get considered. Then the main obstacle is convincing the team that the nice new logical behavior is worth the breakage. I would be surprised if it got through. And Python 3000 is not going to be the "subtle breakage" release. I would give you better odds if your patch created new APIs instead, and *documented* exactly what's useful about the model you're suggesting. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-02-27 10:15 Message: Logged In: YES user_id=199289 Originator: YES P.S. The patch is against Python SVN trunk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:41:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:41:11 -0800 Subject: [Patches] [ python-Patches-1522059 ] Remove operator.truth() and operator.abs() Message-ID: Patches item #1522059, was opened at 2006-07-13 16:10 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Guido van Rossum (gvanrossum) Summary: Remove operator.truth() and operator.abs() Initial Comment: operator.truth() and operator.abs() are both intended to be passed to higher-order function like map, reduce, filter, etc. However, both of these are redundant with the builtins bool() and abs(), respectively. The attached patch will remove operator.truth() and .abs() for Python 3000. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-07 19:41 Message: Logged In: YES user_id=1344176 Originator: YES Rejected by the BDFL in http://mail.python.org/pipermail/python-3000/2007-March/006081.html, closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522059&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:45:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:45:01 -0800 Subject: [Patches] [ python-Patches-1522704 ] XML Test Runner for unittest module Message-ID: Patches item #1522704, was opened at 2006-07-14 14:02 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522704&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Sebastian Rittau (srittau) Assigned to: Nobody/Anonymous (nobody) Summary: XML Test Runner for unittest module Initial Comment: JUnit features an XML Test Runner that enables test output in XML format. This is very useful for buildbots and similar automated setups. PyUnit (the unittest module) lacks this capability. The attached file implements such an XML Test Runner and the matching unit tests. I did not try to generate a patch to the current SVN version and leave that to more capable hand. I think the current unittest module should probably changed into a unittest package like this: unittest/__init__.py - the current unittest.py file unittest/xmlrunner.py - the new XML runner Later __init__.py could be split into even more files like textrunner.py etc. I would like to hear about any improvements that the patch needs (even minor ones). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-07 19:45 Message: Logged In: YES user_id=1344176 Originator: NO As noted in an earlier comment, this needs to spend some time out in the Cheeseshop and build up a following before being included in the stdlib; closing. ---------------------------------------------------------------------- Comment By: Sebastian Rittau (srittau) Date: 2006-07-27 05:22 Message: Logged In: YES user_id=47380 I attached an updated patch. It includes feedback by Mirko Friedenhagen: XmlTestRunner.run now returns the TestResult instead of a boolean, it is now possible to stream multiple test results into a single XML stream, since the XML declaration is left out, if no new file is created, and XmlTestRunner now gracefully recovers from tests overriding sys.stdout and sys.stderr. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-17 14:02 Message: Logged In: YES user_id=1344176 I'd recommend that you release this somewhere like PyPI (http://cheeseshop.python.org/pypi) and see how well it does. If it flies off the shelf, then it could be considered for inclusion in the stdlib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522704&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:46:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:46:23 -0800 Subject: [Patches] [ python-Patches-1671314 ] New File I/O type for Python 3000, plus .h and unit tests Message-ID: Patches item #1671314, was opened at 2007-02-28 18:08 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Daniel Stutzbach (agthorr) >Assigned to: Guido van Rossum (gvanrossum) Summary: New File I/O type for Python 3000, plus .h and unit tests Initial Comment: Here is my implementation of a raw File I/O type for Python 3000, along with unit tests. The tests for repr() fail because I'm not 100% sure what repr() should return (in particular, whether the type should bother remembering the filename just to return in repr()). There are comments at the top of the .c file explaining what remains to be done. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 19:46 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54214. I tweaked a few things; for example O_APPEND doesn't have the semantics we want (it appends on *every write*). I turned it into a module and renamed it to _fileio, the class to _FileIO. The io.py module now imports this and uses it as a base class for *its* FileIO class, if the import works. There are plenty of XXX things. I'll try to get large file support working next; as long as off_t is a 64-bit int this should just work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 From noreply at sourceforge.net Thu Mar 8 01:52:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 16:52:45 -0800 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 18:25 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 19:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-07 19:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Thu Mar 8 05:36:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 07 Mar 2007 20:36:03 -0800 Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool Message-ID: Patches item #1673122, was opened at 2007-03-03 15:33 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: libtool Initial Comment: When the framewok is built on Mac OS X, the Mac OS X specific libtool is used. However, if the GNU libtool is on the PATH first, python refuses to build. This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file. That way, someone can have GNU libtool on the PATH first and still build python. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 23:36 Message: Logged In: YES user_id=18139 Originator: NO It works. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 10:38 Message: Logged In: YES user_id=18139 Originator: NO OK, I don't see why not. I'll try this out tonight, just to make sure it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 From ddszdo at auna.net Thu Mar 8 05:53:11 2007 From: ddszdo at auna.net (Rosa & Emma) Date: Wed, 07 Mar 2007 20:53:11 -0800 Subject: [Patches] Madeleine, do you wanna get 722.- EURO Message-ID: <0f6701c76141$7b2ec660$dd48b785@IFOXFGL> Hello Madeleine, Madeleine, do you wanna get 722.- EURO Get your start bonus now: - Visit our website http://milkandre.com/micro/16/ and download the playing module in your language (no installation needed) - Register as guest or player......and start winning Cheers Rosa & Emma -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070307/25e1ba45/attachment.html From noreply at sourceforge.net Thu Mar 8 09:08:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 00:08:35 -0800 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 22:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 08:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Thu Mar 8 14:08:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 05:08:02 -0800 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 11:48 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: TH (therve) Date: 2007-03-08 13:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 17:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 18:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 18:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 13:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 00:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Thu Mar 8 15:25:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 06:25:21 -0800 Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool Message-ID: Patches item #1673122, was opened at 2007-03-03 15:33 Message generated for change (Comment added) made by herrwitten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: libtool Initial Comment: When the framewok is built on Mac OS X, the Mac OS X specific libtool is used. However, if the GNU libtool is on the PATH first, python refuses to build. This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file. That way, someone can have GNU libtool on the PATH first and still build python. ---------------------------------------------------------------------- >Comment By: Witten (herrwitten) Date: 2007-03-08 09:25 Message: Logged In: YES user_id=1595909 Originator: YES Great! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 23:36 Message: Logged In: YES user_id=18139 Originator: NO It works. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 10:38 Message: Logged In: YES user_id=18139 Originator: NO OK, I don't see why not. I'll try this out tonight, just to make sure it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 From noreply at sourceforge.net Thu Mar 8 18:32:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 09:32:33 -0800 Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test coverage improvement Message-ID: Patches item #1675424, was opened at 2007-03-06 22:14 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile tweaks and test coverage improvement Initial Comment: This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests: - appending to an existing zipfile - appending to an existing file that is not a zipfile - check that calling ZipFile.write without arcname specified produces the expected result - check that files within a Zip archive can have different compression options - check that trying to call write() on a readonly ZipFile object raises a RuntimeError - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension - check that bad modes passed to ZipFile constructor are caught - check that bad modes passed to ZipFile.open are caught - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError - check that bad compression methods passed to ZipFile.open are caught - check that a filename containing a null byte is properly terminated These other miscellaneous changes were made to test_zipfile.py: - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142) - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr. - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data. The following changes were made to zipfile.ZipFile: - A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation) - ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError) - checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant) There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-) If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know. I can add such documentation changes if necessary. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-08 12:32 Message: Logged In: YES user_id=1115903 Originator: YES I've modified ZipFile.getinfo to raise a KeyError instead of a RuntimeError. It would appear that RuntimeError is what stuff in this module raises for IO problems, so I'm assuming this means we're stuck with it (even though I agree that IOError would seem more appropriate for trying to write to closed files). I documented some of the exceptions raised by various methods. However, I focused mainly on the items listed in my original post, so there's probably code that raise exceptions that still aren't properly documented. I also noticed that the existing docs list "error" as the exception that is raised for bad zip files. Since no such exception is raised, I included a change to the docs so that it says BadZipfile instead. I included a change to the NEWS file as well, since it was mentioned in py-dev discussion that such updates can be helpful. :-) File Added: zipfile_coverage2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:18 Message: Logged In: YES user_id=849994 Originator: NO I'd continue raising KeyError in the case the info wasn't found, but set a different message so that backwards compatibility doesn't break. In any case, it would be good to document it. Isn't raising IOError customary for writing to closed files? (If zipfile never raises IOError elsewhere, this is probably not applicable.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:01:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:01:43 -0800 Subject: [Patches] [ python-Patches-1670765 ] email.Generator: no header wrapping for multipart/signed Message-ID: Patches item #1670765, was opened at 2007-02-28 07:04 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670765&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin von Gagern (gagern) Assigned to: Nobody/Anonymous (nobody) Summary: email.Generator: no header wrapping for multipart/signed Initial Comment: The body of a multipart/signed message has to remain unmodified for the signature to stay intact. Rewrapping headers of nested MIME parts breaks signatures. So I disabled header rewrapping for multipart/signed, by adding a new handler to the email.Generator class. There still remains an issue about leading spaces in header values breaking signatures. The supplied patch is against the latest subversion sources, r54016. Related issues: Python bug #968430 http://tinyurl.com/2973or Mailman bug #815297 http://tinyurl.com/2a8dta ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:01 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! Could you work up some tests for this, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670765&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:19:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:19:52 -0800 Subject: [Patches] [ python-Patches-1512007 ] ast branch changed interactive module name Message-ID: Patches item #1512007, was opened at 2006-06-25 00:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: ast branch changed interactive module name Initial Comment: Python 2.4 displays tracebacks interactively like this: Traceback (most recent call last): File "", line 1, in ? ZeroDivisionError: integer division or modulo by zero Python 2.5b1 displays them like this: Traceback (most recent call last): File "", line 1, in ZeroDivisionError: integer division or modulo by zero This doesn't seem likely a particularly good change and it breaks tests which rely on the particular spelling of this message. I probably wouldn't mind the change if it were to a more useful string than "", but "?" seemed better than the current state. If anything is /not/ a module, it's an interactive session with the interpreter. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:19 Message: Logged In: YES user_id=1344176 Originator: NO 1) An interpreter session is essentially a module that the user types in, one statement at a time. 2) "?" tells me considerably less about where the error occurred than does "". "?" could mean anything. 3) Since Python 2.5 has already been released with the objected-to behavior, I'd say it's incredibly unlikely that this change will be reverted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512007&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:25:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:25:55 -0800 Subject: [Patches] [ python-Patches-1439312 ] Patch for bug 1438185: os.renames deletes junction points Message-ID: Patches item #1439312, was opened at 2006-02-26 18:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1439312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 1438185: os.renames deletes junction points Initial Comment: os.removedirs assumes that the os will throw an exception if you try to rmdir an non-empty directory. Although this is a bit of a grey area, windows junction points will be delete themselves even if the junction point's destination has files. os.renames() relied on this behaviour and caused the failure. This patch runs an explicit os.listdir() check when calling os.removeddirs() to verify that a target directory is really empty before deleting. After this patch, manually running os.rmdir() against a junction point will still just remove the junction point like I would expect. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:25 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! I realize testing this kind of OS-specific behaviour is tricky, but could you work up some regression tests for this patch? Also, you should send an email to python-dev (http://mail.python.org/mailman/listinfo/python-dev) about this; someone more knowledgeable about NTFS than I am should take a look at this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1439312&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:27:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:27:57 -0800 Subject: [Patches] [ python-Patches-1414934 ] Patch for bug #1380970 Message-ID: Patches item #1414934, was opened at 2006-01-25 15:52 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1414934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug #1380970 Initial Comment: The split and rsplit methods for both string and unicode types currently do not live up to their documentation. The docs say (quoting from docs.python.org/dev): """ If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends. """ As of svn revision 42185, these methods only strip whitespace from one end. The attached patch makes all four methods (str.split, str.rsplit, unicode.split, unicode.rsplit) remove whitespace from both ends of the string. The patch also modifies Lib/test/string_tests.py to add checks for this to the regression suite. The patch passes the full regression suite. PS: if I could get a review of patch #1412451, that would be smashing. Thanks. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:27 Message: Logged In: YES user_id=1344176 Originator: YES Raymond Hettinger rejected the referenced bug report, so I'm marking this as "rejected", too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1414934&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:36:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:36:19 -0800 Subject: [Patches] [ python-Patches-1639973 ] email.utils.parsedate documentation Message-ID: Patches item #1639973, was opened at 2007-01-19 20:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Nobody/Anonymous (nobody) Summary: email.utils.parsedate documentation Initial Comment: See bug 1629566 (python.org/sf/1629566) for discussion. This patch eliminates any ambiguity in the documentation regarding which fields of the time tuple it refers to. This patch specifies the documentation in both librfc822.tex and emailutil.tex ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:36 Message: Logged In: YES user_id=1344176 Originator: NO Where do the "tm_wday", "tm_yday", "tm_isdst" names come from? I don't see them in the referenced RFC, nor anywhere else in the patched docs. Why not just make a note that 6, 7 and 8 are counted from zero? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:42:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:42:25 -0800 Subject: [Patches] [ python-Patches-1439312 ] Patch for bug 1438185: os.renames deletes junction points Message-ID: Patches item #1439312, was opened at 2006-02-26 23:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1439312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Grant Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug 1438185: os.renames deletes junction points Initial Comment: os.removedirs assumes that the os will throw an exception if you try to rmdir an non-empty directory. Although this is a bit of a grey area, windows junction points will be delete themselves even if the junction point's destination has files. os.renames() relied on this behaviour and caused the failure. This patch runs an explicit os.listdir() check when calling os.removeddirs() to verify that a target directory is really empty before deleting. After this patch, manually running os.rmdir() against a junction point will still just remove the junction point like I would expect. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 18:42 Message: Logged In: YES user_id=849994 Originator: NO I don't think you could create NTFS junction points from Python without resorting to ctypes hackery. Or is there some tool shipped with Windows to manipulate them? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 18:25 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! I realize testing this kind of OS-specific behaviour is tricky, but could you work up some regression tests for this patch? Also, you should send an email to python-dev (http://mail.python.org/mailman/listinfo/python-dev) about this; someone more knowledgeable about NTFS than I am should take a look at this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1439312&group_id=5470 From noreply at sourceforge.net Thu Mar 8 19:54:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 10:54:37 -0800 Subject: [Patches] [ python-Patches-1369028 ] Module fixedlenfields for standard lib Message-ID: Patches item #1369028, was opened at 2005-11-29 05:54 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1369028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: Module fixedlenfields for standard lib Initial Comment: Module fixedlenfields for reading and splitting text files with fixed-length fields. It's inspired by module csv, implemented as iterator and I'm using it exactly like module csv. I've used Python 2.4.2 to develop it. Please consider it for inclusion into Python's standard lib. I'll grant copyright to Python Software Foundation. Ciao, Michael. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:54 Message: Logged In: YES user_id=1344176 Originator: NO Modules submitted for stdlib inclusion should spend some time out in the wild first, attracting a userbase and proving their usefulness. I notice you've posted fixedlenfields to PyPI (http://cheeseshop.python.org/pypi/fixedlenfields/), but since its download URL points to this tracker item, I'm assuming you haven't updated it over the last 15+ months. If fixedlenfields has indeed built up a following over that time, you should do the following and submit a new patch: 1) Update the patch to work with Python 2.5+; it currently doesn't compile with Python 2.5 or 2.6. 2) Split the test suite out into a separate test file based on the unittest module. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1369028&group_id=5470 From noreply at sourceforge.net Thu Mar 8 20:09:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 11:09:43 -0800 Subject: [Patches] [ python-Patches-1491866 ] Complex representation Message-ID: Patches item #1491866, was opened at 2006-05-19 17:27 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491866&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Complex representation Initial Comment: As per request on c.l.p: http://groups.google.de/group/comp.lang.python/browse_thread/thread/26c93fefefd3a100/bf1924ce28fac1ac?hl=de#bf1924ce28fac1ac I've implemented a small patch to change the output of repr(x) for complex variables, so that complex(repr(x)) works for any complex x. This changes the output of repr(x) to '+j' without brackets, but leaves the string output untouched. This change of behaviour would be in line with int(repr(x)) and float(repr(x)) being defined for any int or float x, repectively. I don't know whether this patch is sensible, and whether it breaks any current code, because (for example) eval("5*%r" % (1+2j,)) won't work properly anymore, or whether it'd be more sensible to change the complex constructor to also accept a bracketed expression. I'll attach a patch to do the latter later. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 14:09 Message: Logged In: YES user_id=1344176 Originator: NO Works for me. I'll commit this for 2.6 (no backport) if there are no objections. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-07 19:04 Message: Logged In: YES user_id=51702 Originator: NO I have applied this patch in 2.6 and it seem to work as intended. The test_complex.py unit tests all pass. I guess the change could be useful if you are are serializing and desearializing lists of complex numbers. I think it should be applied. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-20 07:20 Message: Logged In: YES user_id=791932 The attached patch is a revised version of the patch to the complex constructor to accept bracketed string expressions, which also adds documentation changes (whatsnew25). Anyway, I personally also find this to be the "better" way, so I've removed the repr-changing patch. And, calling it a bug was by accident: I should've rather called it tracker item, which is pretty synonymous for me. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-05-20 01:24 Message: Logged In: YES user_id=593130 (The current behavior is not a bug, nor is this patch submission a bug report, so let us omit that word.) I think your example suggests why complexes are printed in parens, so I think enhancing complex() to accept such is the better approach if any change is to be made. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-19 18:28 Message: Logged In: YES user_id=791932 The second patch (python-complex-constructor.diff) changes the constructor to accept bracketed complex numbers which are enclosed in a single bracket. I'd rather say this is the better appropach to have complex(repr(x)) work, but I leave both patches attached to this bug. The latter patch also creates test cases testing for formatting errors with bracketed expressions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491866&group_id=5470 From noreply at sourceforge.net Thu Mar 8 20:27:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 11:27:55 -0800 Subject: [Patches] [ python-Patches-1618485 ] add None values in SimpleXMLRPCServer Message-ID: Patches item #1618485, was opened at 2006-12-18 20:01 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1618485&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Maximiliano Curia (maxy) Assigned to: Nobody/Anonymous (nobody) Summary: add None values in SimpleXMLRPCServer Initial Comment: Using SimpleXMLRPCServer I've been having some problems when trying to use "None" values. Apparently it uses a "dumps" function from xmlrpclib to generate the response. This function does support "None" values, but needs an extra parameter to allow them. The patch attached adds a new parameter (allow_none) to the constructor of SimpleXMLRPCServer, that when set is passed to the xmlrpclib.dumps call. This fixes the problem in a consistent way with the usage of xmlrpclib. It might be a better solution to support "None" values by default in SimpleXMLRPCServer and xmlrpclib. The patch is for python 2.4, but should probably be ported to 2.5 and 2.6. Thanks. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 14:27 Message: Logged In: YES user_id=1344176 Originator: NO Something like this (patch #893642) has already been applied and is present in Python 2.5+. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-06 08:53 Message: Logged In: YES user_id=1038797 Originator: NO As it's a new feature, it can probably only be in 2.6. Otherwise, that seems good, are you willing to write tests for this ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1618485&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:15:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:15:26 -0800 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:27:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:27:34 -0800 Subject: [Patches] [ python-Patches-1671314 ] New File I/O type for Python 3000, plus .h and unit tests Message-ID: Patches item #1671314, was opened at 2007-02-28 18:08 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Daniel Stutzbach (agthorr) Assigned to: Guido van Rossum (gvanrossum) Summary: New File I/O type for Python 3000, plus .h and unit tests Initial Comment: Here is my implementation of a raw File I/O type for Python 3000, along with unit tests. The tests for repr() fail because I'm not 100% sure what repr() should return (in particular, whether the type should bother remembering the filename just to return in repr()). There are comments at the top of the .c file explaining what remains to be done. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:27 Message: Logged In: YES user_id=1344176 Originator: NO Reopening. I'm seeing build warnings and test failures related to the FileIO work when Python is configured with --with-pydebug. When compiling Modules/_fileio.c, gcc complains about "PyFileIO_Type undeclared"; because the _fileio module fails to build, both test_io and test_fileio fail. This occurs even after "make distclean". I have r54216 of p3yk, gcc 3.4.6. _fileio.c compiles successfully if Python is configured without --with-pydebug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 19:46 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54214. I tweaked a few things; for example O_APPEND doesn't have the semantics we want (it appends on *every write*). I turned it into a module and renamed it to _fileio, the class to _FileIO. The io.py module now imports this and uses it as a base class for *its* FileIO class, if the import works. There are plenty of XXX things. I'll try to get large file support working next; as long as off_t is a 64-bit int this should just work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:28:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:28:46 -0800 Subject: [Patches] [ python-Patches-1669481 ] subprocess: Support close_fds on Win32 Message-ID: Patches item #1669481, was opened at 2007-02-26 21:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess: Support close_fds on Win32 Initial Comment: There is an existing close_fds parameter to the subprocess.Popen() constructor that prevents FDs being copied to the child process on UNIX. This patch makes that parameter also work on Windows (with a caveat). Setting this parameter on Windows was explicitly prohibited by the code, because it prevents redirecting stdin/stdout/stderr. However, the check is too restrictive; it is perfectly reasonable to set this flag if you are not redirecting anything. That is what this patch does. The behaviour is unchanged if you are on Windows, set this flag, and simultaneously try to redirect stdin/stdout/stderr: the call will fail with an exception. This patch is against Python SVN trunk. Kind regards, Jon Foster ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 20:28 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good; unfortunately I don't have a Windows to test it, otherwise I'd apply it. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-03-07 23:11 Message: Logged In: YES user_id=199289 Originator: YES I've been reading the general discussion on python-dev about patches needing documentation and tests. So here's an updated patch that includes docs and tests. File Added: subprocess_win32_close_handles_2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669481&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:46:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:46:06 -0800 Subject: [Patches] [ python-Patches-1492240 ] Socket-object convenience function: getpeercred(). Message-ID: Patches item #1492240, was opened at 2006-05-20 17:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492240&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Socket-object convenience function: getpeercred(). Initial Comment: The attached patch implements a convenience function called getpeercred() which internally calls getsockopt(SO_PEERCRED) to retrieve the credentials (pid, uid and gid) of the remote process a socket is attached to, in case the remote end is local. This currently (AFAIK) only works (properly) on Linux 2.4+, but might work on BSD-style systems too. The returned data is wrapped in a new ucred type, which is subclassable to implement additional convenience functions in Lib/socket.py. The patch updates the socket module, the test suite, the documentation (including whatsnew), and adds a configure check for the definition of struct ucred in sys/socket.h, which is the default place for struct ucred if it is available. If struct ucred is not available on the current system, getpeercred() is made a dummy method, which returns a python-defined ucred type which contains pid=0, uid=gid=-1, which are the default values returned under Linux when the call fails because there is no credentials data associated with the socket. The decision to move the data to a separate type was made with respect to the ability to use struct ucred under other systems in a SCM_CREDENTIALS sendmsg() call. I'll post the implementation of sendmsg() and recvmsg() as a separate tracker item, but the latter patch will rely on the inclusion of this patch. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:46 Message: Logged In: YES user_id=1344176 Originator: NO I'm uncomfortable with including something that only works on certain versions of a single platform. Are there any other functions or methods (not modules) that are only available for Linux? I can think of a number of places flagged as "Availability: Unix", but if getpeercred() doesn't work on the BSDs, it doesn't even meet that standard. If a decision is made to include this, and if it only works on Linux 2.4+, I'd rather see it not available at all on other platforms (rather than returning dummy values). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492240&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:53:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:53:05 -0800 Subject: [Patches] [ python-Patches-1669539 ] Change (fix!) os.path.isabs() semantics on Win32 Message-ID: Patches item #1669539, was opened at 2007-02-26 23:07 Message generated for change (Comment added) made by jongfoster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jon Foster (jongfoster) Assigned to: Nobody/Anonymous (nobody) Summary: Change (fix!) os.path.isabs() semantics on Win32 Initial Comment: Hi, I consider this to be a bug in os.path.isabs(): PythonWin 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32. >>> import os.path >>> s = '\\Python25' >>> os.path.isabs(s) True >>> os.path.abspath(s) 'C:\\Python25' >>> os.chdir('d:') >>> os.path.abspath(s) 'D:\\Python25' >>> If s is really an absolute path as isabs() claims, then why does abspath() return a different path (i.e. not s)? And worse, note that a call to os.chdir() changes the meaning of s! So s is clearly not an absolute path, and isabs() is wrong. It turns out that on Windows there are really 4 different kinds of paths: 1) Completely relative, e.g. foo\bar 2) Completely absolute, e.g. c:\foo\bar or \\server\share 3) Halfbreeds with no drive, e.g. \foo\bar 4) Halfbreeds relative to the current working directory on a specific drive, e.g. c:foo\bar Python 2.5's os.path.isabs() method considers both (2) and (3) to be absolute; I agree with the classification of (2) but strongly disagree about case (3). Oh, and os.path.join is also broken, e.g. os.path.join('foo', 'a:bar') gives 'foo\\a:bar', which is an invalid path. Another consequence of this is that os.path.isabs() is not enough to classify paths. Sometimes you really need a relative path, so we really need (at least) a new os.path.isrelative(), which can return "not isabs(s)" on POSIX platforms, and do the right thing on Win32. The attached patch: - Changes the behaviour of os.path.isabs() and os.path.join() on Win32, to classify pathnames as described above (including adding UNC support) - Adds os.path.isrelative() on all platforms - Changes a couple of Win32 os.path tests where I have deliberately broken backward compatibility - Adds lots of new tests for these 3 functions on Win32 This does change the behaviour of isabs(), and it is possible that existing applications might be depending on the current behaviour. Silently changing the behaviour might break those applications. I'm not sure what the best course of action is - applying this for 2.6, putting a new API in (os.path.isreallyabs()?), or waiting for Python 3000...? Kind regards, Jon Foster ---------------------------------------------------------------------- >Comment By: Jon Foster (jongfoster) Date: 2007-03-08 20:53 Message: Logged In: YES user_id=199289 Originator: YES Hi Mark, Thanks for reviewing this. You wrote: > os.path.join("c:\\foo", "\\a") ... > 'c:\\a' seems the correct result Yes indeed, and this patch makes it do that. Hiding in the patch is this changed test case: -tester("ntpath.join('c:/a', '/b')", '/b') +tester("ntpath.join('c:/a', '/b')", 'c:/b') # CHANGED: Was '/b') and these new ones: +tester('ntpath.join("c:\\a", "\\b")', "c:\\b") +tester('ntpath.join("c:/a", "/b")', "c:/b") (Hmm looks like one of those tests is a duplicate... not a big deal I guess). I guess another way to handle these changes is to introduce new isabsolute(), isrelative(), and joinpath() functions, and deprecate isabs() and join(). (By "deprecate" I mean at least put a warning in the docs that it shouldn't be used; whether or not to make the code raise a DeprecationWarning is a separate decision). But that's kinda ugly from an API design point of view. I'm happy to roll a patch that does that, if we decide that fixing isabs() isn't possible. It's a pity there isn't a way to do something like "from __future__ import fixed_win_paths". But given how dynamic Python is, I guess that would be hard. Kind regards, Jon ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-03-08 00:36 Message: Logged In: YES user_id=14198 Originator: NO I agree the current behaviour is not ideal - but the right way forward isn't clear. Note the existing (strange) behaviour of os.path.join: >>> os.path.join("c:\\", "\\a") 'c:\\a' >>> os.path.join("c:\\foo", "\\a") '\\a' if isabs('\\a') returns False, there is almost an expectation that the last example should return 'c:\\foo\\a' - but that would almost never give what was expected. 'c:\\a' seems the correct result, but my quick scan of the test code in the patch shows this isn't exercised. FWIW, about the only common use of isabs() in my code is something like: log_directory = get_option_from_config_file(...) if not os.path.isabs(log_directory): # make log_directory absolute based on app directory. log_directory = os.path.join(app_directory, log_directory) Best I can tell, the above would not break if isabs('/foo') started returning False, so long as os.path.join('c:\\foo', '\\bar') resulted in 'c:\\bar'. Off the top-of-my-head, another strategy may be to introduce isrelative() in 2.6, and in 2.7 introduce a warning when isabs() is passed one of the halfbreeds, warning that 2.8 will return a different value, and pointing to the new isrelative(). 2.8 then gets the full, 'correct' implementation as described here. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-03-07 23:09 Message: Logged In: YES user_id=199289 Originator: YES Thanks for the comments. Updated patch attached, which includes the doc changes. File Added: win32_absolute_paths_2.patch ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 10:32 Message: Logged In: YES user_id=18139 Originator: NO There is an interesting thread on python-dev right now about possibly tweaking the behavior of splitext() in 2.6. So maybe there is hope after all. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 04:01 Message: Logged In: YES user_id=18139 Originator: NO Thanks for submitting this. Nice summary of the different cases. I think very few people have given this that much thought. :) You need a patch for the docs if you want this to even get considered. Then the main obstacle is convincing the team that the nice new logical behavior is worth the breakage. I would be surprised if it got through. And Python 3000 is not going to be the "subtle breakage" release. I would give you better odds if your patch created new APIs instead, and *documented* exactly what's useful about the model you're suggesting. ---------------------------------------------------------------------- Comment By: Jon Foster (jongfoster) Date: 2007-02-26 23:15 Message: Logged In: YES user_id=199289 Originator: YES P.S. The patch is against Python SVN trunk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1669539&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:58:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:58:46 -0800 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 17:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 20:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 17:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Thu Mar 8 21:59:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 12:59:06 -0800 Subject: [Patches] [ python-Patches-914340 ] gzip.GzipFile to accept stream as fileobj. Message-ID: Patches item #914340, was opened at 2004-03-11 18:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile to accept stream as fileobj. Initial Comment: When gzip.GzipFile is initialized with a fileobj which does not have tell() and seek() methods (non-rewinding stream) it throws exception. The interesting thing is that it doesn't have to. The following patch updates gzip.py to allow any stream with just a read() method to be used. This is helpful if you want to be able to do something like: gzip.GzipFile(fileobj=urllib.urlopen("file:///README.gz")).readlines() or use GzipFile with sys.stdin stream. But keep in mind that seek() and rewind() methond of the GzipFile() won't for such stream even with the patch. Igor ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 20:59 Message: Logged In: YES user_id=849994 Originator: NO It looks like Patch #1675951 provides the same feature, plus speedups. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 14:51 Message: Logged In: YES user_id=21627 Originator: NO The patch in this form is incomplete: it lacks test suite changes. Can somebody please provide patches to Lib/test/test_gzip.py that exercises this new functionality? ---------------------------------------------------------------------- Comment By: Jakob Truelsen (antialize) Date: 2006-06-19 08:35 Message: Logged In: YES user_id=379876 Is there any reson this patch is not accepted? If this patch is accepted then I have a patch to urlib2 to (automaticaly) accept gzipped content as described here http://www.http-compression.com/#client_request, if there is some reson this patch is not acceptable please detail, so it can be fixed, in tired of using popen and gunzip :) ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 14:14 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 04:27 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-11 20:04 Message: Logged In: YES user_id=995711 Previous revision of the patch does not work correctly with mutliple compressed members in one stream. I've updated the patch file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:03:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:03:28 -0800 Subject: [Patches] [ python-Patches-1668482 ] don't use '-' and '_' in mkstemp Message-ID: Patches item #1668482, was opened at 2007-02-25 12:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arvin Schnell (arvins) Assigned to: Nobody/Anonymous (nobody) Summary: don't use '-' and '_' in mkstemp Initial Comment: I suggest to not use '-' and '_' in the filename generated by mkstemp. Without a prefix you end up with filename that start with '-' witch are clumsy to delete in the shell. glibc's mkstemp also uses only alphanumerical characters. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:03 Message: Logged In: YES user_id=1344176 Originator: NO Martin, any objections to committing this if only "-" is removed? I'll take care of the check-in. ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-02-25 17:44 Message: Logged In: YES user_id=698939 Originator: YES Nothing is wrong with '_'. I just wanted to make it consistent with glibc. Both 62**6 and 63**6 are huge numbers so it doesn't really matter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-25 17:03 Message: Logged In: YES user_id=21627 Originator: NO I can see what's wrong with -, but what is the problem with _? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668482&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:28:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:28:21 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22: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=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:28:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:28:22 -0800 Subject: [Patches] [ python-Patches-1671314 ] New File I/O type for Python 3000, plus .h and unit tests Message-ID: Patches item #1671314, was opened at 2007-02-28 17:08 Message generated for change (Comment added) made by agthorr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Daniel Stutzbach (agthorr) Assigned to: Guido van Rossum (gvanrossum) Summary: New File I/O type for Python 3000, plus .h and unit tests Initial Comment: Here is my implementation of a raw File I/O type for Python 3000, along with unit tests. The tests for repr() fail because I'm not 100% sure what repr() should return (in particular, whether the type should bother remembering the filename just to return in repr()). There are comments at the top of the .c file explaining what remains to be done. ---------------------------------------------------------------------- >Comment By: Daniel Stutzbach (agthorr) Date: 2007-03-08 15:28 Message: Logged In: YES user_id=6324 Originator: YES It's missing a forward declaration of PyFileIO_Type near the top of the file so the PyFileIO_Check() macro works. Currently PyCheck_FileIO is only called inside of an assert() macro, which is why this problem only surfaces in a debug build. Patch to add the forward declaration attached. File Added: pyfileio_type.diff ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 14:27 Message: Logged In: YES user_id=1344176 Originator: NO Reopening. I'm seeing build warnings and test failures related to the FileIO work when Python is configured with --with-pydebug. When compiling Modules/_fileio.c, gcc complains about "PyFileIO_Type undeclared"; because the _fileio module fails to build, both test_io and test_fileio fail. This occurs even after "make distclean". I have r54216 of p3yk, gcc 3.4.6. _fileio.c compiles successfully if Python is configured without --with-pydebug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 18:46 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54214. I tweaked a few things; for example O_APPEND doesn't have the semantics we want (it appends on *every write*). I turned it into a module and renamed it to _fileio, the class to _FileIO. The io.py module now imports this and uses it as a base class for *its* FileIO class, if the import works. There are plenty of XXX things. I'll try to get large file support working next; as long as off_t is a 64-bit int this should just work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:32:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:32:11 -0800 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 18: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=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:47:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:47:36 -0800 Subject: [Patches] [ python-Patches-1671314 ] New File I/O type for Python 3000, plus .h and unit tests Message-ID: Patches item #1671314, was opened at 2007-02-28 18:08 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Daniel Stutzbach (agthorr) Assigned to: Guido van Rossum (gvanrossum) Summary: New File I/O type for Python 3000, plus .h and unit tests Initial Comment: Here is my implementation of a raw File I/O type for Python 3000, along with unit tests. The tests for repr() fail because I'm not 100% sure what repr() should return (in particular, whether the type should bother remembering the filename just to return in repr()). There are comments at the top of the .c file explaining what remains to be done. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:47 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54226. Reclosing. Thanks, Daniel! ---------------------------------------------------------------------- Comment By: Daniel Stutzbach (agthorr) Date: 2007-03-08 16:28 Message: Logged In: YES user_id=6324 Originator: YES It's missing a forward declaration of PyFileIO_Type near the top of the file so the PyFileIO_Check() macro works. Currently PyCheck_FileIO is only called inside of an assert() macro, which is why this problem only surfaces in a debug build. Patch to add the forward declaration attached. File Added: pyfileio_type.diff ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:27 Message: Logged In: YES user_id=1344176 Originator: NO Reopening. I'm seeing build warnings and test failures related to the FileIO work when Python is configured with --with-pydebug. When compiling Modules/_fileio.c, gcc complains about "PyFileIO_Type undeclared"; because the _fileio module fails to build, both test_io and test_fileio fail. This occurs even after "make distclean". I have r54216 of p3yk, gcc 3.4.6. _fileio.c compiles successfully if Python is configured without --with-pydebug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 19:46 Message: Logged In: YES user_id=6380 Originator: NO Committed revision 54214. I tweaked a few things; for example O_APPEND doesn't have the semantics we want (it appends on *every write*). I turned it into a module and renamed it to _fileio, the class to _FileIO. The io.py module now imports this and uses it as a base class for *its* FileIO class, if the import works. There are plenty of XXX things. I'll try to get large file support working next; as long as off_t is a 64-bit int this should just work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671314&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:48:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:48:34 -0800 Subject: [Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling. Message-ID: Patches item #1520081, was opened at 2006-07-10 18:48 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ernest ter Kuile (ernestjwtk) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.py change to ease option handling. Initial Comment: Telnetlib.py has no automatic telnet option handling mechanism except for the possibility to register a callback function. If set, the callback is used for each option as they arrive. If not set, options are negated. Using this mechanisme is not elegant when extending the telnet class in a OO way, and there is currently no other way to handle this data. This patch adds to the callback mechanisme by also calling an internal function handle_option(), which by default doesn't do much. This function could then do something usefull when extending the telnet class. For backwards compatibility, the current callback mechanism has not been removed, and, if used, has priority over the internal function handle_option(), which is then ignored. Furthermore to explain the telnet option system, a lot of comments have been added. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 22:48 Message: Logged In: YES user_id=51702 Originator: NO Since this feature does not add something and is just a new way to do something that was already possible, maybe it can wait until py3k? I think having a handle_option() method is clearly a cleaner design than having a callback. But the advantage is not that great and in py3k you could break the api and replace the old method with the new one. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2006-07-10 19:09 Message: Logged In: YES user_id=1552811 Changed Category to be Library instead of Modules. Telnetlib.py is not a module (sorry for confusion) Also attached is diff to latest svn telnetlib had some timeout patch had been applied. (as of 10 july) Actually, first look shows no difference between this one and the previous one, but just to be sure. Ernest ter Kuile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 From noreply at sourceforge.net Thu Mar 8 22:48:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 13:48:37 -0800 Subject: [Patches] [ python-Patches-1668482 ] don't use '-' and '_' in mkstemp Message-ID: Patches item #1668482, was opened at 2007-02-25 18:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Arvin Schnell (arvins) >Assigned to: Collin Winter (collinwinter) Summary: don't use '-' and '_' in mkstemp Initial Comment: I suggest to not use '-' and '_' in the filename generated by mkstemp. Without a prefix you end up with filename that start with '-' witch are clumsy to delete in the shell. glibc's mkstemp also uses only alphanumerical characters. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-08 22:48 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, go ahead. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 22:03 Message: Logged In: YES user_id=1344176 Originator: NO Martin, any objections to committing this if only "-" is removed? I'll take care of the check-in. ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-02-25 23:44 Message: Logged In: YES user_id=698939 Originator: YES Nothing is wrong with '_'. I just wanted to make it consistent with glibc. Both 62**6 and 63**6 are huge numbers so it doesn't really matter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-25 23:03 Message: Logged In: YES user_id=21627 Originator: NO I can see what's wrong with -, but what is the problem with _? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668482&group_id=5470 From noreply at sourceforge.net Thu Mar 8 23:03:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 14:03:52 -0800 Subject: [Patches] [ python-Patches-1304895 ] Strobe Timer for guis Message-ID: Patches item #1304895, was opened at 2005-09-26 16:51 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1304895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Strobe Timer for guis Initial Comment: Often when doing gui work it is useful to queue up a task to run at some later time - either once or periodically. Although you can use the thread support to do this, it is problematic because: 1 one because if the work being done is gui related, it often needs to be done in the same thread which owns the gui 2 it is easier to not need to code using threads if you don't need to 3 having multiple threads executing at once doesn't scale so well, especially when you have lots of idle time in a gui app. I created this module to get around this problem. In you gui, you would add _timers.AppServiceTimers to your onIdle method (or whatever method get called for idle processing) Then to register an event to be run you would do: import _timers a = _timers.StrobeTimer() a.Interval(500) def MyStrobe(self): print "I am called every 500 ms", self a.Strobe = MyStrobe a.StartTimer() # do some work a.StopTimer() ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 23:03 Message: Logged In: YES user_id=51702 Originator: NO Thank you for your contribution! However, most GUI libraries already come with their own timer implementations. Also, there is no gain in writing it in C, since the execution speed of the timer class is not important. Additionally, the coding and naming style in the code is inconsistent and not in compliance with PEP7. For these reasons, I think the patch should not be accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1304895&group_id=5470 From noreply at sourceforge.net Thu Mar 8 23:17:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 14:17:48 -0800 Subject: [Patches] [ python-Patches-1668482 ] don't use '-' and '_' in mkstemp Message-ID: Patches item #1668482, was opened at 2007-02-25 12:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Arvin Schnell (arvins) Assigned to: Collin Winter (collinwinter) Summary: don't use '-' and '_' in mkstemp Initial Comment: I suggest to not use '-' and '_' in the filename generated by mkstemp. Without a prefix you end up with filename that start with '-' witch are clumsy to delete in the shell. glibc's mkstemp also uses only alphanumerical characters. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 17:17 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54232; not backporting. Thanks for your patch, Arvin! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-08 16:48 Message: Logged In: YES user_id=21627 Originator: NO Looks fine, go ahead. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 16:03 Message: Logged In: YES user_id=1344176 Originator: NO Martin, any objections to committing this if only "-" is removed? I'll take care of the check-in. ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-02-25 17:44 Message: Logged In: YES user_id=698939 Originator: YES Nothing is wrong with '_'. I just wanted to make it consistent with glibc. Both 62**6 and 63**6 are huge numbers so it doesn't really matter. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-25 17:03 Message: Logged In: YES user_id=21627 Originator: NO I can see what's wrong with -, but what is the problem with _? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668482&group_id=5470 From noreply at sourceforge.net Fri Mar 9 00:57:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 15:57:00 -0800 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Fri Mar 9 00:57:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 15:57:43 -0800 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Fri Mar 9 01:16:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 16:16:16 -0800 Subject: [Patches] [ python-Patches-664020 ] telnetlib option subnegotiation fix Message-ID: Patches item #664020, was opened at 2003-01-07 22:51 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib option subnegotiation fix Initial Comment: The telnetlib patch #630829 (committed as v1.20) for option subnegotiation doesn't work as-is. There are several problems. 1) The option negotiation callback should be a method of the Telnet class, not a separate function. The callback is supposed to call the read_sb_data method when it receives SB or SE, but of which object? I think the callback should have been a method all along. It should be able to change the object's state based on the negotiation. Generally when implementing a new protocol extension, you'll subclass Telnet, add the new behavior, and then have the callback set a flag in the object to activate the new behavior after it has been negotiated. The default DONT/WONT behavior can be moved out of the depths of process_rawq() into the callback method. Subclasses can then just forward to the parent class when they get an option they don't care about, instead of having to reimplement the default behavior. If the callback is a method, the socket argument is still available as self.sock. The set_option_negotiation_callback method and the checks for "if self.option_callback:" would not be needed. Changing the callback to a method will break compatibility with Python 2.2, however. 2) On receipt of SB and SE, the callback is always called with NOOPT. The option is never passed. (It actually gets stored as the first part of the parameter data and returned by read_sb_data().) 3) The callback is called on the receipt of both SB _and_ SE. The SB call is completely superfluous. The option and parameter data have not been read yet, so there is nothing for the callback to do. The attached patch fixes these and adds support for the NOP command. It also includes documentation changes and an example of implementing some options. Some other thoughts: The name "option_callback" is a little misleading. The callback is executed in response to all telnet protocol commands, not just the ones dealing with options. Why define and pass NOOPT for the case when there is no option rather than use None? The only place the SB parameter data will (can safely?) be used is in the callback. Why not pass it as another optional parameter and skip the need for read_sb_data()? A potential name conflict: the EOR telnet option defines a new command code also called EOR (with a much different numeric value). The C header file <arpa/telnet.h> prefixes all the options with TELOPT_, so there is no conflict there, but telnetlib drops the prefix. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 01:16 Message: Logged In: YES user_id=51702 Originator: NO This patch is very similar to #1520081. They both suggest replacing set_option_negotiation_callback with a method on the Telnet object which I think makes perfect sense. They both contain big and useful updates to the documentation. This patch also contain a useful refactoring of the process_rawq() method. I think a merged patch of them both should be applied. But IMHO, it should wait to Py3k because then API can be broken and then set_option_negotiation_callback can be eliminated. ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2003-01-07 22:57 Message: Logged In: YES user_id=2647 Sorry, the patch wasn't uploaded for some reason. Trying again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664020&group_id=5470 From noreply at sourceforge.net Fri Mar 9 02:55:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 17:55:40 -0800 Subject: [Patches] [ python-Patches-1630118 ] Patch to add tempfile.SpooledTemporaryFile (for #415692) Message-ID: Patches item #1630118, was opened at 2007-01-07 15:36 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1630118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dustin J. Mitchell (djmitche) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add tempfile.SpooledTemporaryFile (for #415692) Initial Comment: Attached please find a patch that adds a SpooledTemporaryFile class to tempfile, along with the corresponding documentation (optimistically labeling the feature as added in Python 2.5) and some test cases. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 20:55 Message: Logged In: YES user_id=1344176 Originator: NO Did you mean to leave SpooledTemporaryFile out of tempfile.py's __all__? Also, would it be possible for you to add some tests for the pathological cases you and Armin discussed related to bound .read() and .write() methods? ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-02-03 12:22 Message: Logged In: YES user_id=7446 Originator: YES Sounds good -- here's a new version. File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-01-11 02:55 Message: Logged In: YES user_id=4771 Originator: NO Reimplementing the whole file interface as a proxy functions might be the safest route, yes. I realized that the __getattr__() magic is also used to serve at least one special method, namely the __iter__() of the file objects. This only works with old-style classes. In the long-term future, when old-style classes disappear and these classes become new-style, this is likely to introduce a subtle bug. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-08 10:53 Message: Logged In: YES user_id=7446 Originator: YES I agree it would break in such a situation, but I'm not clear on which direction your bias leads you (specifically, which do we get right -- don't use bound methods, or don't use the __getattr__ magic?). I could fix this by defining "proxy" functions (and some properties) for the whole file interface, rather than just the methods that potentially trigger rollover. That would lose a little efficiency, but mostly only in reading (calling e.g., f.read() will always result in two function applications; in the current model, after the first call it runs at "native" speed). It would also lose forward compatibility if the file protocol changes, although I'm not sure how likely that is. Would you like me to do that? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-01-08 03:26 Message: Logged In: YES user_id=4771 Originator: NO The __getattr__ magic makes the following kind of code fail with SpooledTemporaryFile: f = SpooledTemporaryFile(max_size=something) rd = f.read wr = f.write for x in y: ...use rd(size) and wr(data)... The problem is that the captured 'f.read' method is the one from the StringIO instance, even after the write() rolled the file over to disk. Given that capturing bound methods is a semi-official speed hack advertised in some respected places, we might have to be careful about it. About such matters I am biased towards first getting it right and then getting it fast... Also, Python 2.5 is already out, so this will probably be a 2.6 addition. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-07 15:37 Message: Logged In: YES user_id=7446 Originator: YES File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1630118&group_id=5470 From noreply at sourceforge.net Fri Mar 9 02:56:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 17:56:04 -0800 Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589 Message-ID: Patches item #658599, was opened at 2002-12-26 02:49 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Mark Hammond (mhammond) Summary: Fix for bug 494589 Initial Comment: This is a fix for bug 494589 (os.path.expandvars) I suggest using the same code in ntpath and posixpath. (Maybe have a commonpath.py and let both import it?) Python version 2.2.2 OS: NT4 SP6 (checked on NT and cygwin) Miki ---------------------------------------------------------------------- >Comment By: Jack Diederich (jackdied) Date: 2007-03-08 20:56 Message: Logged In: YES user_id=591932 Originator: NO does the following svn message mean this should be closed? r53460 | sjoerd.mullender | 2007-01-16 11:42:38 -0500 (Tue, 16 Jan 2007) | 4 lines Fixed ntpath.expandvars to not replace references to non-existing variables with nothing. Also added tests. This fixes bug #494589. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-01-30 06:30 Message: Logged In: YES user_id=358087 Hopefully this should do the trick (if I'll remember to attache the file :-) All I did was to allow a $ only right after the first one. Miki ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-29 18:11 Message: Logged In: YES user_id=14198 Yes, I was too eager there. So back to the original patch - it looks good, except it seems to fail in one case I can see: $FOO$FOO is not correctly expanded. Put a space between the vars, or enclose them in braces, and it works correctly. This isn't really a regression though - the old code doesn't handle that case correctly either. posixpath does. See the new patch I uploaded - it contains the original code, plus a patch to test_ntpath.py to test the semantics. Is it possible to fix the patch to handle this case? I haven't time to dig out my regex book <wink> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-16 20:24 Message: Logged In: YES user_id=31435 Did you look at bug 494589? As I noted there, there are semantic diffferences between the ntpath and posixpath versions of .expandvars() (like ntpath mapping $$ to $, and not expanding within single quotes). I personally have no use for the differences, but can't say whether anyone else does. The author of the ntpath version took time to write comments about its pecularities, so they weren't accidents at the time. Incompatible changes are usually PEP material. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-16 00:24 Message: Logged In: YES user_id=14198 It was late last night - the idea of ripping out all duplicated code wont work. A consolidation may be possible, but I haven't time. I'm deleting that patch, but still believe that from posixpath import expandvars is reasonable. Comments? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-15 14:14 Message: Logged In: YES user_id=31435 Sounds like an excellent idea to me, Mark! The glory is all yours, if you're man enough to accept it <wink>. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-15 07:38 Message: Logged In: YES user_id=14198 In fact, why not go the whole-hog, and remove all code in ntpath.py that is identical to posixpath.py Example patch attached <wink> ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-14 22:44 Message: Logged In: YES user_id=14198 Is there any reason why: from posixpath import expandvars is not a better patch? From what I can see, posixpath's version works fine for Windows (windows os.environ is case insensitive) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-13 12:59 Message: Logged In: YES user_id=31435 Mark, can you make time to look at this? I can't. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 22:31 Message: Logged In: YES user_id=33168 The patch didn't apply for me, so I created a new one and attached it. I can't test this. Maybe Tim is interested. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2002-12-29 02:28 Message: Logged In: YES user_id=358087 This time the checkbox is checked. :-) Miki ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 13:07 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470 From noreply at sourceforge.net Fri Mar 9 04:03:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 19:03:24 -0800 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 10:30 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) >Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Fri Mar 9 04:07:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 19:07:51 -0800 Subject: [Patches] [ python-Patches-1491804 ] Simple slice support for list.sort() and .reverse() Message-ID: Patches item #1491804, was opened at 2006-05-19 15:19 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491804&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Heiko Wundram (hwundram) Assigned to: Nobody/Anonymous (nobody) Summary: Simple slice support for list.sort() and .reverse() Initial Comment: As requested per http://groups.google.de/group/comp.lang.python/browse_thread/thread/6feadf8170900e53/aa621eed0fe14050?hl=de#aa621eed0fe14050 list.sort() should support extra keyword arguments start and stop, which specify a slice of the whole list to sort inplace. The attached patch implements this functionality, and extends the sorted() builtin to also offer these keyword arguments, and additionally implements slice support (also with start, stop) for list.reverse(). The patch updates the list object methods and the sorted builtin, and also updates the testsuite to check for the new keyword arguments and updates the documentation to list them. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 22:07 Message: Logged In: YES user_id=1344176 Originator: NO I think anyone who was relying on that behavior was treading on "implementation details" territory to begin with, so I wouldn't worry about this particular semantics nit. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-20 12:15 Message: Logged In: YES user_id=791932 By the way, I've just become aware of the fact that this patch changes the semantics of list.sort() somewhat, because of an optimization I did to the code. The DSU-function isn't called anymore when there are less than two items to sort, i.e. the list or the slice to sort is one item long. This means: --- def test(k): k.append(4) return k[0] x = [[1,2,3]] x.sort(key=test) print x --- will now print [[1,2,3]] (with the patch applied), whereas Python 2.4 would've printed [[1,2,3,4]], but not have called timsort either. I don't know whether this breaks anything (or the old behaviour was sensible); at least it should have to be documented. I'd like feedback before I start either taking out the optimization or documenting this. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-20 07:18 Message: Logged In: YES user_id=791932 The attached patch implements all of the old patch, and adds the specified logic for array.reverse(), updates the documentation for the array module and whatsnew25, and will speed up the methods a slight little bit in the absense of optimization when compiling Python. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-05-20 01:14 Message: Logged In: YES user_id=593130 Having thought about submitting an RFE for start/stop for reverse, I support the enhancement. Please do the same for array.reverse(, so list and array.reverse continue to have the same signature. Two uses: one way to swap partitions in place is reverse each partition and then the whole sequence; probably more useful is the slice reversal in one standard method for sequentially generating permutations in lexicographical order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491804&group_id=5470 From noreply at sourceforge.net Fri Mar 9 04:16:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 19:16:28 -0800 Subject: [Patches] [ python-Patches-1481079 ] Support of HTTP_REFERER in CGIHTTPServer.py Message-ID: Patches item #1481079, was opened at 2006-05-03 09:01 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1481079&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: S?bastien Martini (ookoi) >Assigned to: Collin Winter (collinwinter) Summary: Support of HTTP_REFERER in CGIHTTPServer.py Initial Comment: In CGIHTTPServer.py simply put the referer's value (obtained from headers) in os.env associated to the key 'HTTP_REFERER'. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 22:16 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54234. Thanks for your patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1481079&group_id=5470 From noreply at sourceforge.net Fri Mar 9 04:30:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 19:30:04 -0800 Subject: [Patches] [ python-Patches-1512942 ] Improves an error message from setattr Message-ID: Patches item #1512942, was opened at 2006-06-26 15:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 3 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Improves an error message from setattr Initial Comment: Fixes Bugs item #1506776 ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 22:30 Message: Logged In: YES user_id=1344176 Originator: NO Since no-one has been able to come up with a simple fix or a better error message, and since the referenced bug report was closed eight months ago, I'm closing this patch, too. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-06-29 14:07 Message: Logged In: YES user_id=835142 I did not think of the that case. It looks like there is no easy way to distinguish the slots and no slots case in PyObject_GenericSetAttr. I think the proper fix will involve not filling tp_setattro with PyObject_GenericSetAttr in the presence of slots, but use a function that is optimized for that case. Can anyone suggest a simpler fix? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-28 06:36 Message: Logged In: YES user_id=4771 The error message can still be wrong. For example, in the following situation: class X(object): __slots__ = ['a'] X().b = 5 Then the original message -- no attribute 'b' -- was correct. With this patch Python now wrongly tells you that 'X' object has only read-only attributes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1512942&group_id=5470 From noreply at sourceforge.net Fri Mar 9 04:36:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 19:36:56 -0800 Subject: [Patches] [ python-Patches-1399935 ] enhance unittest to define tests that *should* fail Message-ID: Patches item #1399935, was opened at 2006-01-08 16:45 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399935&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: enhance unittest to define tests that *should* fail Initial Comment: As discussed here: http://mail.python.org/pipermail/python-dev/2006-January/059503.html ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-08 22:36 Message: Logged In: YES user_id=1344176 Originator: NO Why wasn't this ever committed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1399935&group_id=5470 From noreply at sourceforge.net Fri Mar 9 07:38:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 22:38:28 -0800 Subject: [Patches] [ python-Patches-1676994 ] Refactor test_popen2.py to use unittest. Message-ID: Patches item #1676994, was opened at 2007-03-08 23: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=1676994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_popen2.py to use unittest. Initial Comment: This patch turns test_popen2.py into a unittest file. There should be no changes in what the file tests. Modifying test_popen2.py to use unittest also required making a small change to popen2.py, which also contains some testing code. Lib/test/output/test_popen2 should be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 From noreply at sourceforge.net Fri Mar 9 08:15:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 08 Mar 2007 23:15:32 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Fri Mar 9 10:24:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 01:24:53 -0800 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Fri Mar 9 11:15:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 02:15:18 -0800 Subject: [Patches] [ python-Patches-1639973 ] email.utils.parsedate documentation Message-ID: Patches item #1639973, was opened at 2007-01-20 01:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Nobody/Anonymous (nobody) Summary: email.utils.parsedate documentation Initial Comment: See bug 1629566 (python.org/sf/1629566) for discussion. This patch eliminates any ambiguity in the documentation regarding which fields of the time tuple it refers to. This patch specifies the documentation in both librfc822.tex and emailutil.tex ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-09 10:15 Message: Logged In: YES user_id=849994 Originator: NO I agree with Collin. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 18:36 Message: Logged In: YES user_id=1344176 Originator: NO Where do the "tm_wday", "tm_yday", "tm_isdst" names come from? I don't see them in the referenced RFC, nor anywhere else in the patched docs. Why not just make a note that 6, 7 and 8 are counted from zero? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 From ghyoatq at cavtel.net Fri Mar 9 11:53:55 2007 From: ghyoatq at cavtel.net (Ann Vaughn) Date: Fri, 09 Mar 2007 02:53:55 -0800 Subject: [Patches] Galen, do you wanna win 236.- US$ Message-ID: <220b01c76235$01ecbfb0$bb8fd97b@dbsd> Just thought about you Galen, Galen, do you wanna win 236.- US$ Get your start bonus now: - Visit our website http://milkandre.com/magic/5/en/ and download the playing module in your language (no installation needed) - Register as guest or player......and start winning Cheers Ann Vaughn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070309/23f8e676/attachment.htm From noreply at sourceforge.net Fri Mar 9 16:36:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 07:36:22 -0800 Subject: [Patches] [ python-Patches-957003 ] RFE: Extend smtplib.py with support for LMTP Message-ID: Patches item #957003, was opened at 2004-05-19 21:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957003&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Leif Hedstrom (zwoop) Assigned to: Nobody/Anonymous (nobody) Summary: RFE: Extend smtplib.py with support for LMTP Initial Comment: Hi, attached is a proposal to extend the existing smtplib.py module with support for LMTP (RFC2033). I find it very useful together with IMAP servers like Cyrus. Thanks, -- leif ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-09 16:36 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54240 ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-25 22:52 Message: Logged In: YES user_id=1188172 Moving to the patches tracker. As a new feature, assigning to group Python 2.5. ---------------------------------------------------------------------- Comment By: Leif Hedstrom (zwoop) Date: 2004-06-01 23:14 Message: Logged In: YES user_id=480913 Is the documentation provided in the patch for the LMTP class not sufficient? I can extend on that if necessary, although bear in mind that LMTP is very, very similar to SMTP. The main difference is the support for Unix sockets. As for adding test code, I could do that, although I'm guessing most people will not have an LMTP capable server running. If you feel strongly on this, I'll add something that will check for port 2003, and submit the same test message through an LMTP instance. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-06-01 19:25 Message: Logged In: YES user_id=593130 If you were mere requesting a feature enhancement, this would belong in the RFE list and not the bug list. Since you submitted a patch, and not just a proposal, this belongs in the patch list. However, as a patch submission, it also needs 1) a patch to the documentation for smtplib (at least the suggested new text if you can't do Latex) and 2) a patch to the test suite for smtplib (assuming there is one already). Suggestion: close this bug report as invalid and open a patch item with the additional material. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957003&group_id=5470 From noreply at sourceforge.net Fri Mar 9 18:46:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 09:46:20 -0800 Subject: [Patches] [ python-Patches-1639973 ] email.utils.parsedate documentation Message-ID: Patches item #1639973, was opened at 2007-01-19 20:15 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) >Assigned to: Collin Winter (collinwinter) Summary: email.utils.parsedate documentation Initial Comment: See bug 1629566 (python.org/sf/1629566) for discussion. This patch eliminates any ambiguity in the documentation regarding which fields of the time tuple it refers to. This patch specifies the documentation in both librfc822.tex and emailutil.tex ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-09 05:15 Message: Logged In: YES user_id=849994 Originator: NO I agree with Collin. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:36 Message: Logged In: YES user_id=1344176 Originator: NO Where do the "tm_wday", "tm_yday", "tm_isdst" names come from? I don't see them in the referenced RFC, nor anywhere else in the patched docs. Why not just make a note that 6, 7 and 8 are counted from zero? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 From noreply at sourceforge.net Fri Mar 9 18:49:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 09:49:48 -0800 Subject: [Patches] [ python-Patches-1639973 ] email.utils.parsedate documentation Message-ID: Patches item #1639973, was opened at 2007-01-19 19:15 Message generated for change (Comment added) made by mark-roberts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Collin Winter (collinwinter) Summary: email.utils.parsedate documentation Initial Comment: See bug 1629566 (python.org/sf/1629566) for discussion. This patch eliminates any ambiguity in the documentation regarding which fields of the time tuple it refers to. This patch specifies the documentation in both librfc822.tex and emailutil.tex ---------------------------------------------------------------------- >Comment By: Mark Roberts (mark-roberts) Date: 2007-03-09 11:49 Message: Logged In: YES user_id=1591633 Originator: YES http://docs.python.org/lib/module-time.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-09 04:15 Message: Logged In: YES user_id=849994 Originator: NO I agree with Collin. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 12:36 Message: Logged In: YES user_id=1344176 Originator: NO Where do the "tm_wday", "tm_yday", "tm_isdst" names come from? I don't see them in the referenced RFC, nor anywhere else in the patched docs. Why not just make a note that 6, 7 and 8 are counted from zero? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 From noreply at sourceforge.net Fri Mar 9 19:13:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 10:13:12 -0800 Subject: [Patches] [ python-Patches-1639973 ] email.utils.parsedate documentation Message-ID: Patches item #1639973, was opened at 2007-01-19 20:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Collin Winter (collinwinter) Summary: email.utils.parsedate documentation Initial Comment: See bug 1629566 (python.org/sf/1629566) for discussion. This patch eliminates any ambiguity in the documentation regarding which fields of the time tuple it refers to. This patch specifies the documentation in both librfc822.tex and emailutil.tex ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 13:12 Message: Logged In: YES user_id=1344176 Originator: NO Since the confusion stemmed from the ambiguous word "fields", I've changed it (r54243) to "indexes" which will make it perfectly clear where the count starts from. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-03-09 12:49 Message: Logged In: YES user_id=1591633 Originator: YES http://docs.python.org/lib/module-time.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-09 05:15 Message: Logged In: YES user_id=849994 Originator: NO I agree with Collin. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 13:36 Message: Logged In: YES user_id=1344176 Originator: NO Where do the "tm_wday", "tm_yday", "tm_isdst" names come from? I don't see them in the referenced RFC, nor anywhere else in the patched docs. Why not just make a note that 6, 7 and 8 are counted from zero? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1639973&group_id=5470 From noreply at sourceforge.net Fri Mar 9 19:18:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 10:18:06 -0800 Subject: [Patches] [ python-Patches-1668100 ] urllib2.urlopen() raises OSError instead of URLError Message-ID: Patches item #1668100, was opened at 2007-02-24 18:20 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.urlopen() raises OSError instead of URLError Initial Comment: See bug 1591774. The base problem is that when passing a file:// url into urllib2.urlopen() for a file that doesn't exist, the os.stat() call fails with an OSError exception which is not caught. The documentation for urllib2 states that urlopen() raises a URLError upon error. This bug can also be triggered when fetching a http:// url. A misconfigured webserver can cause urllib2.urlopen to use the FileHandler (see bug report). This patch catches OSError in the FileHandler class and raises it as a URLError. Unit test included. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 13:18 Message: Logged In: YES user_id=1344176 Originator: NO I think it should be fixed to raise URLError. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-25 23:12 Message: Logged In: YES user_id=1727609 Originator: YES Sorry, I looked at that commented out section and didn't immediately see what it was for, so ignored it. I'm not sure what the correct behavior would be in this case. Getting a OSError from a http:// url is unsettling. I guess that if I were using the library, I would only want to have to catch one type of exception. Having to catch both URLError and OSError is inconvenient. If I were looking for a file on disk I would use file(), so the only time someone probably uses the file:// url syntax is when the end user is entering the URL. The end user wouldn't distinguish between the two exception types in this case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 12:01 Message: Logged In: YES user_id=261020 Originator: NO I recall that when I wrote the urllib2 tests there were a fair few cases similar to this -- indeed, this particular one is already marked in the tests with an "XXXX" in test_file(). What do other people think about these -- should they be fixed, or the docs changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 From noreply at sourceforge.net Fri Mar 9 20:40:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 11:40:11 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:14:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:14:32 -0800 Subject: [Patches] [ python-Patches-947386 ] Fix for #947380 - sys.path is wrong on windows sometimes Message-ID: Patches item #947386, was opened at 2004-05-04 02:56 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947386&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Ori Berger (orib) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #947380 - sys.path is wrong on windows sometimes Initial Comment: Fixes http://python.org/sf/947380 - see details there. One line of code, one line of comment. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-09 21:14 Message: Logged In: YES user_id=1326842 Originator: NO Closing as suggested in the previous comment. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 14:21 Message: Logged In: YES user_id=1326842 Originator: NO This was fixed in Python 2.5 with patch #1232023: http://www.python.org/sf/1232023 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-21 02:07 Message: Logged In: YES user_id=341410 See my comment in #947380 as to why this will go away in future versions of Python, without your patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=947386&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:20:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:20:39 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 21:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:33:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:33:47 -0800 Subject: [Patches] [ python-Patches-1491866 ] Complex representation Message-ID: Patches item #1491866, was opened at 2006-05-19 17:27 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491866&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Heiko Wundram (hwundram) >Assigned to: Collin Winter (collinwinter) Summary: Complex representation Initial Comment: As per request on c.l.p: http://groups.google.de/group/comp.lang.python/browse_thread/thread/26c93fefefd3a100/bf1924ce28fac1ac?hl=de#bf1924ce28fac1ac I've implemented a small patch to change the output of repr(x) for complex variables, so that complex(repr(x)) works for any complex x. This changes the output of repr(x) to '+j' without brackets, but leaves the string output untouched. This change of behaviour would be in line with int(repr(x)) and float(repr(x)) being defined for any int or float x, repectively. I don't know whether this patch is sensible, and whether it breaks any current code, because (for example) eval("5*%r" % (1+2j,)) won't work properly anymore, or whether it'd be more sensible to change the complex constructor to also accept a bracketed expression. I'll attach a patch to do the latter later. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 15:33 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54247. Thanks for your patch! ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 14:09 Message: Logged In: YES user_id=1344176 Originator: NO Works for me. I'll commit this for 2.6 (no backport) if there are no objections. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-07 19:04 Message: Logged In: YES user_id=51702 Originator: NO I have applied this patch in 2.6 and it seem to work as intended. The test_complex.py unit tests all pass. I guess the change could be useful if you are are serializing and desearializing lists of complex numbers. I think it should be applied. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-20 07:20 Message: Logged In: YES user_id=791932 The attached patch is a revised version of the patch to the complex constructor to accept bracketed string expressions, which also adds documentation changes (whatsnew25). Anyway, I personally also find this to be the "better" way, so I've removed the repr-changing patch. And, calling it a bug was by accident: I should've rather called it tracker item, which is pretty synonymous for me. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2006-05-20 01:24 Message: Logged In: YES user_id=593130 (The current behavior is not a bug, nor is this patch submission a bug report, so let us omit that word.) I think your example suggests why complexes are printed in parens, so I think enhancing complex() to accept such is the better approach if any change is to be made. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-19 18:28 Message: Logged In: YES user_id=791932 The second patch (python-complex-constructor.diff) changes the constructor to accept bracketed complex numbers which are enclosed in a single bracket. I'd rather say this is the better appropach to have complex(repr(x)) work, but I leave both patches attached to this bug. The latter patch also creates test cases testing for formatting errors with bracketed expressions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491866&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:36:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:36:39 -0800 Subject: [Patches] [ python-Patches-1676994 ] Refactor test_popen2.py to use unittest. Message-ID: Patches item #1676994, was opened at 2007-03-09 01:38 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_popen2.py to use unittest. Initial Comment: This patch turns test_popen2.py into a unittest file. There should be no changes in what the file tests. Modifying test_popen2.py to use unittest also required making a small change to popen2.py, which also contains some testing code. Lib/test/output/test_popen2 should be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:36:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:36:53 -0800 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 17:38 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-07 16:07 Message: Logged In: YES user_id=584997 Originator: YES Removed unnecessary global statement in trackCall. Anything else? :-) File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 20:03 Message: Logged In: YES user_id=849994 Originator: NO Note that you don't need the global statement for callLst as you aren't rebinding it in the function. ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-06 01:38 Message: Logged In: YES user_id=584997 Originator: YES Hi collin, * I improved testMixIntsAndLongs. It now asserts things * assert is banished, replaced by the correct calls * the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect. * assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test. Let me know if you have further suggestions. File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:37:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:37:11 -0800 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 10:41 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 12:24 Message: Logged In: YES user_id=1344176 Originator: NO They can stay out; I just wanted to know the reason. This patch looks good to me. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-06 00:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 13:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Fri Mar 9 21:58:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 12:58:20 -0800 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 14:23 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Barran (rbarran) >Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 16:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 09:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 13:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 06:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 12:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 07:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 02:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Mar 9 23:19:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 14:19:05 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 23:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 21:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Fri Mar 9 23:21:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 14:21:10 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 23:21 Message: Logged In: YES user_id=51702 Originator: YES Here is finished patch. It includes both documentation and a few unit tests. File Added: add-PeriodicTimer-2.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 23:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 21:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Sat Mar 10 01:24:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 16:24:29 -0800 Subject: [Patches] [ python-Patches-1599845 ] TCPServer option to bind and activate Message-ID: Patches item #1599845, was opened at 2006-11-20 12:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: TCPServer option to bind and activate Initial Comment: Adds a flag to the TCPServer constructor to automatically call server_bind and server_activate or not. Setting this flag to False gives the programmer the chance to manipulate allow_reuse_address on the instance without having to subclass TCPServer or its derivatives just to change the flag. Adds this flag to SimpleXMLRPCServer.__init__ also. See bug #1595742. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 19:24 Message: Logged In: YES user_id=1344176 Originator: NO Martin, any reason not to apply this? ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-29 20:18 Message: Logged In: YES user_id=624776 Originator: YES I marked the parameter as new to Python 2.6 in the documentation. Is this correct? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 01:50 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide documentation patches as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 From noreply at sourceforge.net Sat Mar 10 01:30:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 16:30:11 -0800 Subject: [Patches] [ python-Patches-1545011 ] Fixes SocketServer Bug 1531963 Message-ID: Patches item #1545011, was opened at 2006-08-22 21:35 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Damon Kohler (damonkohler) >Assigned to: Collin Winter (collinwinter) Summary: Fixes SocketServer Bug 1531963 Initial Comment: Bug 1531963 is fixed by setting SocketServer.server_address = SocketServer.socket.getsockname() when the socket is bound. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-07 15:14 Message: Logged In: YES user_id=1344176 Originator: NO Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 From noreply at sourceforge.net Sat Mar 10 01:33:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 16:33:02 -0800 Subject: [Patches] [ python-Patches-1677688 ] Support CREATE_SUSPENDED flag in subprocess.py for Win32 Message-ID: Patches item #1677688, was opened at 2007-03-09 16: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=1677688&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Heller (chrisheller) Assigned to: Nobody/Anonymous (nobody) Summary: Support CREATE_SUSPENDED flag in subprocess.py for Win32 Initial Comment: The CreateProcess() function that subprocess uses on Windows allows for creation of processes in a suspended state. To then start the process running though you need to call ResumeThread on the primary thread of the process. Currently this thread handle gets closed, then discarded by the subprocess module. In order to continue making use of subprocess, but also use the CREATE_SUSPENDED flag, I modified my local copy of subprocess to retain the thread when the CREATE_SUSPENDED flag was supplied. If the CREATE_SUSPENDED flag is not requested, then the code behaves exactly the same as it currently does. The attached patch is against Subversion trunk, revision 53646. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 From noreply at sourceforge.net Sat Mar 10 01:52:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 16:52:26 -0800 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 12:21 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 01:52 Message: Logged In: YES user_id=51702 Originator: NO I have created a patch that I hope can supersede this one. This patch does some nice refactorings to test_timeout.py by encapsulating some common code in a sockOperation method. Then that method is used to run the function under test. It also implements tests for testSend, testSendto and testSendall. Plus, (I think) it fixes a bug which (I think) only happens when you access the internet from behind a web proxy. I think the patch is good but there were two problems with it so I created a new one. First, it tries to filter out errors dealing with timeouts from normal socket.error's. But the author forgot about args with only one string as a value. Second, I do not like how the actual assertion of the test is done in the tearDown method. My patch fixes those problems, otherwise it is mostly identical to this patch. It is #1677694 at http://sourceforge.net/tracker/index.php?func=detail&aid=1677694&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-14 18:10 Message: Logged In: YES user_id=21627 rhettinger: would you like to review it now? If not, please unassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 16:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 16:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 16:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2003-06-30 14:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 16:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply at sourceforge.net Sat Mar 10 03:41:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 18:41:56 -0800 Subject: [Patches] [ python-Patches-1516309 ] Remove deprecated functions from operator Message-ID: Patches item #1516309, was opened at 2006-07-03 08:47 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) >Assigned to: Collin Winter (collinwinter) Summary: Remove deprecated functions from operator Initial Comment: This patch removes the isCallable() and sequenceIncludes() functions from the operator module. These functions have been deprecated since Python 2.0. This patch is against r47214. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 From noreply at sourceforge.net Sat Mar 10 04:34:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 19:34:10 -0800 Subject: [Patches] [ python-Patches-1545011 ] Fixes SocketServer Bug 1531963 Message-ID: Patches item #1545011, was opened at 2006-08-22 21:35 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Damon Kohler (damonkohler) Assigned to: Collin Winter (collinwinter) Summary: Fixes SocketServer Bug 1531963 Initial Comment: Bug 1531963 is fixed by setting SocketServer.server_address = SocketServer.socket.getsockname() when the socket is bound. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-09 22:34 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54253 (for 2.6), r54255 (for 2.5.1). Thanks for the patch! ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-07 15:14 Message: Logged In: YES user_id=1344176 Originator: NO Looks good to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1545011&group_id=5470 From noreply at sourceforge.net Sat Mar 10 04:50:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 19:50:12 -0800 Subject: [Patches] [ python-Patches-1677688 ] Support CREATE_SUSPENDED flag in subprocess.py for Win32 Message-ID: Patches item #1677688, was opened at 2007-03-09 19:33 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Chris Heller (chrisheller) Assigned to: Nobody/Anonymous (nobody) Summary: Support CREATE_SUSPENDED flag in subprocess.py for Win32 Initial Comment: The CreateProcess() function that subprocess uses on Windows allows for creation of processes in a suspended state. To then start the process running though you need to call ResumeThread on the primary thread of the process. Currently this thread handle gets closed, then discarded by the subprocess module. In order to continue making use of subprocess, but also use the CREATE_SUSPENDED flag, I modified my local copy of subprocess to retain the thread when the CREATE_SUSPENDED flag was supplied. If the CREATE_SUSPENDED flag is not requested, then the code behaves exactly the same as it currently does. The attached patch is against Subversion trunk, revision 53646. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-09 22:50 Message: Logged In: YES user_id=18139 Originator: NO This patch doesn't work. Three bugs: (1) bad syntax, && should be & (2) global name CREATE_SUSPENDED isn't defined; and (3) after the if statement, ht.Close() happens anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 From noreply at sourceforge.net Sat Mar 10 05:19:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 20:19:24 -0800 Subject: [Patches] [ python-Patches-658599 ] Fix for bug 494589 Message-ID: Patches item #658599, was opened at 2002-12-25 23:49 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Mark Hammond (mhammond) Summary: Fix for bug 494589 Initial Comment: This is a fix for bug 494589 (os.path.expandvars) I suggest using the same code in ntpath and posixpath. (Maybe have a commonpath.py and let both import it?) Python version 2.2.2 OS: NT4 SP6 (checked on NT and cygwin) Miki ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-09 20:19 Message: Logged In: YES user_id=33168 Originator: NO Given the bug is closed, seems reasonable to close this patch too. Thanks for pointing it out Jack. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2007-03-08 17:56 Message: Logged In: YES user_id=591932 Originator: NO does the following svn message mean this should be closed? r53460 | sjoerd.mullender | 2007-01-16 11:42:38 -0500 (Tue, 16 Jan 2007) | 4 lines Fixed ntpath.expandvars to not replace references to non-existing variables with nothing. Also added tests. This fixes bug #494589. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-01-30 03:30 Message: Logged In: YES user_id=358087 Hopefully this should do the trick (if I'll remember to attache the file :-) All I did was to allow a $ only right after the first one. Miki ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-29 15:11 Message: Logged In: YES user_id=14198 Yes, I was too eager there. So back to the original patch - it looks good, except it seems to fail in one case I can see: $FOO$FOO is not correctly expanded. Put a space between the vars, or enclose them in braces, and it works correctly. This isn't really a regression though - the old code doesn't handle that case correctly either. posixpath does. See the new patch I uploaded - it contains the original code, plus a patch to test_ntpath.py to test the semantics. Is it possible to fix the patch to handle this case? I haven't time to dig out my regex book <wink> ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-16 17:24 Message: Logged In: YES user_id=31435 Did you look at bug 494589? As I noted there, there are semantic diffferences between the ntpath and posixpath versions of .expandvars() (like ntpath mapping $$ to $, and not expanding within single quotes). I personally have no use for the differences, but can't say whether anyone else does. The author of the ntpath version took time to write comments about its pecularities, so they weren't accidents at the time. Incompatible changes are usually PEP material. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-15 21:24 Message: Logged In: YES user_id=14198 It was late last night - the idea of ripping out all duplicated code wont work. A consolidation may be possible, but I haven't time. I'm deleting that patch, but still believe that from posixpath import expandvars is reasonable. Comments? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-15 11:14 Message: Logged In: YES user_id=31435 Sounds like an excellent idea to me, Mark! The glory is all yours, if you're man enough to accept it <wink>. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-15 04:38 Message: Logged In: YES user_id=14198 In fact, why not go the whole-hog, and remove all code in ntpath.py that is identical to posixpath.py Example patch attached <wink> ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-14 19:44 Message: Logged In: YES user_id=14198 Is there any reason why: from posixpath import expandvars is not a better patch? From what I can see, posixpath's version works fine for Windows (windows os.environ is case insensitive) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-13 09:59 Message: Logged In: YES user_id=31435 Mark, can you make time to look at this? I can't. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 19:31 Message: Logged In: YES user_id=33168 The patch didn't apply for me, so I created a new one and attached it. I can't test this. Maybe Tim is interested. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2002-12-28 23:28 Message: Logged In: YES user_id=358087 This time the checkbox is checked. :-) Miki ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 10:07 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=658599&group_id=5470 From noreply at sourceforge.net Sat Mar 10 07:50:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 09 Mar 2007 22:50:17 -0800 Subject: [Patches] [ python-Patches-1677688 ] Support CREATE_SUSPENDED flag in subprocess.py for Win32 Message-ID: Patches item #1677688, was opened at 2007-03-10 00:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Chris Heller (chrisheller) Assigned to: Nobody/Anonymous (nobody) Summary: Support CREATE_SUSPENDED flag in subprocess.py for Win32 Initial Comment: The CreateProcess() function that subprocess uses on Windows allows for creation of processes in a suspended state. To then start the process running though you need to call ResumeThread on the primary thread of the process. Currently this thread handle gets closed, then discarded by the subprocess module. In order to continue making use of subprocess, but also use the CREATE_SUSPENDED flag, I modified my local copy of subprocess to retain the thread when the CREATE_SUSPENDED flag was supplied. If the CREATE_SUSPENDED flag is not requested, then the code behaves exactly the same as it currently does. The attached patch is against Subversion trunk, revision 53646. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-10 03:50 Message: Logged In: YES user_id=18139 Originator: NO This patch doesn't work. Three bugs: (1) bad syntax, && should be & (2) global name CREATE_SUSPENDED isn't defined; and (3) after the if statement, ht.Close() happens anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 From noreply at sourceforge.net Sat Mar 10 12:51:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 03:51:27 -0800 Subject: [Patches] [ python-Patches-1599845 ] TCPServer option to bind and activate Message-ID: Patches item #1599845, was opened at 2006-11-20 18:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Peter Parente (parente) >Assigned to: Collin Winter (collinwinter) Summary: TCPServer option to bind and activate Initial Comment: Adds a flag to the TCPServer constructor to automatically call server_bind and server_activate or not. Setting this flag to False gives the programmer the chance to manipulate allow_reuse_address on the instance without having to subclass TCPServer or its derivatives just to change the flag. Adds this flag to SimpleXMLRPCServer.__init__ also. See bug #1595742. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 12:51 Message: Logged In: YES user_id=21627 Originator: NO It looks fine indeed. Please apply. Make sure you check #1595742 as well. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-10 01:24 Message: Logged In: YES user_id=1344176 Originator: NO Martin, any reason not to apply this? ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-30 02:18 Message: Logged In: YES user_id=624776 Originator: YES I marked the parameter as new to Python 2.6 in the documentation. Is this correct? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 07:50 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide documentation patches as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 From noreply at sourceforge.net Sat Mar 10 12:57:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 03:57:09 -0800 Subject: [Patches] [ python-Patches-1675981 ] Remove dead code in typeobject's type_new() Message-ID: Patches item #1675981, was opened at 2007-03-07 19:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675981&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) >Assigned to: ?iga Seilnacht (zseil) Summary: Remove dead code in typeobject's type_new() Initial Comment: The code that this patch removes can never be reached; __dict__ and __weakref__ are removed from the slots tuple earlier in the code, in the loop that mangles slot names, around line 1850. I think that this code was just overlooked in the last refactoring, in revision 28166. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 12:57 Message: Logged In: YES user_id=21627 Originator: NO This looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675981&group_id=5470 From noreply at sourceforge.net Sat Mar 10 14:34:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 05:34:35 -0800 Subject: [Patches] [ python-Patches-1677862 ] site.py small ?bug fix | change? Message-ID: Patches item #1677862, was opened at 2007-03-10 15: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=1677862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) Assigned to: Nobody/Anonymous (nobody) Summary: site.py small ?bug fix | change? Initial Comment: change line 137(r54258) from if line.startswith("import"): to if line.startswith("import "): to allow add dirs like import_from_here to modules search path ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 From noreply at sourceforge.net Sat Mar 10 14:47:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 05:47:37 -0800 Subject: [Patches] [ python-Patches-1677872 ] Efficient reverse line iterator Message-ID: Patches item #1677872, was opened at 2007-03-10 13:47 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=1677872&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: Efficient reverse line iterator Initial Comment: This is an implementation of __reversed__ for the TextIOWrapper type from the new IO interface (see http://docs.google.com/Doc?id=dfksfvqd_1cn5g5m). It is used as: import io for line in reversed(io.open(filename)): ... It is efficient (only reads a block at a time) but can handle arbitrary length lines. It is useful for scanning backwards through big log files, but my main reason for submitting it is as a demonstration of the usefulness of the new IO layers - it works by putting a new buffering layer round the RawIOBase object from the open() call. It's just a proof of concept, but if there's interest in this I'm happy to write unit tests and documentation. The patch also makes io.BufferedReader support buffering, and adds a very minimal implementation of io.TextIOBase and io.TextIOWrapper (needed to make io.open() work). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677872&group_id=5470 From noreply at sourceforge.net Sat Mar 10 14:56:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 05:56:01 -0800 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 14:56 Message: Logged In: YES user_id=51702 Originator: YES "I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)" Actually, you get something very very weird. Try "t = Thread(); for x in range(10): t.start()". But it is the fault of the Thread class and above my head to fix anyhow. :) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 23:21 Message: Logged In: YES user_id=51702 Originator: YES Here is finished patch. It includes both documentation and a few unit tests. File Added: add-PeriodicTimer-2.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 23:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 21:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Sat Mar 10 15:42:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 06:42:59 -0800 Subject: [Patches] [ python-Patches-1599845 ] TCPServer option to bind and activate Message-ID: Patches item #1599845, was opened at 2006-11-20 12:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Peter Parente (parente) Assigned to: Collin Winter (collinwinter) Summary: TCPServer option to bind and activate Initial Comment: Adds a flag to the TCPServer constructor to automatically call server_bind and server_activate or not. Setting this flag to False gives the programmer the chance to manipulate allow_reuse_address on the instance without having to subclass TCPServer or its derivatives just to change the flag. Adds this flag to SimpleXMLRPCServer.__init__ also. See bug #1595742. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 09:42 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54262. Thanks for your patch! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 06:51 Message: Logged In: YES user_id=21627 Originator: NO It looks fine indeed. Please apply. Make sure you check #1595742 as well. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 19:24 Message: Logged In: YES user_id=1344176 Originator: NO Martin, any reason not to apply this? ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-29 20:18 Message: Logged In: YES user_id=624776 Originator: YES I marked the parameter as new to Python 2.6 in the documentation. Is this correct? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 01:50 Message: Logged In: YES user_id=21627 Originator: NO Can you please provide documentation patches as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1599845&group_id=5470 From noreply at sourceforge.net Sat Mar 10 16:13:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 07:13:50 -0800 Subject: [Patches] [ python-Patches-1244929 ] hide tests from TestProgram Message-ID: Patches item #1244929, was opened at 2005-07-25 23:54 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244929&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric Huss (ehuss) >Assigned to: Collin Winter (collinwinter) Summary: hide tests from TestProgram Initial Comment: The TestProgram class will find all tests in the file based on whether or not they are subclassed from TestCase. It is not possible to prevent TestProgram from including tests, such as base classes. For example, have BaseTest(unittest.TestCase) class that implements several test functions. However, these test functions can not operate correctly on their own...the class must be subclassed for proper operation (such as TestBlah(BaseTest)). This patch changes the "auto find" feature to ignore any classes that start with an underscore, allowing you to define base classes in the same file, but not have their tests run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1244929&group_id=5470 From noreply at sourceforge.net Sat Mar 10 17:02:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 08:02:28 -0800 Subject: [Patches] [ python-Patches-1304895 ] Strobe Timer for guis Message-ID: Patches item #1304895, was opened at 2005-09-26 10:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1304895&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Brett Rosen (bdrosen) Assigned to: Nobody/Anonymous (nobody) Summary: Strobe Timer for guis Initial Comment: Often when doing gui work it is useful to queue up a task to run at some later time - either once or periodically. Although you can use the thread support to do this, it is problematic because: 1 one because if the work being done is gui related, it often needs to be done in the same thread which owns the gui 2 it is easier to not need to code using threads if you don't need to 3 having multiple threads executing at once doesn't scale so well, especially when you have lots of idle time in a gui app. I created this module to get around this problem. In you gui, you would add _timers.AppServiceTimers to your onIdle method (or whatever method get called for idle processing) Then to register an event to be run you would do: import _timers a = _timers.StrobeTimer() a.Interval(500) def MyStrobe(self): print "I am called every 500 ms", self a.Strobe = MyStrobe a.StartTimer() # do some work a.StopTimer() ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 11:02 Message: Logged In: YES user_id=1344176 Originator: NO This is something that should ship with GUI toolkits, not in Python's stdlib. Please submit this patch to whichever GUI toolkit you favor. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 17:03 Message: Logged In: YES user_id=51702 Originator: NO Thank you for your contribution! However, most GUI libraries already come with their own timer implementations. Also, there is no gain in writing it in C, since the execution speed of the timer class is not important. Additionally, the coding and naming style in the code is inconsistent and not in compliance with PEP7. For these reasons, I think the patch should not be accepted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1304895&group_id=5470 From noreply at sourceforge.net Sat Mar 10 17:08:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 08:08:17 -0800 Subject: [Patches] [ python-Patches-1094387 ] os.py: base class _Environ on dict instead of UserDict Message-ID: Patches item #1094387, was opened at 2005-01-02 05:22 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094387&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.py: base class _Environ on dict instead of UserDict Initial Comment: os.py doesn't have a note, that is has to stay compatible with python2.2 and before. Use the builtin dict class for handling the environment. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-10 11:08 Message: Logged In: YES user_id=1344176 Originator: NO Patch #1367711 does the same thing and is against a more recent checkout; closing. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-03-03 18:43 Message: Logged In: YES user_id=21627 The patch is currently outdated. However, I'm wondering what the advantage of inheriting from dict is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1094387&group_id=5470 From noreply at sourceforge.net Sat Mar 10 19:01:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 10:01:58 -0800 Subject: [Patches] [ python-Patches-1673759 ] 'G' formatting doesn't catch same errors as 'g' Message-ID: Patches item #1673759, was opened at 2007-03-05 02:45 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'G' formatting doesn't catch same errors as 'g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 18:01 Message: Logged In: YES user_id=1740099 Originator: NO Your change in Objects/stringobject.c and Objects/unicodeobject.c goes over the 79 character line limit. Otherwise looks ok - compiles, runs, tests look correct and pass. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 11:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Sat Mar 10 19:57:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 10:57:11 -0800 Subject: [Patches] [ python-Patches-1673759 ] 'G' formatting doesn't catch same errors as 'g' Message-ID: Patches item #1673759, was opened at 2007-03-04 21:45 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'G' formatting doesn't catch same errors as 'g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 13:57 Message: Logged In: YES user_id=411198 Originator: YES Thanks for the catch on the line length. I've updated the patch and attached it. File Added: 1673757-1.diff ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 13:01 Message: Logged In: YES user_id=1740099 Originator: NO Your change in Objects/stringobject.c and Objects/unicodeobject.c goes over the 79 character line limit. Otherwise looks ok - compiles, runs, tests look correct and pass. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Sat Mar 10 19:58:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 10:58:48 -0800 Subject: [Patches] [ python-Patches-1673759 ] '%G' string formatting doesn't catch same errors as '%g' Message-ID: Patches item #1673759, was opened at 2007-03-04 21:45 Message generated for change (Comment added) made by ericvsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) >Summary: '%G' string formatting doesn't catch same errors as '%g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- >Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 13:58 Message: Logged In: YES user_id=411198 Originator: YES Improved summary. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 13:57 Message: Logged In: YES user_id=411198 Originator: YES Thanks for the catch on the line length. I've updated the patch and attached it. File Added: 1673757-1.diff ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 13:01 Message: Logged In: YES user_id=1740099 Originator: NO Your change in Objects/stringobject.c and Objects/unicodeobject.c goes over the 79 character line limit. Otherwise looks ok - compiles, runs, tests look correct and pass. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Sat Mar 10 22:31:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 13:31:54 -0800 Subject: [Patches] [ python-Patches-1677862 ] site.py small ?bug fix | change? Message-ID: Patches item #1677862, was opened at 2007-03-10 13:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) >Assigned to: Martin v. L?wis (loewis) Summary: site.py small ?bug fix | change? Initial Comment: change line 137(r54258) from if line.startswith("import"): to if line.startswith("import "): to allow add dirs like import_from_here to modules search path ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 21:31 Message: Logged In: YES user_id=849994 Originator: NO I can't see a problem with this change other than you could in theory also put a tab after "import". Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 From noreply at sourceforge.net Sat Mar 10 22:34:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 13:34:17 -0800 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 21: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=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Sat Mar 10 22:36:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 13:36:26 -0800 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 21:34 Message generated for change (Settings changed) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Sat Mar 10 22:50:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 13:50:55 -0800 Subject: [Patches] [ python-Patches-1673759 ] '%G' string formatting doesn't catch same errors as '%g' Message-ID: Patches item #1673759, was opened at 2007-03-05 02:45 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: '%G' string formatting doesn't catch same errors as '%g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 21:50 Message: Logged In: YES user_id=1740099 Originator: NO lgtm ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 18:58 Message: Logged In: YES user_id=411198 Originator: YES Improved summary. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 18:57 Message: Logged In: YES user_id=411198 Originator: YES Thanks for the catch on the line length. I've updated the patch and attached it. File Added: 1673757-1.diff ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 18:01 Message: Logged In: YES user_id=1740099 Originator: NO Your change in Objects/stringobject.c and Objects/unicodeobject.c goes over the 79 character line limit. Otherwise looks ok - compiles, runs, tests look correct and pass. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 11:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Sat Mar 10 23:11:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 14:11:38 -0800 Subject: [Patches] [ python-Patches-1678077 ] improve telnetlib.Telnet so option negotiation becomes easie Message-ID: Patches item #1678077, was opened at 2007-03-10 23:11 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=1678077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: improve telnetlib.Telnet so option negotiation becomes easie Initial Comment: This patch is a merger of #664020 (telnetlib option subnegotiation fix) and #1520081 (telnetlib.py change to ease option handling) which are both outdated. The purpose of it is to replace the set_option_negotiation_callback with a handle_option method that subclasses can reimplement. This should make it much easier to implement custom option negotiation handling. The patch also extends the documentation somewhat to make it clearer how to to implement custom option subnegotiation. It breaks compatibility with earlier Pythons because it removes set_option_negotiation_callback. But I think it should be good to apply it for Python 3.0. See the referenced patches for many more details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678077&group_id=5470 From noreply at sourceforge.net Sat Mar 10 23:27:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 14:27:18 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 21:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 6 Private: No Submitted By: ganges master (gangesmaster) >Assigned to: Georg Brandl (gbrandl) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 22:27 Message: Logged In: YES user_id=849994 Originator: NO Applied to Python 3000 branch in rev. 54265. Leaving open for the case that there's interest in backporting to 2.6. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-12-19 21:12 Message: Logged In: YES user_id=1406776 Originator: YES i guess the demo isn't updated/relevant anymore. instead, concrete tests were added to lib/tests/test_builtin.py ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-11-23 12:11 Message: Logged In: YES user_id=4771 Originator: NO Line 20 in demo.py: assert "__getitem__" in dir(x) looks strange to me... Foo doesn't inherit from any sequence or mapping type. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-11 21:31 Message: Logged In: YES user_id=1406776 > PyObject_CallFunctionObjArgs(dirfunc, obj, NULL) done > Couldn't __dir__ also be allowed to return a tuple? no, because tuples are not sortable, and i don't want to over complicate the c-side code of PyObject_Dir. having __dir__ returning only a list is equivalent to __repr__ returning only strings. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 19:58 Message: Logged In: YES user_id=849994 * Instead of doing PyObject_CallFunction(dirfunc, "O", obj) you should do PyObject_CallFunctionObjArgs(dirfunc, obj, NULL). * Couldn't __dir__ also be allowed to return a tuple? ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 11:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 05:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 15:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-06 22:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Sat Mar 10 23:42:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 14:42:53 -0800 Subject: [Patches] [ python-Patches-1678088 ] Refactor test_operations.py to use unittest. Message-ID: Patches item #1678088, was opened at 2007-03-10 15:42 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=1678088&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_operations.py to use unittest. Initial Comment: The summary is a bit of a misnomer. The contents of test_operations.py were moved into test_dict.py and both Lib/test/test_operations.py and Lib/test/output/test_operations should be removed. The attached patch adds the two tests currently in test_operations.py into test_dict.py. The tests were moved because they test the behaviour of dictionaries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678088&group_id=5470 From noreply at sourceforge.net Sat Mar 10 23:59:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 14:59:39 -0800 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sun Mar 11 00:01:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 15:01:06 -0800 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 13:34 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) >Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Sun Mar 11 00:13:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 15:13:01 -0800 Subject: [Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling. Message-ID: Patches item #1520081, was opened at 2006-07-10 18:48 Message generated for change (Comment added) made by ernestjwtk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ernest ter Kuile (ernestjwtk) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.py change to ease option handling. Initial Comment: Telnetlib.py has no automatic telnet option handling mechanism except for the possibility to register a callback function. If set, the callback is used for each option as they arrive. If not set, options are negated. Using this mechanisme is not elegant when extending the telnet class in a OO way, and there is currently no other way to handle this data. This patch adds to the callback mechanisme by also calling an internal function handle_option(), which by default doesn't do much. This function could then do something usefull when extending the telnet class. For backwards compatibility, the current callback mechanism has not been removed, and, if used, has priority over the internal function handle_option(), which is then ignored. Furthermore to explain the telnet option system, a lot of comments have been added. ---------------------------------------------------------------------- >Comment By: Ernest ter Kuile (ernestjwtk) Date: 2007-03-11 00:13 Message: Logged In: YES user_id=1552811 Originator: YES Wel it does, and this is why I needed it. For me it added two very important things: 1) it adds the possibility to create a descendant of the telnet class which can handle the options. Without this, the callback mechanism must always be handled externaly to the telnet object itself. 2) And since the callback has no concept of self (missing parameters) it adds the possibility to have more than one instance of the telnet class which did not need a different version of the callback function each time. I needed about 6 instances (one for each system I had to reach), so had to provide 6 _different_ callback functions. (This showed to me that the callback way of doing was totally broken) I wanted to (and did) encapsulate the telnet object with something which itself could provide the knowlege of handling some of the options (in fact a telnet 3270, which is a special case of the telnet protocol). This would have been very much harder to do without being able to handle the options within the objet. Sorry if I wasn't clear. Ernest. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 22:48 Message: Logged In: YES user_id=51702 Originator: NO Since this feature does not add something and is just a new way to do something that was already possible, maybe it can wait until py3k? I think having a handle_option() method is clearly a cleaner design than having a callback. But the advantage is not that great and in py3k you could break the api and replace the old method with the new one. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2006-07-10 19:09 Message: Logged In: YES user_id=1552811 Changed Category to be Library instead of Modules. Telnetlib.py is not a module (sorry for confusion) Also attached is diff to latest svn telnetlib had some timeout patch had been applied. (as of 10 july) Actually, first look shows no difference between this one and the previous one, but just to be sure. Ernest ter Kuile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 From noreply at sourceforge.net Sun Mar 11 01:04:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 16:04:46 -0800 Subject: [Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling. Message-ID: Patches item #1520081, was opened at 2006-07-10 18:48 Message generated for change (Comment added) made by ernestjwtk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ernest ter Kuile (ernestjwtk) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.py change to ease option handling. Initial Comment: Telnetlib.py has no automatic telnet option handling mechanism except for the possibility to register a callback function. If set, the callback is used for each option as they arrive. If not set, options are negated. Using this mechanisme is not elegant when extending the telnet class in a OO way, and there is currently no other way to handle this data. This patch adds to the callback mechanisme by also calling an internal function handle_option(), which by default doesn't do much. This function could then do something usefull when extending the telnet class. For backwards compatibility, the current callback mechanism has not been removed, and, if used, has priority over the internal function handle_option(), which is then ignored. Furthermore to explain the telnet option system, a lot of comments have been added. ---------------------------------------------------------------------- >Comment By: Ernest ter Kuile (ernestjwtk) Date: 2007-03-11 01:04 Message: Logged In: YES user_id=1552811 Originator: YES sonderblade: I just noticed your new patch and submission. Looks good at first glance. I'll keep my current patch for myself as I don't think Python 3 will come out just yet, But I'll gladly use your version when it does. I too think it best to get rid of the callback mechanism for the reasons described below, but since I didn't want to be too radical I only added to it. Cheers, Ernest. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2007-03-11 00:13 Message: Logged In: YES user_id=1552811 Originator: YES Wel it does, and this is why I needed it. For me it added two very important things: 1) it adds the possibility to create a descendant of the telnet class which can handle the options. Without this, the callback mechanism must always be handled externaly to the telnet object itself. 2) And since the callback has no concept of self (missing parameters) it adds the possibility to have more than one instance of the telnet class which did not need a different version of the callback function each time. I needed about 6 instances (one for each system I had to reach), so had to provide 6 _different_ callback functions. (This showed to me that the callback way of doing was totally broken) I wanted to (and did) encapsulate the telnet object with something which itself could provide the knowlege of handling some of the options (in fact a telnet 3270, which is a special case of the telnet protocol). This would have been very much harder to do without being able to handle the options within the objet. Sorry if I wasn't clear. Ernest. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 22:48 Message: Logged In: YES user_id=51702 Originator: NO Since this feature does not add something and is just a new way to do something that was already possible, maybe it can wait until py3k? I think having a handle_option() method is clearly a cleaner design than having a callback. But the advantage is not that great and in py3k you could break the api and replace the old method with the new one. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2006-07-10 19:09 Message: Logged In: YES user_id=1552811 Changed Category to be Library instead of Modules. Telnetlib.py is not a module (sorry for confusion) Also attached is diff to latest svn telnetlib had some timeout patch had been applied. (as of 10 july) Actually, first look shows no difference between this one and the previous one, but just to be sure. Ernest ter Kuile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 From noreply at sourceforge.net Sun Mar 11 02:21:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 17:21:34 -0800 Subject: [Patches] [ python-Patches-1374063 ] Broader iterable support for xmlrpclib Message-ID: Patches item #1374063, was opened at 2005-12-05 22:14 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1374063&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) >Assigned to: Martin v. L?wis (loewis) Summary: Broader iterable support for xmlrpclib Initial Comment: The XML-RPC spec supports a fairly limited set of datatypes. Most languages, Python included, contain many more types than XML-RPC. Some types, such as Python's complex number type, have no reasonable analog in XML-RPC. Others, such as unicode objects and array objects do. This patch allows anything that can be converted to a list but that is not otherwise supported directly by the xmlrpclib module already to be marshalled as an XML-RPC array if the allow_iter parameter to the ServerProxy constructor evaluated to true. This includes sets and arrays. Motivation... 1. Python already overloads the XML-RPC array type with both lists and tuples. This just extends that overloading to other currently unsupported Python types which can be converted to lists. Why should lists and tuples have all the fun? 2. Providing transparent conversion to XML-RPC arrays keeps calling code a bit cleaner. One of the attractions of XML-RPC is that the remote procedure call looks identical to a local call. This is especially true in Python because of /F's excellent little _Method class. Clearly as a programmer I could type: import array a = array.array('i', [1, 2,3]) ... from somemodule import somefunction print somefunction(list(a)) but that reveals details of the implementation of somefunction, namely that it can't handle arrays directly, even though in most respects arrays and lists are interchangeable. Attached is a patch for the xmlrpclib library that implements this feature, including minor doc changes and a new test case. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2007-03-10 19:21 Message: Logged In: YES user_id=44345 Originator: YES Here's a revised patch. An object having a __dict__ method takes precedence, but an object which can successfully be converted into a list will be transmitted as a list. No more allow_iter parameter. Martin, does it look okay to you? Skip File Added: xmliter.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-02-11 13:14 Message: Logged In: YES user_id=44345 Originator: YES Martin, I'm returning to this after a pause as well... Suppose I have a subclass of dict. When dumping with my proposed patch it will get dumped as a list. If it is to be dumped as some lowest common denominator type, it should be a dict I think. For example: #!/usr/bin/env python class D(dict): pass d = D(x=1, y=2, z=3) print d print list(d) Until we address is case (at least) I'm un-accepting the patch... Skip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-12-03 06:32 Message: Logged In: YES user_id=21627 Originator: NO The patch is fine. Notice that it is currently out of date, due to inclusion of patch #1070046. This other patch added generic support for objects having an __dict__ attribute, marshaling them struct elements. This is in real conflict to this patch: an object both supporting a list conversion and having a __dict__ attribute could be marshaled either way. My proposal is to resolve this in favor of this patch: If an object has a list conversion, it's most likely meant to be a list. If you agree to this resolution, please update the code and the documentation, and apply this patch. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-12-05 22:23 Message: Logged In: YES user_id=44345 Oh, I forgot my original use case. I was constructing a list of musicians from a larger data structure and used a set to guarantee uniqueness during construction. I didn't really care about element ordering. I either had to convert the set to a list when calling the local function that made the RPC call, or modify the local function to always convert that arg to a list. Both alternatives seemed unattractive to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1374063&group_id=5470 From noreply at sourceforge.net Sun Mar 11 03:36:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 10 Mar 2007 18:36:04 -0800 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 13:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 6 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Georg Brandl (gbrandl) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-10 18:36 Message: Logged In: YES user_id=33168 Originator: NO I think this should be backported to 2.6. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 14:27 Message: Logged In: YES user_id=849994 Originator: NO Applied to Python 3000 branch in rev. 54265. Leaving open for the case that there's interest in backporting to 2.6. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-12-19 13:12 Message: Logged In: YES user_id=1406776 Originator: YES i guess the demo isn't updated/relevant anymore. instead, concrete tests were added to lib/tests/test_builtin.py ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-11-23 04:11 Message: Logged In: YES user_id=4771 Originator: NO Line 20 in demo.py: assert "__getitem__" in dir(x) looks strange to me... Foo doesn't inherit from any sequence or mapping type. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-11 13:31 Message: Logged In: YES user_id=1406776 > PyObject_CallFunctionObjArgs(dirfunc, obj, NULL) done > Couldn't __dir__ also be allowed to return a tuple? no, because tuples are not sortable, and i don't want to over complicate the c-side code of PyObject_Dir. having __dir__ returning only a list is equivalent to __repr__ returning only strings. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 11:58 Message: Logged In: YES user_id=849994 * Instead of doing PyObject_CallFunction(dirfunc, "O", obj) you should do PyObject_CallFunctionObjArgs(dirfunc, obj, NULL). * Couldn't __dir__ also be allowed to return a tuple? ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 03:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-07 21:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 07:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-06 14:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Sun Mar 11 12:08:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 04:08:48 -0700 Subject: [Patches] [ python-Patches-1677862 ] site.py small ?bug fix | change? Message-ID: Patches item #1677862, was opened at 2007-03-10 15:34 Message generated for change (Comment added) made by koder_ua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) Assigned to: Martin v. L?wis (loewis) Summary: site.py small ?bug fix | change? Initial Comment: change line 137(r54258) from if line.startswith("import"): to if line.startswith("import "): to allow add dirs like import_from_here to modules search path ---------------------------------------------------------------------- >Comment By: KDanilov aka koder (koder_ua) Date: 2007-03-11 13:08 Message: Logged In: YES user_id=1620221 Originator: YES add "or line.startswith("import\t")" File Added: site_space_patch_v2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 23:31 Message: Logged In: YES user_id=849994 Originator: NO I can't see a problem with this change other than you could in theory also put a tab after "import". Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 From noreply at sourceforge.net Sun Mar 11 16:11:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 08:11:23 -0700 Subject: [Patches] [ python-Patches-1678339 ] Adding a testcase for the bug in find_longest_match Message-ID: Patches item #1678339, was opened at 2007-03-11 18:11 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=1678339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Denys Rtveliashvili (rtvd) Assigned to: Nobody/Anonymous (nobody) Summary: Adding a testcase for the bug in find_longest_match Initial Comment: The find_longest_match method in the difflib's SequenceMatcher has a bug. The bug is in turn caused by a problem with creating a b2j mapping which should contain a list of indices for each of the list elements in b. However, when the b2j mapping is being created (this is being done in __chain_b method in the SequenceMatcher) the mapping becomes broken. The cause of this is that for the frequently used elements the list of indices is removed and the element is being enlisted in the populardict mapping. The test case tries to match two strings like: abbbbbb.... and ...bbbbbbc The number of b is equal and the find_longest_match should have returned the proper amount. However, in case the number of "b"s is large enough, the method reports that the length of the longest common substring is 0. It simply can't find it. A bug was raised some time ago on this matter. It's ID is 1528074. I tried to fix this bug but as a result, the performance drops by a factor of 5-10. Perhaps someone more familiar with Python can find a good fix. For the time being I send this test case (which is broken until the bug is fixed) and I'm going to send a fix next (but the fix makes the method run quite slowly). The patch diff attached was made against the trunk version of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 From noreply at sourceforge.net Sun Mar 11 16:28:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 08:28:30 -0700 Subject: [Patches] [ python-Patches-1678345 ] A fix for the bug #1528074 [warning: quite slow] Message-ID: Patches item #1678345, was opened at 2007-03-11 18: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=1678345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Denys Rtveliashvili (rtvd) Assigned to: Nobody/Anonymous (nobody) Summary: A fix for the bug #1528074 [warning: quite slow] Initial Comment: This is a fix for the bug #1528074 in the difflib's SequenceMatcher which makes (among other possible things) find_longest_match return invalid results sometimes. The previously submitted test case for this bug has the #1678339 ID. The find_longest_match and __chain_b methods in the SequenceMatcher are perfectly optimized. The find_longest_match would work both fast and correctly if only the __chain_b did not break it's assumptions. The find_longest_match assumes that the b2j mapping has a mapping of all non-junk elements in b to lists of their indices in the "b" list. However, when __chain_b creates the b2j mapping, it removes popular elements from the list and marking the elements as popular in the "populardict". As a result, the find_longest_match method can't find the indices for the popular elements and they become automatically considered as something like a junk. I tried to fix the bug by both changing the find_longest_match and __chain_b methods. No matter how hard I tried, the change dropped the performance and slowed down the matching by 5-10 times. The impact of find_longest_match method was larger, so I decided to send a patch for the __chain_b. Please, note, that even though the method starts to work properly and the test cases pass on my computer just fine, the ingenious optimizations performed before become broken, so it would be great if a guru in Python code optimization tries to improve the things a bit. One more point: if the indices are not removed, the memory consumption on the large strings can become quite great. If this is a serious concern, a fix in the find_longest_match will need to be done instead. However that fix would probably be far less efficient that this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678345&group_id=5470 From noreply at sourceforge.net Sun Mar 11 16:54:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 08:54:58 -0700 Subject: [Patches] [ python-Patches-1192590 ] debugger ``condition`` and ``ignore`` exception handling Message-ID: Patches item #1192590, was opened at 2005-04-29 14:25 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Jones (jmjones) >Assigned to: Collin Winter (collinwinter) Summary: debugger ``condition`` and ``ignore`` exception handling Initial Comment: Fixed ``ignore`` and ``condition`` functions in the debugger (pdb.py) where they were not handling an ``IndexError`` exception which occurs when an invalid breakpoint number is passed in. Added a function ``do_show()`` which lists all breakpoints. ``do_show()`` takes a filename pattern as an argument. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 11:54 Message: Logged In: YES user_id=1344176 Originator: NO I'll apply the fixes to do_ignore() and do_condition(), but I'm not so sure about adding do_show(). This meaning of "show" would diverge wildly from gdb's command of the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470 From noreply at sourceforge.net Sun Mar 11 17:05:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 09:05:45 -0700 Subject: [Patches] [ python-Patches-1675981 ] Remove dead code in typeobject's type_new() Message-ID: Patches item #1675981, was opened at 2007-03-07 19:34 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675981&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: Remove dead code in typeobject's type_new() Initial Comment: The code that this patch removes can never be reached; __dict__ and __weakref__ are removed from the slots tuple earlier in the code, in the loop that mangles slot names, around line 1850. I think that this code was just overlooked in the last refactoring, in revision 28166. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-11 17:05 Message: Logged In: YES user_id=1326842 Originator: YES Commited as revision 54270, 54272 (2.5). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-10 12:57 Message: Logged In: YES user_id=21627 Originator: NO This looks fine, please apply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675981&group_id=5470 From noreply at sourceforge.net Sun Mar 11 17:06:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 09:06:43 -0700 Subject: [Patches] [ python-Patches-1192590 ] debugger ``condition`` and ``ignore`` exception handling Message-ID: Patches item #1192590, was opened at 2005-04-29 14:25 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Jones (jmjones) Assigned to: Collin Winter (collinwinter) Summary: debugger ``condition`` and ``ignore`` exception handling Initial Comment: Fixed ``ignore`` and ``condition`` functions in the debugger (pdb.py) where they were not handling an ``IndexError`` exception which occurs when an invalid breakpoint number is passed in. Added a function ``do_show()`` which lists all breakpoints. ``do_show()`` takes a filename pattern as an argument. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 12:06 Message: Logged In: YES user_id=1344176 Originator: NO Applied the bug fix portion of the patch as r54271 (trunk), r54273 (release25-maint). Thanks for the fix! ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 11:54 Message: Logged In: YES user_id=1344176 Originator: NO I'll apply the fixes to do_ignore() and do_condition(), but I'm not so sure about adding do_show(). This meaning of "show" would diverge wildly from gdb's command of the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470 From noreply at sourceforge.net Sun Mar 11 17:25:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 09:25:04 -0700 Subject: [Patches] [ python-Patches-1617687 ] specialcase simple sliceobj in list (and bugfixes) Message-ID: Patches item #1617687, was opened at 2006-12-18 03:35 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1617687&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: specialcase simple sliceobj in list (and bugfixes) Initial Comment: - Specialcase the step=1/None case of slicing using sliceobjects. - Fix bug where slice insertion using a sliceobject was inserting in a different place than slice inserting using a simple slice - Fix two off-by-one bugs that were cancelling each other out: the non-step-1 slice deletion code was memmoving too much for each item to delete, and not enough for the tail end, net result being a few too many bytes moved for each item. - Rewrite tail end move when deleting complex slice, use single memmove() instead of repeated PyList_SET_ITEM() - Expand comments describing the code somewhat. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-11 16:25 Message: Logged In: YES user_id=1740099 Originator: NO An alternative to the tail memmove would just be to incorporate it in the main loop; something like (untested): for(i=0; iob_size; garbage[i] = PyList_GET_ITEM(self, start + i * step); assert(source_end <= self->ob_size); memmove(&self->ob_item[target], &self->ob_item[source], (source_end - source) * sizeof(PyObject *)); } I think this also makes it more obvious what's going on - at the moment the code smells a bit funny, even with your new comment. Otherwise, the change looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1617687&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:00:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:00:08 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:00:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:00:48 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:27:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:27:34 -0700 Subject: [Patches] [ python-Patches-1590352 ] The "lazy strings" patch Message-ID: Patches item #1590352, was opened at 2006-11-04 06:30 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: The "lazy strings" patch Initial Comment: This patch consists of three changes to CPython: * changing PyStringObject.ob_sval, * "lazy concatenations", and * "lazy slices". None of these changes adds new functionality to CPython; they are all speed or memory optimizations. In detail: PyStringObject.ob_sval was changed from a char[] array to a char *. This is not in and of itself particularly desirable. It was necessary in order to implement the other two changes. "lazy concatenations" change string concatenation ("a" + "b") so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string concatenation in CPython is now more than 150% faster on average (as reported by pystone 2.0), and is approximately as fast as the standard string concatenation idiom ("".join([a + b + c])). "lazy slices" changes string slicing ("abc"[1], "a".strip()) so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string slicing in CPython is now more than 60% faster on average (as reported by pystone 2.0). When considering this patch, please keep in mind that the "lazy" changes are distinct, and could be incorporated independently. In particular I'm guessing that "lazy concatenations" have a lot higher chance of being accepted than "lazy slices". These changes were implemented almost entirely in Include/stringobject.h and Objects/stringobject.c. With this patch applied, trunk builds and passes all expected tests on Win32 and Linux. For a more thorough discussion of this patch, please see the attached text file(s). ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-11 17:27 Message: Logged In: YES user_id=1740099 Originator: NO I really like the idea of the lazy cats, and can believe that it's a really good optimisation, but before I review this code properly I'd like to see: a. convincing that it doesn't break strict aliasing (a casual reading suggests it does) b. lazy slices removed into their own patch (or just removed) - I don't want to recommend a patch containing them c. adherence to coding standard d. a little more explanation of how the cat objects work: it's important because they're a future minefield of bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:42:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:42:50 -0700 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 17:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 13:42 Message: Logged In: YES user_id=1344176 Originator: NO Mike, I've tweaked your refactoring some: strengthened the assertions in testMixIntsAndLongs and testDel; code cleanup in testBadTypeReturned; removed Jython-related code; reduced line lengths to < 80; changed a few print statements to self.fail() calls. Look over the version I've uploaded and tell me what you think. File Added: test_class.py.diff ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-07 16:07 Message: Logged In: YES user_id=584997 Originator: YES Removed unnecessary global statement in trackCall. Anything else? :-) File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 20:03 Message: Logged In: YES user_id=849994 Originator: NO Note that you don't need the global statement for callLst as you aren't rebinding it in the function. ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-06 01:38 Message: Logged In: YES user_id=584997 Originator: YES Hi collin, * I improved testMixIntsAndLongs. It now asserts things * assert is banished, replaced by the correct calls * the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect. * assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test. Let me know if you have further suggestions. File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:45:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:45:09 -0700 Subject: [Patches] [ python-Patches-1678088 ] Refactor test_operations.py to use unittest. Message-ID: Patches item #1678088, was opened at 2007-03-10 17:42 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678088&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_operations.py to use unittest. Initial Comment: The summary is a bit of a misnomer. The contents of test_operations.py were moved into test_dict.py and both Lib/test/test_operations.py and Lib/test/output/test_operations should be removed. The attached patch adds the two tests currently in test_operations.py into test_dict.py. The tests were moved because they test the behaviour of dictionaries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678088&group_id=5470 From noreply at sourceforge.net Sun Mar 11 18:59:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 10:59:51 -0700 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 10:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 13:59 Message: Logged In: YES user_id=1344176 Originator: NO One question before I apply this: why did you leave if t.error_count: print '%s errors:\n%s' % (t.getName(), t.errors.getvalue()) in ThreadedTempFileTest.test_main()? Why not make it some kind of assertion? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 12:24 Message: Logged In: YES user_id=1344176 Originator: NO They can stay out; I just wanted to know the reason. This patch looks good to me. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-06 00:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 13:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:19:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:19:03 -0700 Subject: [Patches] [ python-Patches-1590352 ] The "lazy strings" patch Message-ID: Patches item #1590352, was opened at 2006-11-04 06:30 Message generated for change (Comment added) made by lhastings You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: The "lazy strings" patch Initial Comment: This patch consists of three changes to CPython: * changing PyStringObject.ob_sval, * "lazy concatenations", and * "lazy slices". None of these changes adds new functionality to CPython; they are all speed or memory optimizations. In detail: PyStringObject.ob_sval was changed from a char[] array to a char *. This is not in and of itself particularly desirable. It was necessary in order to implement the other two changes. "lazy concatenations" change string concatenation ("a" + "b") so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string concatenation in CPython is now more than 150% faster on average (as reported by pystone 2.0), and is approximately as fast as the standard string concatenation idiom ("".join([a + b + c])). "lazy slices" changes string slicing ("abc"[1], "a".strip()) so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string slicing in CPython is now more than 60% faster on average (as reported by pystone 2.0). When considering this patch, please keep in mind that the "lazy" changes are distinct, and could be incorporated independently. In particular I'm guessing that "lazy concatenations" have a lot higher chance of being accepted than "lazy slices". These changes were implemented almost entirely in Include/stringobject.h and Objects/stringobject.c. With this patch applied, trunk builds and passes all expected tests on Win32 and Linux. For a more thorough discussion of this patch, please see the attached text file(s). ---------------------------------------------------------------------- >Comment By: Larry Hastings (lhastings) Date: 2007-03-11 18:19 Message: Logged In: YES user_id=364875 Originator: YES Howdy! Much has transpired since I posted this patch. * Guido expressed interest in having it in Py3k. * I ported it to Py3k; it's Python patch #1629305 on SourceForge. * Guido didn't like it, specifically discussing the pathological behavior of "lazy slices". * I created a "v2 lazy slices" that eliminated the pathological behavior but added a lot of complexity. * I ran a poll on the Py3k mailing list to see how interested people were in "lazy concatenation" and "v2 lazy slices". Most people were +1 on lazy concatenation, and -1 on lazy slices (v1 or v2), a position I can completely endorse. However, no Python luminaries replied, which--given the patch's checkered past--seemed like a vote of no-confidence. * Guido closed patch #1629305. Is there life after Guido patch-closing? I'd be happy to spend the time answering your questions if my patch had some sort of future. (Though you'll have to tell me what you mean by "break strict aliasing".) ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-11 17:27 Message: Logged In: YES user_id=1740099 Originator: NO I really like the idea of the lazy cats, and can believe that it's a really good optimisation, but before I review this code properly I'd like to see: a. convincing that it doesn't break strict aliasing (a casual reading suggests it does) b. lazy slices removed into their own patch (or just removed) - I don't want to recommend a patch containing them c. adherence to coding standard d. a little more explanation of how the cat objects work: it's important because they're a future minefield of bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:39:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:39:07 -0700 Subject: [Patches] [ python-Patches-1009811 ] Add missing types to __builtin__ Message-ID: Patches item #1009811, was opened at 2004-08-16 01:00 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Postponed Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: Add missing types to __builtin__ Initial Comment: Add most of the missing type objects to __builtin__. Adds the following: ellipsis (not to be confused with Ellipsis, which is the object of this type) builtin_function_or_method dictproxy generator PyCObject classobj instance instancemethod cell NoneType NotImplementedType frame function module traceback code Does not add the rest of the names mentioned in my email, as I'm unsure if they got an approval or were silently ignored. I'm not convinced that it's a good idea to put the rest in __builtin__, myself. See also: and ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 14:39 Message: Logged In: YES user_id=1344176 Originator: NO I agree with Martin. This is going to be taken care of in Python 3 (somehow) regardless. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-27 01:20 Message: Logged In: YES user_id=21627 I don't like to see further __builtin__ pollution, so I recommend to reject this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 From noreply at sourceforge.net Sun Mar 11 19:53:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 11:53:46 -0700 Subject: [Patches] [ python-Patches-1008086 ] patch for 767150 Message-ID: Patches item #1008086, was opened at 2004-08-12 12:50 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008086&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mats Wichmann (mwichmann) >Assigned to: Thomas Wouters (twouters) Summary: patch for 767150 Initial Comment: The attached is a fix for the same problem that is reported in 767150. For 2.3.x and head cvs this problem exists in the code path taken if configure does not detect inet_aton. I have not checked this against 2.2, which is the platform 767150 reports it against, there may be header inclusion issues that make it not work there but the essence is that the quantity worked with has to be forced to be a 32-bit quanitity, not declared unsigned long. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 14:53 Message: Logged In: YES user_id=1344176 Originator: NO The patch is only one line, changing a unsigned long to in_addr_t. Could someone familiar with/with access to Linux on an IA64 machine take a look at this? Thomas, I notice a lot of posts from you about 64-bit issues... ; ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1008086&group_id=5470 From noreply at sourceforge.net Sun Mar 11 21:15:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 13:15:33 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sun Mar 11 21:16:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 13:16:37 -0700 Subject: [Patches] [ python-Patches-1590352 ] The "lazy strings" patch Message-ID: Patches item #1590352, was opened at 2006-11-04 06:30 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Larry Hastings (lhastings) Assigned to: Nobody/Anonymous (nobody) Summary: The "lazy strings" patch Initial Comment: This patch consists of three changes to CPython: * changing PyStringObject.ob_sval, * "lazy concatenations", and * "lazy slices". None of these changes adds new functionality to CPython; they are all speed or memory optimizations. In detail: PyStringObject.ob_sval was changed from a char[] array to a char *. This is not in and of itself particularly desirable. It was necessary in order to implement the other two changes. "lazy concatenations" change string concatenation ("a" + "b") so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string concatenation in CPython is now more than 150% faster on average (as reported by pystone 2.0), and is approximately as fast as the standard string concatenation idiom ("".join([a + b + c])). "lazy slices" changes string slicing ("abc"[1], "a".strip()) so that, instead of directly calculating the resulting string, it returns a placeholder object representing the result. As a result, string slicing in CPython is now more than 60% faster on average (as reported by pystone 2.0). When considering this patch, please keep in mind that the "lazy" changes are distinct, and could be incorporated independently. In particular I'm guessing that "lazy concatenations" have a lot higher chance of being accepted than "lazy slices". These changes were implemented almost entirely in Include/stringobject.h and Objects/stringobject.c. With this patch applied, trunk builds and passes all expected tests on Win32 and Linux. For a more thorough discussion of this patch, please see the attached text file(s). ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-11 20:16 Message: Logged In: YES user_id=1740099 Originator: NO Hi Larry, It doesn't sound too promising - I'm new and have no powers of resurrection :( By strict aliasing, I just meant it's illegal to access members of one type if the object is of a different (incompatible) type (actually I was wrong, this isn't the strict aliasing rule - it's a more fundamental one). In your case, it means it's illegal to pass a concat object where a string object is expected, even if the function accesses members that are common to them both. If this is happening, the answer is to make a union with the string object and cat object as members, and to use this union type instead but it's not pretty. I suggest this patch is closed anyway. If you still believe in your code and think that lazy string cats have support, I suggest making a new patch with just those in (fixed up to be correct C, and PEP 7 compliant). ---------------------------------------------------------------------- Comment By: Larry Hastings (lhastings) Date: 2007-03-11 18:19 Message: Logged In: YES user_id=364875 Originator: YES Howdy! Much has transpired since I posted this patch. * Guido expressed interest in having it in Py3k. * I ported it to Py3k; it's Python patch #1629305 on SourceForge. * Guido didn't like it, specifically discussing the pathological behavior of "lazy slices". * I created a "v2 lazy slices" that eliminated the pathological behavior but added a lot of complexity. * I ran a poll on the Py3k mailing list to see how interested people were in "lazy concatenation" and "v2 lazy slices". Most people were +1 on lazy concatenation, and -1 on lazy slices (v1 or v2), a position I can completely endorse. However, no Python luminaries replied, which--given the patch's checkered past--seemed like a vote of no-confidence. * Guido closed patch #1629305. Is there life after Guido patch-closing? I'd be happy to spend the time answering your questions if my patch had some sort of future. (Though you'll have to tell me what you mean by "break strict aliasing".) ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-11 17:27 Message: Logged In: YES user_id=1740099 Originator: NO I really like the idea of the lazy cats, and can believe that it's a really good optimisation, but before I review this code properly I'd like to see: a. convincing that it doesn't break strict aliasing (a casual reading suggests it does) b. lazy slices removed into their own patch (or just removed) - I don't want to recommend a patch containing them c. adherence to coding standard d. a little more explanation of how the cat objects work: it's important because they're a future minefield of bugs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1590352&group_id=5470 From noreply at sourceforge.net Sun Mar 11 22:02:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 14:02:54 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Sun Mar 11 23:20:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 15:20:19 -0700 Subject: [Patches] [ python-Patches-1369028 ] Module fixedlenfields for standard lib Message-ID: Patches item #1369028, was opened at 2005-11-29 11:54 Message generated for change (Comment added) made by stroeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1369028&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Michael Str?der (stroeder) Assigned to: Nobody/Anonymous (nobody) Summary: Module fixedlenfields for standard lib Initial Comment: Module fixedlenfields for reading and splitting text files with fixed-length fields. It's inspired by module csv, implemented as iterator and I'm using it exactly like module csv. I've used Python 2.4.2 to develop it. Please consider it for inclusion into Python's standard lib. I'll grant copyright to Python Software Foundation. Ciao, Michael. ---------------------------------------------------------------------- >Comment By: Michael Str?der (stroeder) Date: 2007-03-11 23:20 Message: Logged In: YES user_id=64920 Originator: YES File Added: fixedlenfields.py ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 19:54 Message: Logged In: YES user_id=1344176 Originator: NO Modules submitted for stdlib inclusion should spend some time out in the wild first, attracting a userbase and proving their usefulness. I notice you've posted fixedlenfields to PyPI (http://cheeseshop.python.org/pypi/fixedlenfields/), but since its download URL points to this tracker item, I'm assuming you haven't updated it over the last 15+ months. If fixedlenfields has indeed built up a following over that time, you should do the following and submit a new patch: 1) Update the patch to work with Python 2.5+; it currently doesn't compile with Python 2.5 or 2.6. 2) Split the test suite out into a separate test file based on the unittest module. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1369028&group_id=5470 From noreply at sourceforge.net Sun Mar 11 23:34:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 15:34:18 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 21:34 Message generated for change (Comment added) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- >Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 22:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Mon Mar 12 00:47:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 16:47:54 -0700 Subject: [Patches] [ python-Patches-1009811 ] Add missing types to __builtin__ Message-ID: Patches item #1009811, was opened at 2004-08-16 01:00 Message generated for change (Comment added) made by foom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Postponed Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: Add missing types to __builtin__ Initial Comment: Add most of the missing type objects to __builtin__. Adds the following: ellipsis (not to be confused with Ellipsis, which is the object of this type) builtin_function_or_method dictproxy generator PyCObject classobj instance instancemethod cell NoneType NotImplementedType frame function module traceback code Does not add the rest of the names mentioned in my email, as I'm unsure if they got an approval or were silently ignored. I'm not convinced that it's a good idea to put the rest in __builtin__, myself. See also: and ---------------------------------------------------------------------- >Comment By: James Y Knight (foom) Date: 2007-03-11 19:47 Message: Logged In: YES user_id=1104715 Originator: YES I only submitted this because I was directed to. To reiterate, the actual problem is that the classes claim to be defined in a place they aren't actually defined in. Quoting myself: Sooo should (for 'generator' in objects that claim to be in __builtin__ but aren't), 1) 'generator' be added to __builtin__ 2) 'generator' be added to types.py and its __module__ be set to 'types' 3) 'generator' be added to .py and its __module__ be set to '' (and a name for the module chosen) Me, I'm pretty much agnostic towards which solution is chosen, and if this one isn't it, fine with me. I just want to see python be truthful about where types are defined, whatever form that takes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 14:39 Message: Logged In: YES user_id=1344176 Originator: NO I agree with Martin. This is going to be taken care of in Python 3 (somehow) regardless. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-27 01:20 Message: Logged In: YES user_id=21627 I don't like to see further __builtin__ pollution, so I recommend to reject this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 From noreply at sourceforge.net Mon Mar 12 01:24:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 17:24:26 -0700 Subject: [Patches] [ python-Patches-922167 ] Patch to 742342 Crash on recursive reload Message-ID: Patches item #922167, was opened at 2004-03-23 23:17 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to 742342 Crash on recursive reload Initial Comment: Modules that causes a recursive reload cause a program abort. Easy for python developer to fix in their code, but the python interpreter shouldn't crash. This patch guards against circular reloading. This protection comes by an additional dictionary stored in the interpreter state to keep trakc of modules that are reloading. Recursive imports are protected against in a similar manner ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 20:24 Message: Logged In: YES user_id=1344176 Originator: NO I've updated this patch to a recent SVN revision and worked up a test case. What do you think, Martin? File Added: reload.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 09:53 Message: Logged In: YES user_id=21627 Originator: NO Can you please also provide a test suite change to demonstrate the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 From noreply at sourceforge.net Mon Mar 12 01:40:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 17:40:54 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 20:51 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Moonz (mooonz) Assigned to: Nobody/Anonymous (nobody) Summary: httplib gzip support Initial Comment: Add gzip support for httplib. It seems to work correctly - according to the tests I did done, but some points should be altered (I think to the putrequest method, where I didn't change anything - except the two lines of comments who said that the gzip support is not included) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 01:40 Message: Logged In: YES user_id=51702 Originator: NO I have applied and tested this patch. The code seems to be correct. Fetching gzipped data from www.mozilla.org works as it should. What the patch does is change Accept-Encoding from identity to identity,gzip;q=0.9. That hints the HTTP server that we can handle gzipped data. Some servers take the hint and sends us gzipped data (www.mozilla.org is such a server). We check if that is so by checking the Content-Encoding header in the HTTP response headers. If that is set to gzip, the body of the response is gzipped data. What then happens is that we create a hacked GzipFile object that works on a wrapped version of the HTTPResponse itself. It has to be hacked, because GzipFile works by seeking to the end of the file object. That ofcourse does not work for us, because the whole file is not available. But this hacked version employs some kind of StringIO trick so that instead of seeking to the end of the file, it seeks to the end of the read data. So HTTPResponse aquires a reference to GzipFile2 which it reads from. GzipFile2 in turn, has a reference to GzipedHTTPIO (the wrapper) which in turn references the HTTPResponse. The read method in HTTPResponse invokes the read method on GzipedFile2 which invokes the read of GzipedHTTPIO which invokes the read of HTTPResponse. But GzipedHTTPIO breaks the potential recursion by specifying raw=True which means that it want HTTPResponse to feed it uncompressed data. A very, very clever scheme. I hope this information is useful. It took me way to long to get this far. Originally I thought that this patch should be rejected because it is just to damn complicated, but then I saw that the rest of httplib.py is equally complicated. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-01 00:38 Message: Logged In: YES user_id=1188172 This will need documentation and test suite changes, too. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 20:54 Message: Logged In: YES user_id=826215 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 20:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 From noreply at sourceforge.net Mon Mar 12 01:49:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 17:49:13 -0700 Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath() Message-ID: Patches item #677890, was opened at 2003-01-30 20:23 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: add optional CWD argument to os.path.abspath() Initial Comment: I would like to add an optional second argument to os.path.abspath() to allow specifying the directory with respect to which the path should be made absolute. This would be much like the optional second argument of the expand-file-name function in emacs: (expand-file-name NAME &optional DEFAULT-DIRECTORY) The patch is against python 2.2.2. I am running RH 6.3 linux but that should not matter. thanks Greg Klanderman gak at klanderman.net ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 20:49 Message: Logged In: YES user_id=1344176 Originator: NO What's your motivating use-case for this? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-21 08:55 Message: Logged In: YES user_id=469548 Well, depends on what you mean by 'support'. I don't think anyone seriously objects, but there doesn't seem to be anyone who really cares either. That usually means that if you care enough to create a complete implementation (including tests and documentation changes) yourself, the patch will be accepted. So please submit a new patch if you do care enough. ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-02-05 13:09 Message: Logged In: YES user_id=698972 i can submit a patch for those other versions of abspath. but i'd rather know whether there is support for this change before doing that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:16 Message: Logged In: YES user_id=357491 And don't forget riscospath.py found in the plat-risc directory in Lib in the source distribution. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:06 Message: Logged In: YES user_id=357491 What about ntpath.py and os2emxpath.py? ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-01-30 20:28 Message: Logged In: YES user_id=698972 sorry, trying again to attach the patch.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:01:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:01:24 -0700 Subject: [Patches] [ python-Patches-1678662 ] ftp.python.org does not exist anymore Message-ID: Patches item #1678662, was opened at 2007-03-12 02:01 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=1678662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: ftp.python.org does not exist anymore Initial Comment: ftp.python.org does not exist. So the testcode in urllib.py must use a more stable FTP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678662&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:10:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:10:42 -0700 Subject: [Patches] [ python-Patches-808210 ] fix for external test regression in test.regrtest Message-ID: Patches item #808210, was opened at 2003-09-17 18:48 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808210&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: fix for external test regression in test.regrtest Initial Comment: A detailed description of the bug introduced in Python 2.3 is here: http://sourceforge.net/tracker/index.php? func=detail&aid=798274&group_id=5470&atid=105470 This patch implements the solution as suggested in the report: if a testdir argument is provided and the test module is not in a package, it attempts to import modules from that directory. This restores compatibility with the test suites I wrote in Python 2.2, and does not interfere with the current behavior as used by the Python regression test suite. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 21:10 Message: Logged In: YES user_id=1344176 Originator: NO regrtest's purpose is to test Python; third-party projects wishing to use regrtest in their own test suites would do well to customize it for their particular needs. ---------------------------------------------------------------------- Comment By: Nicholas Riley (nriley) Date: 2003-10-02 15:09 Message: Logged In: YES user_id=34933 Sorry, I'm not familiar with Python patch policies, but it seems a second 2.3.x release is about to be released without this patch included. This makes it difficult for users of the test suite I wrote to use it, because they have to replace their version of regrtest.py with mine, or go back to Python 2.2. Is there anything else I need to do in order to get this version incorporated? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=808210&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:19:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:19:54 -0700 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 21:28 Message generated for change (Comment added) made by aminusfu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2007-03-12 01:19 Message: Logged In: YES user_id=967320 Originator: NO Why not subclass threading._Thread and override just the run method? It would make more sense, then, to stick with the "cancel" method name instead of "end". ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 13:56 Message: Logged In: YES user_id=51702 Originator: YES "I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)" Actually, you get something very very weird. Try "t = Thread(); for x in range(10): t.start()". But it is the fault of the Thread class and above my head to fix anyhow. :) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 22:21 Message: Logged In: YES user_id=51702 Originator: YES Here is finished patch. It includes both documentation and a few unit tests. File Added: add-PeriodicTimer-2.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 22:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 19:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 07:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:35:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:35:05 -0700 Subject: [Patches] [ python-Patches-816787 ] urllib2.URLError don't calll IOError.__init__ Message-ID: Patches item #816787, was opened at 2003-10-02 16:16 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=816787&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2.URLError don't calll IOError.__init__ Initial Comment: The comments says it's not needed by in the case of: --------------- from urllib2 import URLError u = URLError(1) u[-1] Traceback (most recent call last): File "u.py", line 6, in ? u[-1] AttributeError: URLError instance has no attribute 'args' -------------- it's not what we excpect. Attaching a patch to call IOError.__init__ ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 21:35 Message: Logged In: YES user_id=1344176 Originator: NO Closing, per jjlee's suggestion. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-05-19 17:10 Message: Logged In: YES user_id=261020 This should be closed: If anybody has any further bright ideas on making urllib2's exceptions more beautiful, they can always submit a new patch. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-06 01:10 Message: Logged In: YES user_id=31392 I've changed URLError to call IOError.__init__(). That's an improvement, but it's still not great. The typical EnvironmentError has a two- or three-tuple where item 0 is the errno, item 1 is a string explaining the error, and item 3 is a filenumber. The change will creates args, but won't set errno or strerrror. Code expecting an errno in args[0] will be surprised. What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=816787&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:42:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:42:23 -0700 Subject: [Patches] [ python-Patches-1678668 ] fix a bug mixing up 0.0 and-0.0 Message-ID: Patches item #1678668, was opened at 2007-03-11 18:42 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=1678668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: fix a bug mixing up 0.0 and-0.0 Initial Comment: When 0.0 and -0.0 occur in the same compilation unit (e.g. function), the first one to occur gets used in lieu of all occurrences of the other. So, I've added a unittest to confirm this bug, and slightly tweaked an optimization performed in ast.c (_exactly_ along the lines of the similar tweak that's already there in the similar optimization performed in peephole.c) to remove the bug (which was not in the latest released 2.4 but keeps resurfacing -- hopefully no longer, w/the new unittest). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:55:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:55:43 -0700 Subject: [Patches] [ python-Patches-1678668 ] fix a bug mixing up 0.0 and-0.0 Message-ID: Patches item #1678668, was opened at 2007-03-11 18:42 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: fix a bug mixing up 0.0 and-0.0 Initial Comment: When 0.0 and -0.0 occur in the same compilation unit (e.g. function), the first one to occur gets used in lieu of all occurrences of the other. So, I've added a unittest to confirm this bug, and slightly tweaked an optimization performed in ast.c (_exactly_ along the lines of the similar tweak that's already there in the similar optimization performed in peephole.c) to remove the bug (which was not in the latest released 2.4 but keeps resurfacing -- hopefully no longer, w/the new unittest). ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2007-03-11 18:55 Message: Logged In: YES user_id=60314 Originator: YES Forgot to mention that this patch fixes bug 1678380 Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 From noreply at sourceforge.net Mon Mar 12 02:58:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 18:58:49 -0700 Subject: [Patches] [ python-Patches-1678662 ] ftp.python.org does not exist anymore Message-ID: Patches item #1678662, was opened at 2007-03-11 21:01 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) >Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: ftp.python.org does not exist anymore Initial Comment: ftp.python.org does not exist. So the testcode in urllib.py must use a more stable FTP. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-11 21:58 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54278 (trunk), r54279 (release25-maint). Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678662&group_id=5470 From noreply at sourceforge.net Mon Mar 12 05:05:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 21:05:26 -0700 Subject: [Patches] [ python-Patches-1678668 ] fix a bug mixing up 0.0 and-0.0 Message-ID: Patches item #1678668, was opened at 2007-03-12 01:42 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: fix a bug mixing up 0.0 and-0.0 Initial Comment: When 0.0 and -0.0 occur in the same compilation unit (e.g. function), the first one to occur gets used in lieu of all occurrences of the other. So, I've added a unittest to confirm this bug, and slightly tweaked an optimization performed in ast.c (_exactly_ along the lines of the similar tweak that's already there in the similar optimization performed in peephole.c) to remove the bug (which was not in the latest released 2.4 but keeps resurfacing -- hopefully no longer, w/the new unittest). ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-12 04:05 Message: Logged In: YES user_id=703403 Originator: NO Works for me. Mark ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-12 01:55 Message: Logged In: YES user_id=60314 Originator: YES Forgot to mention that this patch fixes bug 1678380 Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 From noreply at sourceforge.net Mon Mar 12 05:31:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 21:31:05 -0700 Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath() Message-ID: Patches item #677890, was opened at 2003-01-30 20:23 Message generated for change (Comment added) made by gregklanderman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: add optional CWD argument to os.path.abspath() Initial Comment: I would like to add an optional second argument to os.path.abspath() to allow specifying the directory with respect to which the path should be made absolute. This would be much like the optional second argument of the expand-file-name function in emacs: (expand-file-name NAME &optional DEFAULT-DIRECTORY) The patch is against python 2.2.2. I am running RH 6.3 linux but that should not matter. thanks Greg Klanderman gak at klanderman.net ---------------------------------------------------------------------- >Comment By: Greg Klanderman (gregklanderman) Date: 2007-03-12 00:31 Message: Logged In: YES user_id=698972 Originator: YES Well, it's been 4 years and I'd pretty much forgotten about this.. but I believe I had a case where my program had some configuration item - the base directory w.r.t. which other files were to be found. So if you have one of those file names, it's convenient to use abspath() except you don't want it relative to the process' cwd, you want it relative to the configured directory. Anyway, it's no big deal, you can just close this if you want. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 20:49 Message: Logged In: YES user_id=1344176 Originator: NO What's your motivating use-case for this? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-21 08:55 Message: Logged In: YES user_id=469548 Well, depends on what you mean by 'support'. I don't think anyone seriously objects, but there doesn't seem to be anyone who really cares either. That usually means that if you care enough to create a complete implementation (including tests and documentation changes) yourself, the patch will be accepted. So please submit a new patch if you do care enough. ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-02-05 13:09 Message: Logged In: YES user_id=698972 i can submit a patch for those other versions of abspath. but i'd rather know whether there is support for this change before doing that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:16 Message: Logged In: YES user_id=357491 And don't forget riscospath.py found in the plat-risc directory in Lib in the source distribution. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:06 Message: Logged In: YES user_id=357491 What about ntpath.py and os2emxpath.py? ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-01-30 20:28 Message: Logged In: YES user_id=698972 sorry, trying again to attach the patch.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 From noreply at sourceforge.net Mon Mar 12 05:34:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 21:34:55 -0700 Subject: [Patches] [ python-Patches-677890 ] add optional CWD argument to os.path.abspath() Message-ID: Patches item #677890, was opened at 2003-01-30 20:23 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Greg Klanderman (gregklanderman) Assigned to: Nobody/Anonymous (nobody) Summary: add optional CWD argument to os.path.abspath() Initial Comment: I would like to add an optional second argument to os.path.abspath() to allow specifying the directory with respect to which the path should be made absolute. This would be much like the optional second argument of the expand-file-name function in emacs: (expand-file-name NAME &optional DEFAULT-DIRECTORY) The patch is against python 2.2.2. I am running RH 6.3 linux but that should not matter. thanks Greg Klanderman gak at klanderman.net ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2007-03-12 00:31 Message: Logged In: YES user_id=698972 Originator: YES Well, it's been 4 years and I'd pretty much forgotten about this.. but I believe I had a case where my program had some configuration item - the base directory w.r.t. which other files were to be found. So if you have one of those file names, it's convenient to use abspath() except you don't want it relative to the process' cwd, you want it relative to the configured directory. Anyway, it's no big deal, you can just close this if you want. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 20:49 Message: Logged In: YES user_id=1344176 Originator: NO What's your motivating use-case for this? ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-08-21 08:55 Message: Logged In: YES user_id=469548 Well, depends on what you mean by 'support'. I don't think anyone seriously objects, but there doesn't seem to be anyone who really cares either. That usually means that if you care enough to create a complete implementation (including tests and documentation changes) yourself, the patch will be accepted. So please submit a new patch if you do care enough. ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-02-05 13:09 Message: Logged In: YES user_id=698972 i can submit a patch for those other versions of abspath. but i'd rather know whether there is support for this change before doing that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:16 Message: Logged In: YES user_id=357491 And don't forget riscospath.py found in the plat-risc directory in Lib in the source distribution. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-02-05 05:06 Message: Logged In: YES user_id=357491 What about ntpath.py and os2emxpath.py? ---------------------------------------------------------------------- Comment By: Greg Klanderman (gregklanderman) Date: 2003-01-30 20:28 Message: Logged In: YES user_id=698972 sorry, trying again to attach the patch.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=677890&group_id=5470 From noreply at sourceforge.net Mon Mar 12 06:56:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 22:56:02 -0700 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 08:41 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-11 23:56 Message: Logged In: YES user_id=1727609 Originator: YES File Added: test_threadedtempfile.py.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 11:59 Message: Logged In: YES user_id=1344176 Originator: NO One question before I apply this: why did you leave if t.error_count: print '%s errors:\n%s' % (t.getName(), t.errors.getvalue()) in ThreadedTempFileTest.test_main()? Why not make it some kind of assertion? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 10:24 Message: Logged In: YES user_id=1344176 Originator: NO They can stay out; I just wanted to know the reason. This patch looks good to me. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-05 22:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 17:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 11:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Mon Mar 12 06:58:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 22:58:03 -0700 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 08:41 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-11 23:58 Message: Logged In: YES user_id=1727609 Originator: YES RE: >One question before I apply this: why did you leave > >if t.error_count: > print '%s errors:\n%s' % (t.getName(), t.errors.getvalue()) I missed that line - removed it and made the final assert more useful. See patch v2. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-11 23:56 Message: Logged In: YES user_id=1727609 Originator: YES File Added: test_threadedtempfile.py.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 11:59 Message: Logged In: YES user_id=1344176 Originator: NO One question before I apply this: why did you leave if t.error_count: print '%s errors:\n%s' % (t.getName(), t.errors.getvalue()) in ThreadedTempFileTest.test_main()? Why not make it some kind of assertion? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 10:24 Message: Logged In: YES user_id=1344176 Originator: NO They can stay out; I just wanted to know the reason. This patch looks good to me. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-05 22:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 17:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 11:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Mon Mar 12 07:22:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 23:22:15 -0700 Subject: [Patches] [ python-Patches-1668100 ] urllib2.urlopen() raises OSError instead of URLError Message-ID: Patches item #1668100, was opened at 2007-02-24 16:20 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.urlopen() raises OSError instead of URLError Initial Comment: See bug 1591774. The base problem is that when passing a file:// url into urllib2.urlopen() for a file that doesn't exist, the os.stat() call fails with an OSError exception which is not caught. The documentation for urllib2 states that urlopen() raises a URLError upon error. This bug can also be triggered when fetching a http:// url. A misconfigured webserver can cause urllib2.urlopen to use the FileHandler (see bug report). This patch catches OSError in the FileHandler class and raises it as a URLError. Unit test included. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 00:22 Message: Logged In: YES user_id=1727609 Originator: YES File Added: bug_1591774_failing_test_and_bugfix_v2.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 11:18 Message: Logged In: YES user_id=1344176 Originator: NO I think it should be fixed to raise URLError. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-25 21:12 Message: Logged In: YES user_id=1727609 Originator: YES Sorry, I looked at that commented out section and didn't immediately see what it was for, so ignored it. I'm not sure what the correct behavior would be in this case. Getting a OSError from a http:// url is unsettling. I guess that if I were using the library, I would only want to have to catch one type of exception. Having to catch both URLError and OSError is inconvenient. If I were looking for a file on disk I would use file(), so the only time someone probably uses the file:// url syntax is when the end user is entering the URL. The end user wouldn't distinguish between the two exception types in this case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 10:01 Message: Logged In: YES user_id=261020 Originator: NO I recall that when I wrote the urllib2 tests there were a fair few cases similar to this -- indeed, this particular one is already marked in the tests with an "XXXX" in test_file(). What do other people think about these -- should they be fixed, or the docs changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 From noreply at sourceforge.net Mon Mar 12 07:23:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 11 Mar 2007 23:23:52 -0700 Subject: [Patches] [ python-Patches-1668100 ] urllib2.urlopen() raises OSError instead of URLError Message-ID: Patches item #1668100, was opened at 2007-02-24 16:20 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.urlopen() raises OSError instead of URLError Initial Comment: See bug 1591774. The base problem is that when passing a file:// url into urllib2.urlopen() for a file that doesn't exist, the os.stat() call fails with an OSError exception which is not caught. The documentation for urllib2 states that urlopen() raises a URLError upon error. This bug can also be triggered when fetching a http:// url. A misconfigured webserver can cause urllib2.urlopen to use the FileHandler (see bug report). This patch catches OSError in the FileHandler class and raises it as a URLError. Unit test included. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 00:23 Message: Logged In: YES user_id=1727609 Originator: YES Added patch v2 which is a patch against trunk, and adds in the tests that were commented out (they previously failed). ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 00:22 Message: Logged In: YES user_id=1727609 Originator: YES File Added: bug_1591774_failing_test_and_bugfix_v2.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 11:18 Message: Logged In: YES user_id=1344176 Originator: NO I think it should be fixed to raise URLError. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-25 21:12 Message: Logged In: YES user_id=1727609 Originator: YES Sorry, I looked at that commented out section and didn't immediately see what it was for, so ignored it. I'm not sure what the correct behavior would be in this case. Getting a OSError from a http:// url is unsettling. I guess that if I were using the library, I would only want to have to catch one type of exception. Having to catch both URLError and OSError is inconvenient. If I were looking for a file on disk I would use file(), so the only time someone probably uses the file:// url syntax is when the end user is entering the URL. The end user wouldn't distinguish between the two exception types in this case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 10:01 Message: Logged In: YES user_id=261020 Originator: NO I recall that when I wrote the urllib2 tests there were a fair few cases similar to this -- indeed, this particular one is already marked in the tests with an "XXXX" in test_file(). What do other people think about these -- should they be fixed, or the docs changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 From noreply at sourceforge.net Mon Mar 12 09:36:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 01:36:17 -0700 Subject: [Patches] [ python-Patches-1677862 ] site.py small ?bug fix | change? Message-ID: Patches item #1677862, was opened at 2007-03-10 15:34 Message generated for change (Comment added) made by koder_ua You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) Assigned to: Martin v. L?wis (loewis) Summary: site.py small ?bug fix | change? Initial Comment: change line 137(r54258) from if line.startswith("import"): to if line.startswith("import "): to allow add dirs like import_from_here to modules search path ---------------------------------------------------------------------- >Comment By: KDanilov aka koder (koder_ua) Date: 2007-03-12 10:36 Message: Logged In: YES user_id=1620221 Originator: YES File Added: site_space_patch_v2.diff ---------------------------------------------------------------------- Comment By: KDanilov aka koder (koder_ua) Date: 2007-03-11 13:08 Message: Logged In: YES user_id=1620221 Originator: YES add "or line.startswith("import\t")" File Added: site_space_patch_v2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 23:31 Message: Logged In: YES user_id=849994 Originator: NO I can't see a problem with this change other than you could in theory also put a tab after "import". Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 From noreply at sourceforge.net Mon Mar 12 09:58:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 01:58:09 -0700 Subject: [Patches] [ python-Patches-1009811 ] Add missing types to __builtin__ Message-ID: Patches item #1009811, was opened at 2004-08-16 07:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Closed Resolution: Postponed Priority: 5 Private: No Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: Add missing types to __builtin__ Initial Comment: Add most of the missing type objects to __builtin__. Adds the following: ellipsis (not to be confused with Ellipsis, which is the object of this type) builtin_function_or_method dictproxy generator PyCObject classobj instance instancemethod cell NoneType NotImplementedType frame function module traceback code Does not add the rest of the names mentioned in my email, as I'm unsure if they got an approval or were silently ignored. I'm not convinced that it's a good idea to put the rest in __builtin__, myself. See also: and ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 09:58 Message: Logged In: YES user_id=21627 Originator: NO There are more options, e.g. __module__ set to None, and generator being in no module. I think this is the one I would prefer. In any case, it seems very difficult to achieve consensus on this, so it just won't get fixed for the moment. ---------------------------------------------------------------------- Comment By: James Y Knight (foom) Date: 2007-03-12 00:47 Message: Logged In: YES user_id=1104715 Originator: YES I only submitted this because I was directed to. To reiterate, the actual problem is that the classes claim to be defined in a place they aren't actually defined in. Quoting myself: Sooo should (for 'generator' in objects that claim to be in __builtin__ but aren't), 1) 'generator' be added to __builtin__ 2) 'generator' be added to types.py and its __module__ be set to 'types' 3) 'generator' be added to .py and its __module__ be set to '' (and a name for the module chosen) Me, I'm pretty much agnostic towards which solution is chosen, and if this one isn't it, fine with me. I just want to see python be truthful about where types are defined, whatever form that takes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 19:39 Message: Logged In: YES user_id=1344176 Originator: NO I agree with Martin. This is going to be taken care of in Python 3 (somehow) regardless. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-01-27 07:20 Message: Logged In: YES user_id=21627 I don't like to see further __builtin__ pollution, so I recommend to reject this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1009811&group_id=5470 From noreply at sourceforge.net Mon Mar 12 10:16:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 02:16:11 -0700 Subject: [Patches] [ python-Patches-1678668 ] fix a bug mixing up 0.0 and-0.0 Message-ID: Patches item #1678668, was opened at 2007-03-12 02:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: fix a bug mixing up 0.0 and-0.0 Initial Comment: When 0.0 and -0.0 occur in the same compilation unit (e.g. function), the first one to occur gets used in lieu of all occurrences of the other. So, I've added a unittest to confirm this bug, and slightly tweaked an optimization performed in ast.c (_exactly_ along the lines of the similar tweak that's already there in the similar optimization performed in peephole.c) to remove the bug (which was not in the latest released 2.4 but keeps resurfacing -- hopefully no longer, w/the new unittest). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 10:16 Message: Logged In: YES user_id=21627 Originator: NO I'm still doubtful whether this deserves fixing. However, if it does, it should produce different literals for +0j and -0j as well. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-12 05:05 Message: Logged In: YES user_id=703403 Originator: NO Works for me. Mark ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2007-03-12 02:55 Message: Logged In: YES user_id=60314 Originator: YES Forgot to mention that this patch fixes bug 1678380 Alex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678668&group_id=5470 From noreply at sourceforge.net Mon Mar 12 11:10:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 03:10:37 -0700 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 11:10 Message: Logged In: YES user_id=51702 Originator: YES There is no threading._Thread class. ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2007-03-12 02:19 Message: Logged In: YES user_id=967320 Originator: NO Why not subclass threading._Thread and override just the run method? It would make more sense, then, to stick with the "cancel" method name instead of "end". ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 14:56 Message: Logged In: YES user_id=51702 Originator: YES "I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)" Actually, you get something very very weird. Try "t = Thread(); for x in range(10): t.start()". But it is the fault of the Thread class and above my head to fix anyhow. :) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 23:21 Message: Logged In: YES user_id=51702 Originator: YES Here is finished patch. It includes both documentation and a few unit tests. File Added: add-PeriodicTimer-2.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 23:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 21:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Mon Mar 12 12:02:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 04:02:18 -0700 Subject: [Patches] [ python-Patches-1677862 ] site.py small ?bug fix | change? Message-ID: Patches item #1677862, was opened at 2007-03-10 14:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: KDanilov aka koder (koder_ua) Assigned to: Martin v. L?wis (loewis) Summary: site.py small ?bug fix | change? Initial Comment: change line 137(r54258) from if line.startswith("import"): to if line.startswith("import "): to allow add dirs like import_from_here to modules search path ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 12:02 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54285. Not backporting it, since it is technically a new feature (it also required a documentation change). ---------------------------------------------------------------------- Comment By: KDanilov aka koder (koder_ua) Date: 2007-03-12 09:36 Message: Logged In: YES user_id=1620221 Originator: YES File Added: site_space_patch_v2.diff ---------------------------------------------------------------------- Comment By: KDanilov aka koder (koder_ua) Date: 2007-03-11 12:08 Message: Logged In: YES user_id=1620221 Originator: YES add "or line.startswith("import\t")" File Added: site_space_patch_v2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 22:31 Message: Logged In: YES user_id=849994 Originator: NO I can't see a problem with this change other than you could in theory also put a tab after "import". Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677862&group_id=5470 From noreply at sourceforge.net Mon Mar 12 13:17:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 05:17:26 -0700 Subject: [Patches] [ python-Patches-1660500 ] Hide iteration variable in list comprehensions Message-ID: Patches item #1660500, was opened at 2007-02-15 21:29 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1660500&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nick Coghlan (ncoghlan) Assigned to: Georg Brandl (gbrandl) Summary: Hide iteration variable in list comprehensions Initial Comment: This patch hides the iteration variable in list comprehensions. It adds new tests (modelled on the generator expression tests) and also removes some del statements from the standard library (where code previously cleaned up its own namespace). The changes to symtable.[ch] are more significant than strictly necessary - I found it necessary to spend some time cleaning up the code in order to understand what was needed for the list comprehension changes. Given that the 2.x and 3.0 compilers have already diverged fairly significantly, I don't believe this will make the process of keeping them in sync any more difficult than it is already. Assigning to Georg for initial review (as his set comprehensions patch provided a great deal of inspiration for this one). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2007-03-12 22:17 Message: Logged In: YES user_id=1038590 Originator: YES The patch for 'nonlocal' was applied since Georg & I started working on this. It's going to take me a bit of fiddling to update the patch so that the parser/compiler stage play well with each other (I really should have just believed the patch utility when it reported a conflict trying to patch symtable.c). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 08:56 Message: Logged In: YES user_id=6380 Originator: NO Can't say that slowdown bothers me much, if it's typical. However I think you need to do a svn up in your workspace and regenerate the patch; I get FAILED message from patch on all the generated files and a few others: graminit.[ch], symtable.[ch], Python-ast.c, symbol.py. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-26 20:30 Message: Logged In: YES user_id=849994 Originator: NO Okay, I looked at the patch, and apart from a refleak in one of the compiler methods I couldn't find anything wrong. I then manually applied the rest of my set comprehension patch. The result is attached. Grammar, AST and compilation for comprehensions are now really unified. It passes the tests for listcomps, genexps and setcomps. I couldn't check properly for refleaks since e.g. test_genexps leaks in the branch head, as well as some other tests. I'm currently searching for the offending revision(s)... File Added: new-set-comps.diff ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-02-15 22:13 Message: Logged In: YES user_id=1038590 Originator: YES For reference, the original set comprehensions patch & the py3k list discussion: http://www.python.org/sf/1548388 http://mail.python.org/pipermail/python-3000/2006-December/005188.html Note that the current patch ended up looking a *lot* like the original one (the main difference specific to list comprehensions is that the temporary list is built in the inner scope and then returned rather than being passed in as an argument. Additionally, the code has been unified only for the symtable stage - the AST and compilation stages still use separate code for listcomps and genexps). It turns out that there are some really curly scoping problems that using a nested function deals with automatically (see the new test_listcomps.py in the patch for examples). Having a more efficient mechanism specifically for 'transient' scopes like this is an interesting idea, but it's far from easy (mainly because the variables in the scope still need to be properly visible in scopes it *contains*). Adding set comprehensions on top of this patch should be pretty straightforward. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2007-02-15 21:53 Message: Logged In: YES user_id=1038590 Originator: YES Speed measurements show a significant speed up over trunk & Python 2.4 for module/class level code: (Python 2.4)$ python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 239 msec per loop (Python 2.x trunk)$ ./python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 193 msec per loop (Python 3000)$ ./python -m timeit -s "seq=range(1000)" "[[x for x in seq] for y in seq]" 10 loops, best of 3: 176 msec per loop This is almost certainly due to the variables and the list object becoming function locals. There is a slowdown inside a function (but we are still faster than Python 2.4): (Python 2.4)$ python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 259 msec per loop (Python 2.x trunk)$ ./python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 176 msec per loop (Python 3000)$ ./python -m timeit -s "seq=range(1000)" -s "def f(): return [[x for x in seq] for y in seq]" "f()" 10 loops, best of 3: 185 msec per loop ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1660500&group_id=5470 From noreply at sourceforge.net Mon Mar 12 13:21:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 05:21:11 -0700 Subject: [Patches] [ python-Patches-922167 ] Patch to 742342 Crash on recursive reload Message-ID: Patches item #922167, was opened at 2004-03-24 05:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) >Assigned to: Collin Winter (collinwinter) Summary: Patch to 742342 Crash on recursive reload Initial Comment: Modules that causes a recursive reload cause a program abort. Easy for python developer to fix in their code, but the python interpreter shouldn't crash. This patch guards against circular reloading. This protection comes by an additional dictionary stored in the interpreter state to keep trakc of modules that are reloading. Recursive imports are protected against in a similar manner ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 13:21 Message: Logged In: YES user_id=21627 Originator: NO The failure I see is not an interpreter crash, but an ImportError. Is that what everybody else sees also, or does it really fault the interpreter? If that is the bug to be fixed, the patch looks fine, please apply. There is one line that uses space rather than tab; that should be corrected before committing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 01:24 Message: Logged In: YES user_id=1344176 Originator: NO I've updated this patch to a recent SVN revision and worked up a test case. What do you think, Martin? File Added: reload.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:53 Message: Logged In: YES user_id=21627 Originator: NO Can you please also provide a test suite change to demonstrate the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 From noreply at sourceforge.net Mon Mar 12 13:53:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 05:53:00 -0700 Subject: [Patches] [ python-Patches-922167 ] Patch to 742342 Crash on recursive reload Message-ID: Patches item #922167, was opened at 2004-03-24 04:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Collin Winter (collinwinter) Summary: Patch to 742342 Crash on recursive reload Initial Comment: Modules that causes a recursive reload cause a program abort. Easy for python developer to fix in their code, but the python interpreter shouldn't crash. This patch guards against circular reloading. This protection comes by an additional dictionary stored in the interpreter state to keep trakc of modules that are reloading. Recursive imports are protected against in a similar manner ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 12:53 Message: Logged In: YES user_id=849994 Originator: NO With a file "foo.py" containing "import foo; reload(foo)", the interpreter segfaults here (linux x86). With the patch, it doesn't anymore. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 12:21 Message: Logged In: YES user_id=21627 Originator: NO The failure I see is not an interpreter crash, but an ImportError. Is that what everybody else sees also, or does it really fault the interpreter? If that is the bug to be fixed, the patch looks fine, please apply. There is one line that uses space rather than tab; that should be corrected before committing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 00:24 Message: Logged In: YES user_id=1344176 Originator: NO I've updated this patch to a recent SVN revision and worked up a test case. What do you think, Martin? File Added: reload.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 14:53 Message: Logged In: YES user_id=21627 Originator: NO Can you please also provide a test suite change to demonstrate the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 From noreply at sourceforge.net Mon Mar 12 14:18:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 06:18:22 -0700 Subject: [Patches] [ python-Patches-1591665 ] adding __dir__ Message-ID: Patches item #1591665, was opened at 2006-11-06 21:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 6 Private: No Submitted By: ganges master (gangesmaster) Assigned to: Georg Brandl (gbrandl) Summary: adding __dir__ Initial Comment: in accordance with http://mail.python.org/pipermail/python-dev/2006-November/069865.html i've written a patch that allows objects to define their own introspection mechanisms, by providing __dir__. with this patch: * dir() returns the locals. this is done in builtin_dir() * dir(obj) returns the attributes of obj, by invoking PyObject_Dir() * if obj->ob_type has "__dir__", it is used. note that it must return a list! * otherwise, use default the mechanism of collecting attributes * for module objects, return __dict__.keys() * for type objects, return __dict__.keys() + dir(obj.__base__) * for all other objects, return __dict__.keys() + __members__ + __methods__ + dir(obj.__class__) * builtin_dir takes care of sorting the list ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:18 Message: Logged In: YES user_id=849994 Originator: NO Done in rev. 54287. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-11 02:36 Message: Logged In: YES user_id=33168 Originator: NO I think this should be backported to 2.6. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-10 22:27 Message: Logged In: YES user_id=849994 Originator: NO Applied to Python 3000 branch in rev. 54265. Leaving open for the case that there's interest in backporting to 2.6. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-12-19 21:12 Message: Logged In: YES user_id=1406776 Originator: YES i guess the demo isn't updated/relevant anymore. instead, concrete tests were added to lib/tests/test_builtin.py ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-11-23 12:11 Message: Logged In: YES user_id=4771 Originator: NO Line 20 in demo.py: assert "__getitem__" in dir(x) looks strange to me... Foo doesn't inherit from any sequence or mapping type. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-11 21:31 Message: Logged In: YES user_id=1406776 > PyObject_CallFunctionObjArgs(dirfunc, obj, NULL) done > Couldn't __dir__ also be allowed to return a tuple? no, because tuples are not sortable, and i don't want to over complicate the c-side code of PyObject_Dir. having __dir__ returning only a list is equivalent to __repr__ returning only strings. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 19:58 Message: Logged In: YES user_id=849994 * Instead of doing PyObject_CallFunction(dirfunc, "O", obj) you should do PyObject_CallFunctionObjArgs(dirfunc, obj, NULL). * Couldn't __dir__ also be allowed to return a tuple? ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-08 11:22 Message: Logged In: YES user_id=1406776 i like to init all my locals ("just in case"), but if the rest of the code does not adhere my style, i'll change that. anyway, i made the changes to the code, updated the docs, and added full tests (the original dir() wasn't test so thoroughly) -tomer ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-08 05:53 Message: Logged In: YES user_id=33168 tomer, do you know about configuring with --pydebug? That helps track down refleaks when running regrtest -R ::. object.c: _dir_locals: result is not necessary and locals doesn't need to be initialized as it's set on the next line. You could just declare and set it all on one line. _specialized_dir_type should be static. No need to init dict. Either don't init result or remove else result = NULL. I'd prefer removing the else and leaving the init. _specialized_dir_module should be static. No need to init dict. Can you get the name of the module and use that in the error msg: PyModule_GetName()? That would hopefully provide a nicer error msg. _generic_dir: No need to init dict. + /* XXX api change: how about falling to obj->ob_type + XXX if no __class__ exists? */ Do you mean falling *back*? Also, we've been using XXX(username): as the format for such comments. So this would be better as: /* XXX(tomer): Perhaps fall back to obj->ob_type if no __class__ exists? */ _dir_object: No need to init dirfunc. PyObject_Dir: No need to init result. Are there tests for all conditions? At least: * dir() * dir(obj) * dir(obj_with_no_dict) * dir(obj_with_no__class__) * dir(obj_with__methods__) * dir(obj_with__members__) * dir(module) * dir(module_with_no__dict__) * dir(module_with_invalid__dict__) There also need to be updates to Doc/lib/libfuncs.tex. If you can't deal with the markup, just do the best you can in text and someone else will fixup the markup. Thanks for attaching the patch as a single file, it's easier to deal with. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-11-07 15:37 Message: Logged In: YES user_id=1406776 okay: * builtin_dir directly calls PyObject_Dir * PyObject_Dir handles NULL argument and sorting * it is now completely compatible with the 2.5 API * fixed several refcount bugs (i wish we had a tracing gc :) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-11-06 22:52 Message: Logged In: YES user_id=1038590 The retrieval of locals on a NULL argument and the sorting step need to move back inside PyObject_Dir to avoid changing the C API. If the standard library's current C API tests didn't break on this version of the patch, then the final version of the patch should include enhanced tests for PyObject_Dir that pass both before and after the patch is applied to PyObject_Dir. Other than that, I didn't see any major problems on reading the code (i.e. refcounts and error handling looked pretty reasonable). I haven't actually run it though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1591665&group_id=5470 From noreply at sourceforge.net Mon Mar 12 14:38:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 06:38:15 -0700 Subject: [Patches] [ python-Patches-1675423 ] Make PyComplex_AsCComplex use __complex__ Message-ID: Patches item #1675423, was opened at 2007-03-07 03:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) >Assigned to: Georg Brandl (gbrandl) Summary: Make PyComplex_AsCComplex use __complex__ Initial Comment: The functions in the math module have the (pleasantly) surprising and apparently undocumented property that they'll accept not just floats, but any Python object having a float method: >>> class test1(object): ... def __float__(self): ... return 3. ... >>> from math import sqrt >>> sqrt(test1()) 1.7320508075688772 Based on this, one might expect the functions in the complex math module cmath to have the same property with respect to __complex__. But this isn't so: >>> class test2(object): ... def __complex__(self): ... return -3 + 0j ... >>> from cmath import sqrt as csqrt >>> csqrt(test2()) Traceback (most recent call last): File "", line 1, in TypeError: a float is required The real surprise is that the cmath functions *will* call the __float__ method, if it's available: >>> csqrt(test1()) (1.7320508075688772+0j) This patch expands the PyComplex_AsCComplex method so that it looks for a __complex__ method before looking for the __float__ method. This `fixes' the above behaviour. Should it be a documented feature that the math functions will make use of __float__? If so, and if the patched behaviour seems desirable, I'll add suitable tests to test_math and test_cmath. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:38 Message: Logged In: YES user_id=849994 Originator: NO I think it is the right thing to do. Test cases would be welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 From noreply at sourceforge.net Mon Mar 12 14:47:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 06:47:18 -0700 Subject: [Patches] [ python-Patches-1675423 ] Make PyComplex_AsCComplex use __complex__ Message-ID: Patches item #1675423, was opened at 2007-03-07 03:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Georg Brandl (gbrandl) Summary: Make PyComplex_AsCComplex use __complex__ Initial Comment: The functions in the math module have the (pleasantly) surprising and apparently undocumented property that they'll accept not just floats, but any Python object having a float method: >>> class test1(object): ... def __float__(self): ... return 3. ... >>> from math import sqrt >>> sqrt(test1()) 1.7320508075688772 Based on this, one might expect the functions in the complex math module cmath to have the same property with respect to __complex__. But this isn't so: >>> class test2(object): ... def __complex__(self): ... return -3 + 0j ... >>> from cmath import sqrt as csqrt >>> csqrt(test2()) Traceback (most recent call last): File "", line 1, in TypeError: a float is required The real surprise is that the cmath functions *will* call the __float__ method, if it's available: >>> csqrt(test1()) (1.7320508075688772+0j) This patch expands the PyComplex_AsCComplex method so that it looks for a __complex__ method before looking for the __float__ method. This `fixes' the above behaviour. Should it be a documented feature that the math functions will make use of __float__? If so, and if the patched behaviour seems desirable, I'll add suitable tests to test_math and test_cmath. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:47 Message: Logged In: YES user_id=849994 Originator: NO Please include both old-style and new-style classes in the test case, and for each one test if the check for a complex return from __complex__ works. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:38 Message: Logged In: YES user_id=849994 Originator: NO I think it is the right thing to do. Test cases would be welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 From noreply at sourceforge.net Mon Mar 12 15:13:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 07:13:26 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 23:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 14:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 20:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 17:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 17:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 22:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 23:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 23:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 00:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 00:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 15:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Mon Mar 12 15:28:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 07:28:17 -0700 Subject: [Patches] [ python-Patches-922167 ] Patch to 742342 Crash on recursive reload Message-ID: Patches item #922167, was opened at 2004-03-24 05:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Collin Winter (collinwinter) Summary: Patch to 742342 Crash on recursive reload Initial Comment: Modules that causes a recursive reload cause a program abort. Easy for python developer to fix in their code, but the python interpreter shouldn't crash. This patch guards against circular reloading. This protection comes by an additional dictionary stored in the interpreter state to keep trakc of modules that are reloading. Recursive imports are protected against in a similar manner ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 15:28 Message: Logged In: YES user_id=21627 Originator: NO Interesting. My system was OSX/x86. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:53 Message: Logged In: YES user_id=849994 Originator: NO With a file "foo.py" containing "import foo; reload(foo)", the interpreter segfaults here (linux x86). With the patch, it doesn't anymore. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 13:21 Message: Logged In: YES user_id=21627 Originator: NO The failure I see is not an interpreter crash, but an ImportError. Is that what everybody else sees also, or does it really fault the interpreter? If that is the bug to be fixed, the patch looks fine, please apply. There is one line that uses space rather than tab; that should be corrected before committing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 01:24 Message: Logged In: YES user_id=1344176 Originator: NO I've updated this patch to a recent SVN revision and worked up a test case. What do you think, Martin? File Added: reload.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:53 Message: Logged In: YES user_id=21627 Originator: NO Can you please also provide a test suite change to demonstrate the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 From noreply at sourceforge.net Mon Mar 12 16:07:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 08:07:32 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 21:34 Message generated for change (Comment added) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- >Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 15:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 22:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Mon Mar 12 16:58:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 08:58:14 -0700 Subject: [Patches] [ python-Patches-1678088 ] Refactor test_operations.py to use unittest. Message-ID: Patches item #1678088, was opened at 2007-03-10 17:42 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678088&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_operations.py to use unittest. Initial Comment: The summary is a bit of a misnomer. The contents of test_operations.py were moved into test_dict.py and both Lib/test/test_operations.py and Lib/test/output/test_operations should be removed. The attached patch adds the two tests currently in test_operations.py into test_dict.py. The tests were moved because they test the behaviour of dictionaries. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 11:58 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54290. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678088&group_id=5470 From noreply at sourceforge.net Mon Mar 12 17:50:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 09:50:57 -0700 Subject: [Patches] [ python-Patches-922167 ] Patch to 742342 Crash on recursive reload Message-ID: Patches item #922167, was opened at 2004-03-23 23:17 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Brian Leair (bleair2) Assigned to: Collin Winter (collinwinter) Summary: Patch to 742342 Crash on recursive reload Initial Comment: Modules that causes a recursive reload cause a program abort. Easy for python developer to fix in their code, but the python interpreter shouldn't crash. This patch guards against circular reloading. This protection comes by an additional dictionary stored in the interpreter state to keep trakc of modules that are reloading. Recursive imports are protected against in a similar manner ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 12:50 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54291 (trunk), r54294 (release25-maint). Thanks for the patch, Brian! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 10:28 Message: Logged In: YES user_id=21627 Originator: NO Interesting. My system was OSX/x86. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 08:53 Message: Logged In: YES user_id=849994 Originator: NO With a file "foo.py" containing "import foo; reload(foo)", the interpreter segfaults here (linux x86). With the patch, it doesn't anymore. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-12 08:21 Message: Logged In: YES user_id=21627 Originator: NO The failure I see is not an interpreter crash, but an ImportError. Is that what everybody else sees also, or does it really fault the interpreter? If that is the bug to be fixed, the patch looks fine, please apply. There is one line that uses space rather than tab; that should be corrected before committing. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 20:24 Message: Logged In: YES user_id=1344176 Originator: NO I've updated this patch to a recent SVN revision and worked up a test case. What do you think, Martin? File Added: reload.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 09:53 Message: Logged In: YES user_id=21627 Originator: NO Can you please also provide a test suite change to demonstrate the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=922167&group_id=5470 From noreply at sourceforge.net Mon Mar 12 18:00:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 10:00:25 -0700 Subject: [Patches] [ python-Patches-1168055 ] Add current dir when running try_run test program Message-ID: Patches item #1168055, was opened at 2005-03-21 21:49 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1168055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Phillip J. Eby (pje) Summary: Add current dir when running try_run test program Initial Comment: The try_run function in command/config.py is used to run a test program as part of configuring an extension module with "python setup.py config" before running "python setup.py build". When running the test program, the current directory is not included in the program name. So it attempts to run _configtest instead of ./_configtest. This works fine as long as the user has the current directory in the path. If not, the attempt to run _configtest fails. The patch adds the current directory in front of _configtest, so that the program runs even if the user does not have the current directory in the path. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 13:00 Message: Logged In: YES user_id=1344176 Originator: NO Phillip, any thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1168055&group_id=5470 From noreply at sourceforge.net Mon Mar 12 18:25:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 10:25:25 -0700 Subject: [Patches] [ python-Patches-1670993 ] Refactor test_threadedtempfile.py to use unittest. Message-ID: Patches item #1670993, was opened at 2007-02-28 10:41 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_threadedtempfile.py to use unittest. Initial Comment: This patch turns test_threadedtempfile.py into a unittest test file. There should be no changes in what the file tests. Input on this patch is welcome before I go too far on more of the old test files. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 13:25 Message: Logged In: YES user_id=1344176 Originator: NO I added an assert for 'ok', committed the result as r54295. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 01:58 Message: Logged In: YES user_id=1727609 Originator: YES RE: >One question before I apply this: why did you leave > >if t.error_count: > print '%s errors:\n%s' % (t.getName(), t.errors.getvalue()) I missed that line - removed it and made the final assert more useful. See patch v2. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 01:56 Message: Logged In: YES user_id=1727609 Originator: YES File Added: test_threadedtempfile.py.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 13:59 Message: Logged In: YES user_id=1344176 Originator: NO One question before I apply this: why did you leave if t.error_count: print '%s errors:\n%s' % (t.getName(), t.errors.getvalue()) in ThreadedTempFileTest.test_main()? Why not make it some kind of assertion? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 12:24 Message: Logged In: YES user_id=1344176 Originator: NO They can stay out; I just wanted to know the reason. This patch looks good to me. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-06 00:07 Message: Logged In: YES user_id=1727609 Originator: YES I removed the -t/-f options mostly because in the short time I spent trying to handle both -t/-f and unittest.main(), it seemed like the options were messing up unittest. I asked about removing the command line processing on this file at the PyCon sprint and the people there thought it would be okay to remove them. Their argument was that the files that match output to the output/ directory haven't been refactored in a long time, probably aren't maintained much (other than when they break), and probably aren't used much. Since the intended audience of this file is a developer, they wouldn't have a difficult time manually changing the global variables for this setting located at the top of the file. Having said that, if someone uses this functionality, I'll try adding it back in. Thoughts? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 19:16 Message: Logged In: YES user_id=1344176 Originator: NO Why did you get rid of the -t/-f options? ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-28 13:40 Message: Logged In: YES user_id=1727609 Originator: YES Lib/test/output/test_threadedtempfile should also be removed when this patch is applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670993&group_id=5470 From noreply at sourceforge.net Mon Mar 12 18:37:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 10:37:03 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 17:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 13:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 15:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 03:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Mon Mar 12 18:40:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 10:40:01 -0700 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 21:28 Message generated for change (Comment added) made by aminusfu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2007-03-12 17:40 Message: Logged In: YES user_id=967320 Originator: NO Sorry about that; I meant threading._Timer. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 10:10 Message: Logged In: YES user_id=51702 Originator: YES There is no threading._Thread class. ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2007-03-12 01:19 Message: Logged In: YES user_id=967320 Originator: NO Why not subclass threading._Thread and override just the run method? It would make more sense, then, to stick with the "cancel" method name instead of "end". ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 13:56 Message: Logged In: YES user_id=51702 Originator: YES "I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)" Actually, you get something very very weird. Try "t = Thread(); for x in range(10): t.start()". But it is the fault of the Thread class and above my head to fix anyhow. :) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 22:21 Message: Logged In: YES user_id=51702 Originator: YES Here is finished patch. It includes both documentation and a few unit tests. File Added: add-PeriodicTimer-2.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 22:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 19:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 07:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Mon Mar 12 19:12:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 11:12:08 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 18:25 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) >Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 10:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 17:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 16:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 13:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 13:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 17:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 18:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 18:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-07 19:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-07 19:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 10:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Mon Mar 12 19:26:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 11:26:50 -0700 Subject: [Patches] [ python-Patches-1168055 ] Add current dir when running try_run test program Message-ID: Patches item #1168055, was opened at 2005-03-22 02:49 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1168055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Collin Winter (collinwinter) Summary: Add current dir when running try_run test program Initial Comment: The try_run function in command/config.py is used to run a test program as part of configuring an extension module with "python setup.py config" before running "python setup.py build". When running the test program, the current directory is not included in the program name. So it attempts to run _configtest instead of ./_configtest. This works fine as long as the user has the current directory in the path. If not, the attempt to run _configtest fails. The patch adds the current directory in front of _configtest, so that the program runs even if the user does not have the current directory in the path. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2007-03-12 18:26 Message: Logged In: YES user_id=56214 Originator: NO Sorry, I've never used the "config" command nor seen any code that does, nor any documentation for it. I didn't even know it was actually usable. The OP's rationale for the change sounds reasonable to me, but a quick skim of the module doesn't convince me that it'll fix the problem correctly, vs. e.g. using os.path.abspath(). One thing that bugs me is why the program's being created in the current directory instead of the build/ directory in the first place. ISTM that there's a lot more that's broken here. OTOH, I don't suppose the patch would make things any worse. It would be nice if the original author of the module were around. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 17:00 Message: Logged In: YES user_id=1344176 Originator: NO Phillip, any thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1168055&group_id=5470 From noreply at sourceforge.net Mon Mar 12 19:43:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 11:43:20 -0700 Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test coverage improvement Message-ID: Patches item #1675424, was opened at 2007-03-06 22:14 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile tweaks and test coverage improvement Initial Comment: This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests: - appending to an existing zipfile - appending to an existing file that is not a zipfile - check that calling ZipFile.write without arcname specified produces the expected result - check that files within a Zip archive can have different compression options - check that trying to call write() on a readonly ZipFile object raises a RuntimeError - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension - check that bad modes passed to ZipFile constructor are caught - check that bad modes passed to ZipFile.open are caught - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError - check that bad compression methods passed to ZipFile.open are caught - check that a filename containing a null byte is properly terminated These other miscellaneous changes were made to test_zipfile.py: - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142) - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr. - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data. The following changes were made to zipfile.ZipFile: - A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation) - ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError) - checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant) There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-) If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know. I can add such documentation changes if necessary. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 14:43 Message: Logged In: YES user_id=1344176 Originator: NO I'm definitely in favor of the docs and test changes, and the extra error checking seems like a good idea. Both test_zipfile and test_zipfile64 pass for me with the patch applied. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-08 12:32 Message: Logged In: YES user_id=1115903 Originator: YES I've modified ZipFile.getinfo to raise a KeyError instead of a RuntimeError. It would appear that RuntimeError is what stuff in this module raises for IO problems, so I'm assuming this means we're stuck with it (even though I agree that IOError would seem more appropriate for trying to write to closed files). I documented some of the exceptions raised by various methods. However, I focused mainly on the items listed in my original post, so there's probably code that raise exceptions that still aren't properly documented. I also noticed that the existing docs list "error" as the exception that is raised for bad zip files. Since no such exception is raised, I included a change to the docs so that it says BadZipfile instead. I included a change to the NEWS file as well, since it was mentioned in py-dev discussion that such updates can be helpful. :-) File Added: zipfile_coverage2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:18 Message: Logged In: YES user_id=849994 Originator: NO I'd continue raising KeyError in the case the info wasn't found, but set a different message so that backwards compatibility doesn't break. In any case, it would be good to document it. Isn't raising IOError customary for writing to closed files? (If zipfile never raises IOError elsewhere, this is probably not applicable.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 From noreply at sourceforge.net Mon Mar 12 19:58:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 11:58:45 -0700 Subject: [Patches] [ python-Patches-1679204 ] Allow "datetime in date" Message-ID: Patches item #1679204, was opened at 2007-03-12 14:58 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=1679204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Allow "datetime in date" Initial Comment: As discussed in http://mail.python.org/pipermail/python-ideas/2007-March/000320.html, this patch adds a __contains__ method to datetime.date objects: datetime(2007, 3, 4, x, y, z) in date(2007, 3, 4) -> True datetime(2007, 3, 5, x, y, z) in date(2007, 3, 4) -> False Trying to see if a date contains anything other than a datetime results in a TypeError. Patch includes docs and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679204&group_id=5470 From noreply at sourceforge.net Mon Mar 12 22:11:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 14:11:48 -0700 Subject: [Patches] [ python-Patches-1676820 ] Add a PeriodicTimer to threading Message-ID: Patches item #1676820, was opened at 2007-03-08 22:28 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add a PeriodicTimer to threading Initial Comment: I have often wanted a timer in Python with the same functions as Javas Timer (http://java.sun.com/javase/6/docs/api/java/util/Timer.html). I want it repeating instead of being just a one-shot thing like Pythons Timer class. Here is a patch that adds such a class to the threading module. You then use it like this: import threading def hello(): print "Hi there!" t = threading.PeriodicTimer(5, hello) t.start() # "Hi there!" will be printed every five seconds. The use cases for this class is things like updating canvases, updating simulations and polling stuff. I can provide documentation and unit test patches if this class is deemed worthy. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 22:11 Message: Logged In: YES user_id=51702 Originator: YES Pretty pointless I think, the semantics for the two classes are totally different. The method is named end() because it has a very different meaning than the Timer class' cancel(). ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2007-03-12 18:40 Message: Logged In: YES user_id=967320 Originator: NO Sorry about that; I meant threading._Timer. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 11:10 Message: Logged In: YES user_id=51702 Originator: YES There is no threading._Thread class. ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2007-03-12 02:19 Message: Logged In: YES user_id=967320 Originator: NO Why not subclass threading._Thread and override just the run method? It would make more sense, then, to stick with the "cancel" method name instead of "end". ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 14:56 Message: Logged In: YES user_id=51702 Originator: YES "I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O)" Actually, you get something very very weird. Try "t = Thread(); for x in range(10): t.start()". But it is the fault of the Thread class and above my head to fix anyhow. :) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 23:21 Message: Logged In: YES user_id=51702 Originator: YES Here is finished patch. It includes both documentation and a few unit tests. File Added: add-PeriodicTimer-2.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 23:19 Message: Logged In: YES user_id=21627 Originator: NO I haven't actually tried the code AssertionError is fine (although I wonder what you get under -O) ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 21:20 Message: Logged In: YES user_id=51702 Originator: YES "Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results." I do not understand. Is AssertionError: thread already started a meaningful result? That is what Timer raises if you call start() on it multiple times. The intent of PeriodicTimer is to not be reusable because I have not seen any use case for that, but I guess I could make it so if you think so. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 20:40 Message: Logged In: YES user_id=51702 Originator: YES I choose the name to match the Timer class and the java.util.Timer class in the Java API. I'll rename it to "end" so that the caller gets the hint that further invocations of "start" is meaningless. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-09 08:15 Message: Logged In: YES user_id=21627 Originator: NO Looks fine to me. The only issue I see is naming: To stop a periodic timer, shouldn't the method name be "stop" rather than "cancel"? Also, as you can hold onto the timer, make sure invoking start/'end' multiple times in arbitrary order gives meaningful results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676820&group_id=5470 From noreply at sourceforge.net Mon Mar 12 22:36:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 14:36:59 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 16:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 17:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Mon Mar 12 22:46:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 14:46:49 -0700 Subject: [Patches] [ python-Patches-1679204 ] Allow "datetime in date" Message-ID: Patches item #1679204, was opened at 2007-03-12 18:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Allow "datetime in date" Initial Comment: As discussed in http://mail.python.org/pipermail/python-ideas/2007-March/000320.html, this patch adds a __contains__ method to datetime.date objects: datetime(2007, 3, 4, x, y, z) in date(2007, 3, 4) -> True datetime(2007, 3, 5, x, y, z) in date(2007, 3, 4) -> False Trying to see if a date contains anything other than a datetime results in a TypeError. Patch includes docs and tests. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 21:46 Message: Logged In: YES user_id=849994 Originator: NO Patch looks good, but the indentation of the /* nb_xyz */ comments seems to be messed up ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679204&group_id=5470 From noreply at sourceforge.net Mon Mar 12 23:45:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 15:45:45 -0700 Subject: [Patches] [ python-Patches-1679379 ] Documentation for fnmatch.translate() Message-ID: Patches item #1679379, was opened at 2007-03-12 23: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=1679379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for fnmatch.translate() Initial Comment: Simple LaTeX documentation for fnmatch.translate(). Plus, examples to the functions translate() and fnmatch(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679379&group_id=5470 From noreply at sourceforge.net Tue Mar 13 00:33:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 16:33:41 -0700 Subject: [Patches] [ python-Patches-1501979 ] syntax errors on continuation lines Message-ID: Patches item #1501979, was opened at 2006-06-07 04:49 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501979&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Miller (rcmiller) Assigned to: Nobody/Anonymous (nobody) Summary: syntax errors on continuation lines Initial Comment: This patch modifies syntax error location information to indicate when an error is detected on a statement continuation line, for example File "test.py", line 42 (continuing line 41) The intent is to be less confusing when an error reported on one line is actually the result of unbalanced brackets on a previous line. The change adds a new 'stmt_lineno' field to the SyntaxError exception, containing the line number on which the statement started. The patch is against r46701 and was developed and tested on Fedora 4 Linux. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-13 00:33 Message: Logged In: YES user_id=51702 Originator: NO Works nicely: >>> (3, ... 8, ... 4 +, File "", line 3 (continuing line 1) 4 +, ^ SyntaxError: invalid syntax The patch does not apply cleanly because of changes in traceback.py, but it is easy to fix. But IMHO, the special casing that checks for the presence of the extra stmt_lineno attribute is not nice at all. I think it would be better if stmt_lineno always was included and equal to lineno in the normal case. Then traceback.py would just check if stmt_lineno differs from lineno, and if so, append the extra '(continuing line %d)' information. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-06-08 15:05 Message: Logged In: YES user_id=849994 Note that you cannot give a "|" inside a tuple specification in PyArg_ParseTuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1501979&group_id=5470 From noreply at sourceforge.net Tue Mar 13 03:12:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 19:12:14 -0700 Subject: [Patches] [ python-Patches-1679204 ] Allow "datetime in date" Message-ID: Patches item #1679204, was opened at 2007-03-12 14:58 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679204&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Allow "datetime in date" Initial Comment: As discussed in http://mail.python.org/pipermail/python-ideas/2007-March/000320.html, this patch adds a __contains__ method to datetime.date objects: datetime(2007, 3, 4, x, y, z) in date(2007, 3, 4) -> True datetime(2007, 3, 5, x, y, z) in date(2007, 3, 4) -> False Trying to see if a date contains anything other than a datetime results in a TypeError. Patch includes docs and tests. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 22:12 Message: Logged In: YES user_id=1344176 Originator: YES Closing. Comparing dates and datetimes is just a bad idea. This was more a proof-of-concept than anything else. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 17:46 Message: Logged In: YES user_id=849994 Originator: NO Patch looks good, but the indentation of the /* nb_xyz */ comments seems to be messed up ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679204&group_id=5470 From noreply at sourceforge.net Tue Mar 13 03:14:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 12 Mar 2007 19:14:39 -0700 Subject: [Patches] [ python-Patches-1168055 ] Add current dir when running try_run test program Message-ID: Patches item #1168055, was opened at 2005-03-21 21:49 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1168055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Michiel de Hoon (mdehoon) Assigned to: Collin Winter (collinwinter) Summary: Add current dir when running try_run test program Initial Comment: The try_run function in command/config.py is used to run a test program as part of configuring an extension module with "python setup.py config" before running "python setup.py build". When running the test program, the current directory is not included in the program name. So it attempts to run _configtest instead of ./_configtest. This works fine as long as the user has the current directory in the path. If not, the attempt to run _configtest fails. The patch adds the current directory in front of _configtest, so that the program runs even if the user does not have the current directory in the path. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-12 22:14 Message: Logged In: YES user_id=1344176 Originator: NO Closing based on PJE's comment. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2007-03-12 14:26 Message: Logged In: YES user_id=56214 Originator: NO Sorry, I've never used the "config" command nor seen any code that does, nor any documentation for it. I didn't even know it was actually usable. The OP's rationale for the change sounds reasonable to me, but a quick skim of the module doesn't convince me that it'll fix the problem correctly, vs. e.g. using os.path.abspath(). One thing that bugs me is why the program's being created in the current directory instead of the build/ directory in the first place. ISTM that there's a lot more that's broken here. OTOH, I don't suppose the patch would make things any worse. It would be nice if the original author of the module were around. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 13:00 Message: Logged In: YES user_id=1344176 Originator: NO Phillip, any thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1168055&group_id=5470 From noreply at sourceforge.net Tue Mar 13 08:51:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 00:51:30 -0700 Subject: [Patches] [ python-Patches-1679379 ] Documentation for fnmatch.translate() Message-ID: Patches item #1679379, was opened at 2007-03-12 22:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679379&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for fnmatch.translate() Initial Comment: Simple LaTeX documentation for fnmatch.translate(). Plus, examples to the functions translate() and fnmatch(). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 07:51 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed in rev. 54323, 54324 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1679379&group_id=5470 From noreply at sourceforge.net Tue Mar 13 08:58:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 00:58:04 -0700 Subject: [Patches] [ python-Patches-1642844 ] comments to clarify complexobject.c Message-ID: Patches item #1642844, was opened at 2007-01-23 19:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642844&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Georg Brandl (gbrandl) Summary: comments to clarify complexobject.c Initial Comment: The constructor for a complex takes two values, representing the real and imaginary parts. Obviously, these should normally both be real numbers, but they don't have to be. The code to cater to complex arguments led to even Tim Peters asking WTF? http://mail.python.org/pipermail/python-dev/2007-January/070732.html This patch just adds comments. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 07:58 Message: Logged In: YES user_id=849994 Originator: NO Committed in rev. 54325. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-01-27 08:48 Message: Logged In: YES user_id=849994 Originator: NO Let Tim decide whether these are useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642844&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:01:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:01:52 -0700 Subject: [Patches] [ python-Patches-1654974 ] Binding annotations in tracebacks. Message-ID: Patches item #1654974, was opened at 2007-02-08 09:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654974&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nefarious CodeMonkey, Jr. (nejucomo) Assigned to: Nobody/Anonymous (nobody) Summary: Binding annotations in tracebacks. Initial Comment: The attached module provides a suitable replacement for sys.excepthook to handle uncaught exceptions. The output is the same, except after each source line shown, a list of relevant bindings is shown. Here's a quick example from the tail end of a test: File "./test-exprann.py", line 16, in f assert c == 12 # With bindings: # c = 42 AssertionError The bindings shown are the intersection of the code object "co_names" and the non-keyword name tokens in the parsed source line. The goal is to only show bindings relevant to the exception. I hope the utility of this is self-evident to any programmer. I tried testing it with crazy expressions containing nonfree bindings (such as lambda's and list comprehensions), so I think it behaves well in most circumstances. The performance might be bad (it parses each line in the backtrace), but I figure it is worth it for uncaught exceptions. Let me know if you find this tool useful. Thanks, Nejucomo ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:01 Message: Logged In: YES user_id=849994 Originator: NO Definitely. Adding a new stdlib module should go through a python-dev discussion. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-06 00:18 Message: Logged In: YES user_id=1344176 Originator: NO You should bring this up on the python-dev list (http://mail.python.org/mailman/listinfo/python-dev). ---------------------------------------------------------------------- Comment By: Nefarious CodeMonkey, Jr. (nejucomo) Date: 2007-02-21 21:26 Message: Logged In: YES user_id=44911 Originator: YES This feature has already been present in the stdlib for awhile, hidden in the cgitb module. Enable it like this: import cgitb cgitb.enable(format="text") I was not aware of this, assuming cgitb just formatted typical tracebacks into html. Perhaps a better design of traceback reporting in general is called for? ---------------------------------------------------------------------- Comment By: Nefarious CodeMonkey, Jr. (nejucomo) Date: 2007-02-12 19:00 Message: Logged In: YES user_id=44911 Originator: YES I've simplified and modularized the design of this tool. Included is a patch against the 2.6 svn head which adds a module to the stdlib called bindann (for "binding annotation"), and then modifies the traceback module to use it. It also includes a demo script which compares classic and annotated exception tracebacks. The interface to traceback is backwards compatible (it introduces optional arguments defaulting to pre-patch behavior). bindann is much simpler than the previous annex file, because it doesn't try parsing, only tokenizing the source line, to look for name references. Thus it succeeds where annex would fail (for example if the head of a for-loop causes an uncaught exception, the source line will only be the head which is not a complete/parsable expression). Here's the output of the demo: $ ./Demo/newfeatures/demo-bindann.py This demonstrates binding-annoted exception tracebacks. Consider the following function: def f(c): for char in c + " hello": print 'The string contains "%s".' % (char,) -With standard tracebacks, calling f(42) gives: Traceback (most recent call last): File "./Demo/newfeatures/demo-bindann.py", line 17, in main f(42) File "./Demo/newfeatures/demo-bindann.py", line 28, in f for char in c + " hello": TypeError: unsupported operand type(s) for +: 'int' and 'str' -And now with annotated exceptions: Traceback (most recent call last): File "./Demo/newfeatures/demo-bindann.py", line 33, in # With bindings: # main = # Source: main() File "./Demo/newfeatures/demo-bindann.py", line 24, in main # With bindings: # f = # Source: f(42) File "./Demo/newfeatures/demo-bindann.py", line 28, in f # With bindings: c = 42 # char = # Source: for char in c + " hello": TypeError: unsupported operand type(s) for +: 'int' and 'str' File Added: bindann-patch.1 ---------------------------------------------------------------------- Comment By: Nefarious CodeMonkey, Jr. (nejucomo) Date: 2007-02-08 09:50 Message: Logged In: YES user_id=44911 Originator: YES BTW, I only tested this on python 2.4. Because it examines the parse tree (very simply), it may not work if the AST format changes. The only parsing it does is search for all NAME tokens which are not keywords, so I assumed this was stable across releases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1654974&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:08:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:08:55 -0700 Subject: [Patches] [ python-Patches-1667860 ] urllib2 raises an UnboundLocalError if "auth-int" is the qop Message-ID: Patches item #1667860, was opened at 2007-02-24 15:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Atul Varma (varmaa) >Assigned to: Georg Brandl (gbrandl) Summary: urllib2 raises an UnboundLocalError if "auth-int" is the qop Initial Comment: If a proxy server is connected to that specifies the "auth-int" quality of protection (qop) code--or any qop code aside from "auth", actually--urllib2 raises an UnboundLocalError exception. While this patch doesn't implement auth-int, it does modify the behavior of urllib2 such that it raises a URLError with the reason "qop '%s' is not supported', where %s is the name of the qop code. Two unit tests that test urllib2's functionality with an in-process proxy can be found at: http://varmaa.googlepages.com/Urllib2ProxyTests.py I will try to attach this file to this patch ticket if I can. I am also interested in integrating this unit testing suite with the Python standard lib unit tests, and am willing to work with you if this is desirable. One of the unit tests in this suite succeeds with the standard version of urllib2.py, but the other fails unless this patch is applied. This patch (and the unit test suite) applies to Python 2.4 and 2.5. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:08 Message: Logged In: YES user_id=849994 Originator: NO The new test file looks good, so if you complete the patch I'll apply it. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:42 Message: Logged In: YES user_id=863202 Originator: YES Thanks for the feedback, John--I've applied your suggestions to the testing suite (including renaming the file name) and the patch file. The only thing I haven't done yet is add tests for failure cases, but I wanted to submit the "refactored" version of the test suite before doing that so I know I'm on the right track. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:38 Message: Logged In: YES user_id=863202 Originator: YES File Added: test_urllib2_localnet.py ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-26 01:33 Message: Logged In: YES user_id=863202 Originator: YES File Added: urllib2_patch.diff ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 17:37 Message: Logged In: YES user_id=261020 Originator: NO This looks useful. It would be nice to test failure cases too (e.g. wrong password, .add_password() not called, ...). I think if this goes into a new file (which might be reasonable), it should be named something like test_urllib2_localnet.py , to allow for adding more loopback tests, which will not always involve proxy handling. I suppose it should NOT depend on the network resource flag (Lib/test/regrtest.py -u network) since it's only localhost. Style (see PEP 8): Don't put whitespace inside brackets -- e.g. bad: fn( arg ) good: fn(arg) Use this_kind_of_name or thiskind if short, not thisKind. Imports and classes etc. don't need comments to label them as such. Probably is useful to label the BaseHTTPServer code though (maybe '# Local proxy test infrastructure'). See e.g. end of Lib/test/test_urllib2net.py for appropriate stdlib test boilerplate. Your patch has inconsistent line endings, BTW. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-24 15:20 Message: Logged In: YES user_id=863202 Originator: YES File Added: Urllib2ProxyTests.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667860&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:15:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:15:06 -0700 Subject: [Patches] [ python-Patches-1668100 ] urllib2.urlopen() raises OSError instead of URLError Message-ID: Patches item #1668100, was opened at 2007-02-24 23:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.urlopen() raises OSError instead of URLError Initial Comment: See bug 1591774. The base problem is that when passing a file:// url into urllib2.urlopen() for a file that doesn't exist, the os.stat() call fails with an OSError exception which is not caught. The documentation for urllib2 states that urlopen() raises a URLError upon error. This bug can also be triggered when fetching a http:// url. A misconfigured webserver can cause urllib2.urlopen to use the FileHandler (see bug report). This patch catches OSError in the FileHandler class and raises it as a URLError. Unit test included. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:15 Message: Logged In: YES user_id=849994 Originator: NO Committed in rev. 54326. Not backporting since it raises a different exception now. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 06:23 Message: Logged In: YES user_id=1727609 Originator: YES Added patch v2 which is a patch against trunk, and adds in the tests that were commented out (they previously failed). ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-12 06:22 Message: Logged In: YES user_id=1727609 Originator: YES File Added: bug_1591774_failing_test_and_bugfix_v2.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 18:18 Message: Logged In: YES user_id=1344176 Originator: NO I think it should be fixed to raise URLError. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-02-26 04:12 Message: Logged In: YES user_id=1727609 Originator: YES Sorry, I looked at that commented out section and didn't immediately see what it was for, so ignored it. I'm not sure what the correct behavior would be in this case. Getting a OSError from a http:// url is unsettling. I guess that if I were using the library, I would only want to have to catch one type of exception. Having to catch both URLError and OSError is inconvenient. If I were looking for a file on disk I would use file(), so the only time someone probably uses the file:// url syntax is when the end user is entering the URL. The end user wouldn't distinguish between the two exception types in this case. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 17:01 Message: Logged In: YES user_id=261020 Originator: NO I recall that when I wrote the urllib2 tests there were a fair few cases similar to this -- indeed, this particular one is already marked in the tests with an "XXXX" in test_file(). What do other people think about these -- should they be fixed, or the docs changed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668100&group_id=5470 From hypertextual at phonereader.com Tue Mar 13 08:45:55 2007 From: hypertextual at phonereader.com (hypertextual at phonereader.com) Date: Tue, 13 Mar 2007 08:45:55 +0100 Subject: [Patches] Rhetorics of Hypertext Message-ID: <1daa201c76543$a1ad1e80$17e3c13e@wpc1193> Rhetorics of Hypertext March 13th 2007 POSTS of the week : Imagination radicale vs imaginaire social (imagination repr?sentation image) http://phonereader.com/m/R?mail20en-46705-470-35 : Sweeping change (changing transformation mobile) http://phonereader.com/m/R?mail20en-46705-471-35 : Penser l'Hypertexte ? l'?ge de l'Internet mobile (pens?e philosophie th?orie) http://phonereader.com/m/R?mail20en-46705-472-35 : Shifting boundaries (limit domain linking) http://phonereader.com/m/R?mail20en-46705-473-35 : Modalit? et virtualit? (possible r?alit? virtualit?) http://phonereader.com/m/R?mail20en-46705-474-35 : Books and Hypertexts (hypertext writing book) http://phonereader.com/m/R?mail20en-46705-475-35 : Elargissement de notre perception (ph?nom?nologie Benjamin art) http://phonereader.com/m/R?mail20en-46705-476-35 : Mouth that bites (fragment post text) http://phonereader.com/m/R?mail20en-46705-477-35 : L'objet textu? et son axiomatique (algorithme calcul parcours) http://phonereader.com/m/R?mail20en-46705-478-35 : Citability and hypertext (word sentence source) http://phonereader.com/m/R?mail20en-46705-479-35 : Possible et objectivit? (r?alit? virtualit? mod?le) http://phonereader.com/m/R?mail20en-46705-480-35 : Reading practises (writing reading text) http://phonereader.com/m/R?mail20en-46705-481-35 : Primary sources (linking thread origin) http://phonereader.com/m/R?mail20en-46705-482-35 : Structure du flux de la conscience (ph?nom?nologie dur?e temps) http://phonereader.com/m/R?mail20en-46705-483-35 Jean-Philippe Pastor : Politique : http://phonereader.com/m/R?mail20en-46705-351-35 ? Moonstone Order by fax : http://phonereader.com/m/R?mail20en-46705-74-35 Critics of the book on Fabula : http://phonereader.com/m/R?mail20en-46705-75-35 E-Books Principe et succession ? http://phonereader.com/m/R?mail20en-46705-71-35 Fuse of time ? http://phonereader.com/m/R?mail20en-46705-72-35 Anticipations ? http://phonereader.com/m/R?mail20en-46705-57-35 Le Possible et l'inattendu ? http://phonereader.com/m/R?mail20en-46705-58-35 Monde des possibles ? http://phonereader.com/m/R?mail20en-46705-59-35 Reprises ? http://phonereader.com/m/R?mail20en-46705-60-35 Jacques Derrida ? http://phonereader.com/m/R?mail20en-46705-61-35 Symbolique de la mise en page ? http://phonereader.com/m/R?mail20en-46705-62-35 Exclusive reading ? http://phonereader.com/m/R?mail20en-46705-63-35 Huit Hypoth?ses ? http://phonereader.com/m/R?mail20en-46705-64-35 Mythe et temporalit? ? http://phonereader.com/m/R?mail20en-46705-65-35 Individualisme ? http://phonereader.com/m/R?mail20en-46705-66-35 Derrida, la contrefacture, l'absence. ? http://phonereader.com/m/R?mail20en-46705-67-35 Machines textuelles ? http://phonereader.com/m/R?mail20en-46705-68-35 L'inconcevable ? http://phonereader.com/m/R?mail20en-46705-69-35 Contre-coup ? http://phonereader.com/m/R?mail20en-46705-70-35 plus ... / more ... http://phonereader.com/m/R?mail20en-46705-78-35 French Metablog http://phonereader.com/m/R?mail20en-46705-76-35 MetaBlog en anglais http://phonereader.com/m/R?mail20en-46705-77-35 French Theory http://phonereader.com/m/R?mail20en-46705-78-35 Metabole mobile http://phonereader.com/m/R?mail20en-46705-79-35 Enregistrez-vous sur Hypertextual http://phonereader.com/m/R?mail20en-46705-80-35 Tous les livres sur : http://phonereader.com/m/R?mail20en-46705-81-35 Google Print ou sur amazon.com avec Castoriadis ou la création des possibles http://phonereader.com/m/R?mail20en-46705-82-35 Hypertexte principal http://phonereader.com/m/R?mail20en-46705-83-35 Dialogues et entretiens sur metabole.net http://phonereader.com/m/R?mail20en-46705-84-35 E-books avec PHONEREADER 3G Mobility http://phonereader.com/m/R?mail20en-46705-85-35 Archives en fran?ais http://phonereader.com/m/R?mail20en-46705-86-35 Podcast of the day http://phonereader.com/m/R?mail20en-46705-327-35 References actualit? , http://phonereader.com/m/R?mail20en-46705-39-35 ?cran , http://phonereader.com/m/R?mail20en-46705-40-35 inattendu , http://phonereader.com/m/R?mail20en-46705-41-35 litt?rature , http://phonereader.com/m/R?mail20en-46705-42-35 livres , http://phonereader.com/m/R?mail20en-46705-43-35 m?tabole , http://phonereader.com/m/R?mail20en-46705-44-35 musique , http://phonereader.com/m/R?mail20en-46705-45-35 narration , http://phonereader.com/m/R?mail20en-46705-46-35 politique , http://phonereader.com/m/R?mail20en-46705-47-35 possible , http://phonereader.com/m/R?mail20en-46705-48-35 religion , http://phonereader.com/m/R?mail20en-46705-49-35 science , http://phonereader.com/m/R?mail20en-46705-50-35 temps , http://phonereader.com/m/R?mail20en-46705-51-35 texte , http://phonereader.com/m/R?mail20en-46705-52-35 voir vid?os , http://phonereader.com/m/R?mail20en-46705-53-35 voyages , http://phonereader.com/m/R?mail20en-46705-54-35 weblogs , http://phonereader.com/m/R?mail20en-46705-55-35 web/Tech . http://phonereader.com/m/R?mail20en-46705-56-35 March 13th 2007 [...] Within this newsletter we look specifically at the changing definition of a book. A book is no longer a tangible thing; a book is what a book does. It is an information architecture. We examine the various manifestations of electronic book readers and imminent technologies, such electronic ink, including a case study on the use of ebook reading devices by a lending library, and speculate about other uses of such devices We see the convergence of print and etext - manifestations of the same thing - electronically stored text, with the difference demonstrated only in their final rendering. We look at changes in print technologies and the shift in mindset necessary to accommodate emergent forms of digital text - as information services within a product-service system, the changing shape of digital design and changes in printing technologies from letterpress to the rise of digital printing... This newsletter was written by Jean-Philippe PASTOR ** M?tabole ** http://phonereader.com/m/R?mail20en-46705-19-35 To not receive any mail, clic here : http://phonereader.com/m/R?mail20en-46705-0-35 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070313/70a920b5/attachment-0001.htm From noreply at sourceforge.net Tue Mar 13 09:34:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:34:32 -0700 Subject: [Patches] [ python-Patches-1670765 ] email.Generator: no header wrapping for multipart/signed Message-ID: Patches item #1670765, was opened at 2007-02-28 12:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670765&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin von Gagern (gagern) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generator: no header wrapping for multipart/signed Initial Comment: The body of a multipart/signed message has to remain unmodified for the signature to stay intact. Rewrapping headers of nested MIME parts breaks signatures. So I disabled header rewrapping for multipart/signed, by adding a new handler to the email.Generator class. There still remains an issue about leading spaces in header values breaking signatures. The supplied patch is against the latest subversion sources, r54016. Related issues: Python bug #968430 http://tinyurl.com/2973or Mailman bug #815297 http://tinyurl.com/2a8dta ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:34 Message: Logged In: YES user_id=849994 Originator: NO Assigning to Barry. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 18:01 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! Could you work up some tests for this, too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1670765&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:39:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:39:43 -0700 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:39 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good to me; documentation updates and new tests will be needed though. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 21:25 Message: Logged In: YES user_id=341410 I've just attached an updated version of the patch to handle expandusers (without recursive environment variable expansion), as well as a variant of http://python.org/sf/1574252 to handle %VAR% style expansions on Windows. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 10:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 10:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-15 01:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 20:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\\Documents and Settings\\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\\bob') '~billy\\bob' >>> ntpath.expanduser('~\\bob') 'C:\\Documents and Settings\\jcarlson\\bob' >>> ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') '~billy\\%TESTING%\\%TESTING1%\\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\\billy' >>> ntpath_patched.expanduser('~billy\\bob') 'C:Documents and Settings\\billy\\bob' >>> ntpath_patched.expanduser('~\\bob') 'C:Documents and Settings\\jcarlson\\bob' >>> ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') 'C:Documents and Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:40:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:40:20 -0700 Subject: [Patches] [ python-Patches-1574252 ] Add %var% support to ntpath.expandvars Message-ID: Patches item #1574252, was opened at 2006-10-10 04:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Chip Norkus (doubleyewdee) Assigned to: Nobody/Anonymous (nobody) Summary: Add %var% support to ntpath.expandvars Initial Comment: NT variables are passed around as %var% instead of $var or ${var}. Providing support for this gives a seamless user experience for NT users using Python. E.g. os.path.expandvars('%TEMP%') now does what is expected on NT. I updated the docstring, could not find any tests or documentation references in svn for this portion of code. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:40 Message: Logged In: YES user_id=849994 Originator: NO Closing in favor of #957650. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 21:28 Message: Logged In: YES user_id=341410 I've added a new patch to http://python.org/sf/957650 that adds both the expanduser and expandvars case. The expandvars case is slightly different from what the OP submitted, if only in that it won't mask ValueErrors that don't come from the str.index() call. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 17:49 Message: Logged In: YES user_id=341410 I believe that there are two changes that are desireable; the functionality offered in this patch (expansion of %VAR% environment variables), and ~user\subpath expansion. Recursive re-application of variable expansion shouldn't occur. I can merge the two patches that adds the functionality to ntpath.expanduser and ntpath.expandvars . ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 14:36 Message: Logged In: YES user_id=21627 josiahcarlson, can you propose a strategy to resolve this all? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-16 22:47 Message: Logged In: YES user_id=341410 See also: http://python.org/sf/796219 and http://python.org/sf/957650 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1574252&group_id=5470 From noreply at sourceforge.net Tue Mar 13 09:41:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 01:41:08 -0700 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:41 Message: Logged In: YES user_id=849994 Originator: NO This fixes #796219. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:39 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good to me; documentation updates and new tests will be needed though. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 21:25 Message: Logged In: YES user_id=341410 I've just attached an updated version of the patch to handle expandusers (without recursive environment variable expansion), as well as a variant of http://python.org/sf/1574252 to handle %VAR% style expansions on Windows. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 10:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 10:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-15 01:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 20:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\\Documents and Settings\\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\\bob') '~billy\\bob' >>> ntpath.expanduser('~\\bob') 'C:\\Documents and Settings\\jcarlson\\bob' >>> ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') '~billy\\%TESTING%\\%TESTING1%\\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\\billy' >>> ntpath_patched.expanduser('~billy\\bob') 'C:Documents and Settings\\billy\\bob' >>> ntpath_patched.expanduser('~\\bob') 'C:Documents and Settings\\jcarlson\\bob' >>> ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') 'C:Documents and Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:29:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:29:52 -0700 Subject: [Patches] [ python-Patches-701743 ] Reloading pseudo modules Message-ID: Patches item #701743, was opened at 2003-03-11 19:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=701743&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Reloading pseudo modules Initial Comment: Python allows to put something that is not a module in sys.modules. Unfortunately reload() does not work wth such a pseudo module ("TypeError: reload() argument must be module" is raised). This patch changes Python/import.c::PyImport_ReloadModule() so that it works with anything that has a __name__ attribute that can be found in sys.modules.keys(). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-13 10:29 Message: Logged In: YES user_id=21627 Originator: NO I have now updated the patch to the current trunk, however, I fail to see how it fixes the bug. See the included test case: it reports an ImportError on the reload, saying that there is no module named 'fake'. File Added: diff3.txt ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-03-31 21:38 Message: Logged In: YES user_id=89016 A use case can be found at http://www.livinglogic.de/viewcvs/index.cgi/LivingLogic/xist/_xist/xsc.py?rev=2.235 (Look for the classmethod makemod() in the class Namespace). This puts a class object into sys.modules instead of the module that defines this class. This makes it possible to derive from "modules". Of course the patch does not fully fix the problem, because reload() does not repopulate the class object. Unfortunately that's impossible to fix with Python code, as it's impossible for Python code to distinguish the first import from subsequent ones. If this was possible (and Python code had access to the old "module"), a real reload could be coded in pure Python for this specific case. But with the patch at least it's possible to use the return value of reload() afterwards to use the new "module". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 18:34 Message: Logged In: YES user_id=21627 The patch looks fine now as far as it goes. I'm unsure what the use case is, though: What object do you have in sys.modules for which reload() would be meaningful? Can you attach an example where reloading fails now but succeeds with your patch applied? As for reload modifying the module object: It needs to, or else all clients would have to run reload; this would include things like function default arguments. I guess it returns a result for historical reasons. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-03-17 15:25 Message: Logged In: YES user_id=89016 PyImport_ReloadModule() is only called by the implementation of the reload builtin, so it seems that m==NULL can only happen with broken extension modules. I've updated the patch accordingly (raising a SystemError) and changed the error case for a missing __name__ attribute to raise a TypeError when an AttributeError is detected. Unfortunately this might mask exceptions (e.g. when __name__ is implemented as a property.) Another problem is that reload() seems to repopulate the existing module object when reloading real modules. Example: Write a simple foo.py which contains "x = 1" and then: >>> import foo >>> foo.x 1 [ Now open your editor and change foo.py to "x = 2" ] >>> foo2 = reload(foo) >>> foo.x 2 >>> foo2.x 2 >>> print id(foo), id(foo2) 1077466884 1077466884 >>> Of course this can't work with pseudo modules. I wonder why reload() has a return value at all, as it always modifies its parameter for real modules. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-15 14:51 Message: Logged In: YES user_id=21627 I think the exceptions need to be reworked: "must be a module" now only occurs if m is NULL. Under what circumstances could that happen? Failure to provide __name__ is passed through; shouldn't this get diagnosed in a better way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=701743&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:32:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:32:27 -0700 Subject: [Patches] [ python-Patches-1635454 ] CSV DictWriter Errors Message-ID: Patches item #1635454, was opened at 2007-01-15 00:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1635454&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Nobody/Anonymous (nobody) Summary: CSV DictWriter Errors Initial Comment: In reponse to feature request 1634717. The DictWriter, with this patch, should return a list of all offending extraneous field names, instead of simply raising a failure. I could see a use case for this in error reporting. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 09:32 Message: Logged In: YES user_id=849994 Originator: NO Committed a similar patch in rev. 54327. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1635454&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:36:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:36:29 -0700 Subject: [Patches] [ python-Patches-1559413 ] test_cmd_line fails on Windows Message-ID: Patches item #1559413, was opened at 2006-09-15 15:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559413&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: test_cmd_line fails on Windows Initial Comment: test_cmd_line fails in 2.5c2 if Python is installed into a directory with spaces in its name. This is a shallow problem, and can be fixe with attached patch. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 09:36 Message: Logged In: YES user_id=849994 Originator: NO Wouldn't the quotes work for non-Windows platforms too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559413&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:39:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:39:08 -0700 Subject: [Patches] [ python-Patches-1559298 ] test_popen fails on Windows if installed to "Program Files" Message-ID: Patches item #1559298, was opened at 2006-09-15 12:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: test_popen fails on Windows if installed to "Program Files" Initial Comment: test_popen fails in 2.5c2. The reason is that popen invokes cmd.exe /c "c:\program files\python25\python.exe" -c "import sys;print sys.argv" cmd.exe does not support that syntax, and gives an error (which silently disappears); the pipe read then returns an empty string. This problem exists atleast since Python 2.3. To fix this, cmd.exe needs to be invoked as cmd.exe /c "c:\program files\python25\python.exe" -c "import sys;print sys.argv" The attached patch fixes this by always wrapping the command line with an addition pair of quotes. It's not clear to me whether this can go into 2.5.1: an application may already work around this problem by passing extra quotes to popen, which would then break if popen adds even more quotes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO I don't see a difference between your two command lines here... did you mean to add additional quotes in the second example? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559298&group_id=5470 From noreply at sourceforge.net Tue Mar 13 10:41:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 02:41:50 -0700 Subject: [Patches] [ python-Patches-1555098 ] Performance enhancements. Message-ID: Patches item #1555098, was opened at 2006-09-09 00:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Indy (indy90) Assigned to: Raymond Hettinger (rhettinger) Summary: Performance enhancements. Initial Comment: Implemeted some performance enhancements. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 09:41 Message: Logged In: YES user_id=849994 Originator: NO Committed to trunk as rev. 54328. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-09-09 15:48 Message: Logged In: YES user_id=80475 Attached is a cleaned-up version of the patch that focuses on using str.join instead of successive string addition. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-09 02:11 Message: Logged In: YES user_id=33168 Please create a context or unified diff against svn HEAD. Although I doubt robotparser changed between now and then, it is not easy to apply if there are other changes. Thanks. Also it would be good to describe what the performance enhancements actually are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555098&group_id=5470 From noreply at sourceforge.net Tue Mar 13 11:07:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 03:07:36 -0700 Subject: [Patches] [ python-Patches-1542681 ] Tweak pydoc to speak about with and CONTEXTMANAGERS Message-ID: Patches item #1542681, was opened at 2006-08-18 14:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542681&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: Tweak pydoc to speak about with and CONTEXTMANAGERS Initial Comment: Just a first go to having pydoc speaking about 2.5 features. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 10:07 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, applied as rev. 54329, 54330 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1542681&group_id=5470 From noreply at sourceforge.net Tue Mar 13 11:20:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 03:20:01 -0700 Subject: [Patches] [ python-Patches-1569798 ] Fix building the source within exec_prefix Message-ID: Patches item #1569798, was opened at 2006-10-03 08:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569798&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: Fix building the source within exec_prefix Initial Comment: [forwarded from http://bugs.debian.org/385336] when built under a subdirectory of exec_prefix, the build fails building the extensions. bug submitter writes: OK, after a debugging session, I found out why. It seems to be an upstream bug in distutils. See python2.5-2.5~c1/Lib/distutils/command/build_ext.py line 188+: if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') This code is executed only in the shared build. The if clause is here to determine whether we're running a correctly installed python or whether we're running python from its source tree. In our case (since we're building python itself atm), the condition *must* evaluate to false. However, this exact check looks very clumsy. On my build system, sys.executable == '/usr/src/debian/build/python2.5-2.5~c1/build-shared/python', sys.exec_prefix == '/usr', i.e. the condition is true and distutils thinks it's running on an already installed python distribution. The reason is that I'm building below the 'install prefix' directory (in /usr/src/...). In contrast, on the Debian buildd machines, this is performed in /build/buildd/.... which does not trigger the distutils bug. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 10:20 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, adapted to current trunk and applied in rev. 54331, 54332 (2.5). ---------------------------------------------------------------------- Comment By: Benjamin Thyreau (benji2) Date: 2006-11-09 13:27 Message: Logged In: YES user_id=140916 Hi, I seem to have a very related problem too, since i also traced it back to Lib/distutils/command/build_ext.py line 188. Summary, when Python is installed with both --enable-shared and --prefix, distutils generated compilations lines (rightly) add -lpython2.5 but does NOT add the corresponding -L (which is, PREFIX/lib by default ). I had to manually add self.library_dirs.append(os.path.join(sys.prefix, "lib")) on line 190 to quick fix that. Also, the abovementioned test "string.find(sys.executable, sys.exec_prefix)!=-1" doesn't have the intended effect on my system either, because of symlinks (oddly enough it works when running from IPython, maybe it resolves paths differently) Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1569798&group_id=5470 From noreply at sourceforge.net Tue Mar 13 11:24:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 03:24:56 -0700 Subject: [Patches] [ python-Patches-1449244 ] email.message.py charset can be unicode instance Message-ID: Patches item #1449244, was opened at 2006-03-14 00:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 7 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.message.py charset can be unicode instance Initial Comment: *_charset in Charset become unicode instance in email-4.0a. message.py should add this for type test. --- email-4.0a2/email/message.py Mon Mar 6 04:58:33 2006 +++ email/message.py Mon Mar 6 14:59:04 2006 @@ -238,7 +238,7 @@ self.del_param('charset') self._charset = None return - if isinstance(charset, str): + if isinstance(charset, str) or isinstance(charset, unicode): charset = email.charset.Charset(charset) if not isinstance(charset, email.charset.Charset): raise TypeError(charset) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-13 11:24 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54333 and r54334. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-03-06 21:12 Message: Logged In: YES user_id=67709 Originator: YES Here is a revised patch with a test case. I've found another unicode charset bug in the code and it was fixed also. File Added: email.1449244.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 14:17 Message: Logged In: YES user_id=21627 Originator: NO Can you please include a test case for this, as a patch to the current test suite, using the unittest framework? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1449244&group_id=5470 From noreply at sourceforge.net Tue Mar 13 12:58:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 04:58:38 -0700 Subject: [Patches] [ python-Patches-1443875 ] email/charset.py convert() patch Message-ID: Patches item #1443875, was opened at 2006-03-06 04:41 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None >Priority: 1 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/charset.py convert() patch Initial Comment: email/charset.py has convert() function to incorporate using different charset for input and output for a language like Japanese. Because the email user agent in Japan frequently use characters outside the range of legitimate JIS charset, these messages are shunted in mailman delivery. Here is a patch to handle this case by replacing the characters by '?' using the 'errors' parameter in unicode/encode functions. This patch includes the unicode string conversion patch in #1368247. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-03-13 11:58 Message: Logged In: YES user_id=67709 Originator: YES Ok, I worked a little on the code to propagate the choice of 'strict' or 'replace' but there are many we should fix. And we should fix the application, mailman, also. The problem is only related to Japanese and we'd rather find workarounds elsewhere. I put the priority of this patch lowest. Thanks for your comments. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 13:15 Message: Logged In: YES user_id=21627 Originator: NO I'm -1 on this patch as-is. It changes the default error handling behavior from 'strict' to 'replace', for this method. This is a choice that the caller of these methods should make, so I think the default value for the error handling should be 'strict'. If then it is meaningful in mailman to set this to 'replace', this is mailman's choice. Python should never, on its own, create moji-bake. If you revise this patch, please provide the test case as a patch to Lib/email/test somehow (probably patching both test_email and test_email_renamed). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2006-03-13 23:35 Message: Logged In: YES user_id=67709 Thanks! Here is an example program which fails on 4.0a without the patch. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-03-12 13:09 Message: Logged In: YES user_id=12800 Do you have a test case for this? #1368247 includes one just for the encoding of unicode strings, but not for the error argument. If you can include a simple test case, then I'll add this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1443875&group_id=5470 From noreply at sourceforge.net Tue Mar 13 17:11:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 09:11:25 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 18:32 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 13:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 18:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Tue Mar 13 17:16:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 09:16:14 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 12:48 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 17:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 14:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 18:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 19:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 14:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Tue Mar 13 17:44:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 09:44:40 -0700 Subject: [Patches] [ python-Patches-1680015 ] __slots__ tuple modified inplace if it contains unicode name Message-ID: Patches item #1680015, was opened at 2007-03-13 17:44 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=1680015&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: __slots__ tuple modified inplace if it contains unicode name Initial Comment: Function _unicode_to_string() in typeobject.c tries to copy the original tuple by asking for a complete slice of the original tuple. This case is special cased in tupleslice() to only incref the original tuple. As a consequence, the user's tuple could be modified (see the test). There are also some reference leaks if an unicode name can't be encoded with the default codec. The patch fixes this and adds tests for both cases. I also moved a comment about possible leaks to the appropriate place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 From noreply at sourceforge.net Tue Mar 13 18:12:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 10:12:33 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 11:48 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: TH (therve) Date: 2007-03-13 17:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 16:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 13:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 17:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 18:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 18:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 13:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 00:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Tue Mar 13 18:44:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 10:44:11 -0700 Subject: [Patches] [ python-Patches-1635639 ] ConfigParser does not quote % Message-ID: Patches item #1635639, was opened at 2007-01-15 07:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1635639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Mark Roberts (mark-roberts) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser does not quote % Initial Comment: This is covered by bug 1603688 (https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603688&group_id=5470) I implemented 2 versions of this patch. One version raises ValueError when an invalid interpolation syntax is encountered (such as foo%, foo%bar, and %foo, but not %%foo and %(dir)foo). The other version simply replaces appropriate %s with %%s. Initially, I believed ValueError was the appropriate way to go with this. However, when I thought about how I use ConfigParser, I realized that it would be far nicer if it simply worked. I'm +0.5 to ValueError, and +1 to munging the values. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 17:44 Message: Logged In: YES user_id=849994 Originator: NO Explicit is better than implicit. I committed a similar patch that raises ValueError, and your new test cases in rev. 54339. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 19:44 Message: Logged In: YES user_id=11375 Originator: NO Turning into a patch. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-16 02:17 Message: Logged In: YES user_id=1591633 Originator: YES For the record, this was supposed to be a patch. I don't know if the admins have any way of moving it to that category. I guess that explained the funky categories and groups. Sorry for the inconvenience. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2007-01-15 07:44 Message: Logged In: YES user_id=1591633 Originator: YES File Added: bug_1603688_cfgparser_munges.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1635639&group_id=5470 From noreply at sourceforge.net Tue Mar 13 18:55:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 10:55:07 -0700 Subject: [Patches] [ python-Patches-701743 ] Reloading pseudo modules Message-ID: Patches item #701743, was opened at 2003-03-11 19:59 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=701743&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Reloading pseudo modules Initial Comment: Python allows to put something that is not a module in sys.modules. Unfortunately reload() does not work wth such a pseudo module ("TypeError: reload() argument must be module" is raised). This patch changes Python/import.c::PyImport_ReloadModule() so that it works with anything that has a __name__ attribute that can be found in sys.modules.keys(). ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-03-13 18:55 Message: Logged In: YES user_id=89016 Originator: YES This patch only works if there's a real module behind the fake one, i.e. if the imported module replaces itself if sys.modules. To test, put the following into fake.py: --- class FakeMod: def __init__(self, n): self.__name__ = n def foo(self): return 42 import sys sys.modules[__name__] = FakeMod(__name__) --- On the commandline do: >>> import fake >>> import sys >>> fake >>> fake.foo() 42 [Now edit fake.py and change 42 to 43] >>> fake2 = reload(fake) >>> fake2 >>> fake.foo() 42 >>> fake2.foo() 43 >>> sys.modules['fake'].foo() However I'm no longer sure that the patch in this form is all that useful. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-13 10:29 Message: Logged In: YES user_id=21627 Originator: NO I have now updated the patch to the current trunk, however, I fail to see how it fixes the bug. See the included test case: it reports an ImportError on the reload, saying that there is no module named 'fake'. File Added: diff3.txt ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-03-31 21:38 Message: Logged In: YES user_id=89016 A use case can be found at http://www.livinglogic.de/viewcvs/index.cgi/LivingLogic/xist/_xist/xsc.py?rev=2.235 (Look for the classmethod makemod() in the class Namespace). This puts a class object into sys.modules instead of the module that defines this class. This makes it possible to derive from "modules". Of course the patch does not fully fix the problem, because reload() does not repopulate the class object. Unfortunately that's impossible to fix with Python code, as it's impossible for Python code to distinguish the first import from subsequent ones. If this was possible (and Python code had access to the old "module"), a real reload could be coded in pure Python for this specific case. But with the patch at least it's possible to use the return value of reload() afterwards to use the new "module". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 18:34 Message: Logged In: YES user_id=21627 The patch looks fine now as far as it goes. I'm unsure what the use case is, though: What object do you have in sys.modules for which reload() would be meaningful? Can you attach an example where reloading fails now but succeeds with your patch applied? As for reload modifying the module object: It needs to, or else all clients would have to run reload; this would include things like function default arguments. I guess it returns a result for historical reasons. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-03-17 15:25 Message: Logged In: YES user_id=89016 PyImport_ReloadModule() is only called by the implementation of the reload builtin, so it seems that m==NULL can only happen with broken extension modules. I've updated the patch accordingly (raising a SystemError) and changed the error case for a missing __name__ attribute to raise a TypeError when an AttributeError is detected. Unfortunately this might mask exceptions (e.g. when __name__ is implemented as a property.) Another problem is that reload() seems to repopulate the existing module object when reloading real modules. Example: Write a simple foo.py which contains "x = 1" and then: >>> import foo >>> foo.x 1 [ Now open your editor and change foo.py to "x = 2" ] >>> foo2 = reload(foo) >>> foo.x 2 >>> foo2.x 2 >>> print id(foo), id(foo2) 1077466884 1077466884 >>> Of course this can't work with pseudo modules. I wonder why reload() has a return value at all, as it always modifies its parameter for real modules. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-15 14:51 Message: Logged In: YES user_id=21627 I think the exceptions need to be reworked: "must be a module" now only occurs if m is NULL. Under what circumstances could that happen? Failure to provide __name__ is passed through; shouldn't this get diagnosed in a better way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=701743&group_id=5470 From noreply at sourceforge.net Tue Mar 13 18:57:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 10:57:13 -0700 Subject: [Patches] [ python-Patches-1680015 ] __slots__ tuple modified inplace if it contains unicode name Message-ID: Patches item #1680015, was opened at 2007-03-13 16:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: __slots__ tuple modified inplace if it contains unicode name Initial Comment: Function _unicode_to_string() in typeobject.c tries to copy the original tuple by asking for a complete slice of the original tuple. This case is special cased in tupleslice() to only incref the original tuple. As a consequence, the user's tuple could be modified (see the test). There are also some reference leaks if an unicode name can't be encoded with the default codec. The patch fixes this and adds tests for both cases. I also moved a comment about possible leaks to the appropriate place. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 17:57 Message: Logged In: YES user_id=849994 Originator: NO Perhaps moving the "leak" comment into the if block isn't such a good idea. Ah, and while you're at it, you could improve the variable names ("o" and "o1" is not very useful :) Otherwise the patch looks fine, I'd say you can apply it then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 From noreply at sourceforge.net Tue Mar 13 19:16:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 11:16:03 -0700 Subject: [Patches] [ python-Patches-1581073 ] Allow textwrap to preserve leading and trailing whitespace Message-ID: Patches item #1581073, was opened at 2006-10-20 07:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1581073&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Dwayne Bailey (dwaynebailey) Assigned to: Greg Ward (gward) Summary: Allow textwrap to preserve leading and trailing whitespace Initial Comment: The attached file add the ability to preserve whitespace in textwrap. Usefull where you are using textwrap in instances where whitespace is significant (I'm using it to reflow Gettext PO file text). By default the current behaviour is preserver so the added option is called drop_whitespace and by default it is set to True. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 18:16 Message: Logged In: YES user_id=849994 Originator: NO Added patch, test and doc changes in rev. 54341. ---------------------------------------------------------------------- Comment By: Dwayne Bailey (dwaynebailey) Date: 2006-10-20 07:22 Message: Logged In: YES user_id=937299 Hi Greg, I'm assigning this to you as you seem to be the original author and suggested that was the best step in this email: http://mail.python.org/pipermail/python-dev/2005-February/051769.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1581073&group_id=5470 From noreply at sourceforge.net Tue Mar 13 19:20:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 11:20:25 -0700 Subject: [Patches] [ python-Patches-1580674 ] posix.readlink doesn't use filesystemencoding Message-ID: Patches item #1580674, was opened at 2006-10-19 17:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: posix.readlink doesn't use filesystemencoding Initial Comment: Unlink most (all?) other functions in posixmodule posix.readlink doesn't encode unicode arguments using the default filesystem encoding but using the default system encoding. This patch files that. The reason I haven't applied this yet is that this patch also changes the return type: if the argument of readlink is a unicode string the result will also be one, just like with os.listdir. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 18:20 Message: Logged In: YES user_id=849994 Originator: NO In light of the recent issue with glob.py, I think that this is better not backported to 2.5. Closing now. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 10:46 Message: Logged In: YES user_id=580910 Applied to the trunk in revision 52415. I'm keeping this patch open while waiting for feedback on the backport question that I posted on python-dev. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-22 10:37 Message: Logged In: YES user_id=21627 The patch is fine, please apply. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-22 09:29 Message: Logged In: YES user_id=580910 readlink2.patch cleans up the unicode check and adds a documentation update. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 17:48 Message: Logged In: YES user_id=21627 This should be discussed on python-dev. I don't think the change in return type should be backported - it has a real chance of breaking applications (which suddenly start seeing Unicode strings where none were before). Always using the file system encoding (instead of the default encoding) but leaving the return type might be considered a bug fix. It also might be considered a new feature: you can now do things you couldn't before. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-20 08:50 Message: Logged In: YES user_id=580910 The type check and unicode conversion of the result were copied from listdir. I agree that calling PyArg_ParseTuple just to check if an argument is unicode is overkill. I'll change the check to a plain PyUnicode_Check of the first argument and add the documentation update. BTW. Is this change valid for backporting to 2.5.1? The reason I looked into this is that os.path.realpath is broken when a unicode argument is used with non-ascii characters and there is a symlink during resolving the path. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 07:56 Message: Logged In: YES user_id=21627 The patch looks right in principle (although the duplicate parsing seems overkill; checking whether the first tuple element (if any) is a Unicode object should do just as well). The change in return type still needs to be documented, though (with \versionchanged). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1580674&group_id=5470 From noreply at sourceforge.net Tue Mar 13 19:24:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 11:24:59 -0700 Subject: [Patches] [ python-Patches-1605192 ] Make Imap Error more helpful Message-ID: Patches item #1605192, was opened at 2006-11-29 11:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Make Imap Error more helpful Initial Comment: Hi, In my app I got this error: imaplib.error: command SEARCH illegal in state AUTH. but I did successfully login. After reading the source of imaplib.py I realized that this was meant: imaplib.error: command SEARCH illegal in state AUTH. Allowed after: SELECTED Attached is a small patch to make the error message more helpful. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 18:24 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, applied a similar one in rev. 54343. ---------------------------------------------------------------------- Comment By: Mark Roberts (mark-roberts) Date: 2006-12-27 17:52 Message: Logged In: YES user_id=1591633 Originator: NO The patch looks great (Not as though I have a lot of say to say so..), but it seems incongruous that you say "allowed after" when it might seem more explicit to say "Allowed in states", like so: "Allowed in states: %s" % (", ".join(Commands[command]) Otherwise, I'm all for more explicit error messages! - Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1605192&group_id=5470 From noreply at sourceforge.net Tue Mar 13 19:32:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 11:32:06 -0700 Subject: [Patches] [ python-Patches-1537850 ] option to leave tempfile.NamedTemporaryFile around on close Message-ID: Patches item #1537850, was opened at 2006-08-10 06:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Damien Miller (djmdjm) Assigned to: Nobody/Anonymous (nobody) Summary: option to leave tempfile.NamedTemporaryFile around on close Initial Comment: Hi, tempfile.NamedTemporaryFile provides a good interface to creating temporary files, but its insistence on deleting the file upon close is limiting. The attached patch adds an optional parameter to NamedTemporaryFile that allows persistence of the temp file after it has been closed. One use-case that demonstrates where keeping the temporary file around is handy would be when you need to safely create and fill a temp file before it is atomically moved into place with os.rename(). E.g. def update_conf(conf_path): old = open(conf_path) tmp = tempfile.NamedTemporaryFile(prefix = os.basename(conf_path), \ dir = os.dirname(conf_path), delete = False) for l in old: tmp.write(l.replace('war', 'peace')) close(old) close(tmp) os.link(conf_path, conf_path + ".old") os.rename(tmp.name, conf_path) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 18:32 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed with doc changes as rev. 54344. ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-26 06:47 Message: Logged In: YES user_id=1359232 Well, that would a) not be an atomic replacement and b) you miss (or would have to reimplement) the mkstemp() like behaviour. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-26 06:40 Message: Logged In: YES user_id=357491 Right, it doesn't create a filesystem file. But that is the point. You work in memory and then write to your final destination as needed. Your code you have pasted in the description does nothing special that requires the use of a temporary file. You can just write into a StringIO object, skip the os.link call, and then just write out to the final file location. ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-25 04:27 Message: Logged In: YES user_id=1359232 Here is an diff that includes a regress test ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-25 00:22 Message: Logged In: YES user_id=1359232 As far as I can tell, StringIO doesn't actually create a filesystem object that can be manipulated. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-08-24 23:52 Message: Logged In: YES user_id=357491 Why can't you store into an instance of StringIO instead of a temp file? ---------------------------------------------------------------------- Comment By: Damien Miller (djmdjm) Date: 2006-08-10 06:58 Message: Logged In: YES user_id=1359232 oops, wrong Category: this should be Lib and not Modules ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1537850&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:32:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:32:46 -0700 Subject: [Patches] [ python-Patches-1533909 ] Let timeit accept functions Message-ID: Patches item #1533909, was opened at 2006-08-03 14:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533909&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Let timeit accept functions Initial Comment: I see that there is a history of proposed (and rejected) patches to allow timeit to see various module global namespaces, etc. But I'm surprised that no one has proposed the obvious functional solution: allow the arguments (particularly 'stmt') to be functions that get called, instead of strings that get parsed and executed. This does increase the measurement overhead slightly, adding in the function call, but in many cases it is far more useful within scripts. To time some part of the code, you can replace a function call 'foo()' with 'timeit.Timer(foo).timeit()'. I also propose helper functions for use within scripts: timeit.timeit(...) is shorthand for timeit.Timer(...).timeit(...), and timeit.repeat(...) is shorthand for timeit.Timer(...).repeat(...). Now you can replace a function call 'foo()' with 'timeit.timeit(foo)', e.g., 'print "foo takes", timeit.timeit(foo), "seconds"'. Attached is a simple patch implementing both of these changes. Documentation would need updating too. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 19:32 Message: Logged In: YES user_id=849994 Originator: NO Reformatted the patch, bugfixed it, added documentation and committed as rev. 54348. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 18:12 Message: Logged In: YES user_id=849994 Please use four-space indents when contributing library code. Perhaps unicode "stmt" arguments should also be allowed. Perhaps other arguments should be checked with callable() to exclude lists or something like that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1533909&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:35:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:35:23 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 18:51 Message generated for change (Comment added) made by mooonz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Moonz (mooonz) Assigned to: Nobody/Anonymous (nobody) Summary: httplib gzip support Initial Comment: Add gzip support for httplib. It seems to work correctly - according to the tests I did done, but some points should be altered (I think to the putrequest method, where I didn't change anything - except the two lines of comments who said that the gzip support is not included) ---------------------------------------------------------------------- >Comment By: Moonz (mooonz) Date: 2007-03-13 19:35 Message: Logged In: YES user_id=826215 Originator: YES Wow, you digged up something I forgot for my own sake :) Seriously, did I really made this horrible piece of crap ? All my apologies for that... Allthough, if sb is interested in gzip support in httplib, I should have something somewhere on my computer which should do the job in a better way (can't make worst, anyway ;)). It's a complete rewrite of the GzipFile class which doesn't need a random access to the data... I'll upload it tomorrow... ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 00:40 Message: Logged In: YES user_id=51702 Originator: NO I have applied and tested this patch. The code seems to be correct. Fetching gzipped data from www.mozilla.org works as it should. What the patch does is change Accept-Encoding from identity to identity,gzip;q=0.9. That hints the HTTP server that we can handle gzipped data. Some servers take the hint and sends us gzipped data (www.mozilla.org is such a server). We check if that is so by checking the Content-Encoding header in the HTTP response headers. If that is set to gzip, the body of the response is gzipped data. What then happens is that we create a hacked GzipFile object that works on a wrapped version of the HTTPResponse itself. It has to be hacked, because GzipFile works by seeking to the end of the file object. That ofcourse does not work for us, because the whole file is not available. But this hacked version employs some kind of StringIO trick so that instead of seeking to the end of the file, it seeks to the end of the read data. So HTTPResponse aquires a reference to GzipFile2 which it reads from. GzipFile2 in turn, has a reference to GzipedHTTPIO (the wrapper) which in turn references the HTTPResponse. The read method in HTTPResponse invokes the read method on GzipedFile2 which invokes the read of GzipedHTTPIO which invokes the read of HTTPResponse. But GzipedHTTPIO breaks the potential recursion by specifying raw=True which means that it want HTTPResponse to feed it uncompressed data. A very, very clever scheme. I hope this information is useful. It took me way to long to get this far. Originally I thought that this patch should be rejected because it is just to damn complicated, but then I saw that the rest of httplib.py is equally complicated. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-31 22:38 Message: Logged In: YES user_id=1188172 This will need documentation and test suite changes, too. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:36:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:36:39 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 19:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 19:36 Message: Logged In: YES user_id=849994 Originator: NO Note that commands.mkarg() is written for UNIX shells. While it may work with spaces in the file name, it may produce illegal Windows command line commands in other cases. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 17:54 Message: Logged In: YES user_id=11375 Would it simplify matters if CGIHTTPServer used the subprocess module, which tries to provide a platform-independent interface? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:37:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:37:57 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 18:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Moonz (mooonz) Assigned to: Nobody/Anonymous (nobody) Summary: httplib gzip support Initial Comment: Add gzip support for httplib. It seems to work correctly - according to the tests I did done, but some points should be altered (I think to the putrequest method, where I didn't change anything - except the two lines of comments who said that the gzip support is not included) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 19:37 Message: Logged In: YES user_id=849994 Originator: NO Note that we already have a patch for that, in #1675951. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2007-03-13 19:35 Message: Logged In: YES user_id=826215 Originator: YES Wow, you digged up something I forgot for my own sake :) Seriously, did I really made this horrible piece of crap ? All my apologies for that... Allthough, if sb is interested in gzip support in httplib, I should have something somewhere on my computer which should do the job in a better way (can't make worst, anyway ;)). It's a complete rewrite of the GzipFile class which doesn't need a random access to the data... I'll upload it tomorrow... ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 00:40 Message: Logged In: YES user_id=51702 Originator: NO I have applied and tested this patch. The code seems to be correct. Fetching gzipped data from www.mozilla.org works as it should. What the patch does is change Accept-Encoding from identity to identity,gzip;q=0.9. That hints the HTTP server that we can handle gzipped data. Some servers take the hint and sends us gzipped data (www.mozilla.org is such a server). We check if that is so by checking the Content-Encoding header in the HTTP response headers. If that is set to gzip, the body of the response is gzipped data. What then happens is that we create a hacked GzipFile object that works on a wrapped version of the HTTPResponse itself. It has to be hacked, because GzipFile works by seeking to the end of the file object. That ofcourse does not work for us, because the whole file is not available. But this hacked version employs some kind of StringIO trick so that instead of seeking to the end of the file, it seeks to the end of the read data. So HTTPResponse aquires a reference to GzipFile2 which it reads from. GzipFile2 in turn, has a reference to GzipedHTTPIO (the wrapper) which in turn references the HTTPResponse. The read method in HTTPResponse invokes the read method on GzipedFile2 which invokes the read of GzipedHTTPIO which invokes the read of HTTPResponse. But GzipedHTTPIO breaks the potential recursion by specifying raw=True which means that it want HTTPResponse to feed it uncompressed data. A very, very clever scheme. I hope this information is useful. It took me way to long to get this far. Originally I thought that this patch should be rejected because it is just to damn complicated, but then I saw that the rest of httplib.py is equally complicated. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-31 22:38 Message: Logged In: YES user_id=1188172 This will need documentation and test suite changes, too. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:41:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:41:48 -0700 Subject: [Patches] [ python-Patches-1526367 ] str.__iter__ and unicode.__iter__ Message-ID: Patches item #1526367, was opened at 2006-07-21 09:39 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: str.__iter__ and unicode.__iter__ Initial Comment: This patch add iterator classes for str and unicode, as discussed here: http://mail.python.org/pipermail/python-3000/2006-July/002650.html ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 19:41 Message: Logged In: YES user_id=849994 Originator: NO This looks good, but needs new tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 From noreply at sourceforge.net Tue Mar 13 20:49:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 12:49:46 -0700 Subject: [Patches] [ python-Patches-1243678 ] httplib gzip support Message-ID: Patches item #1243678, was opened at 2005-07-23 18:51 Message generated for change (Comment added) made by mooonz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Moonz (mooonz) Assigned to: Nobody/Anonymous (nobody) Summary: httplib gzip support Initial Comment: Add gzip support for httplib. It seems to work correctly - according to the tests I did done, but some points should be altered (I think to the putrequest method, where I didn't change anything - except the two lines of comments who said that the gzip support is not included) ---------------------------------------------------------------------- >Comment By: Moonz (mooonz) Date: 2007-03-13 19:49 Message: Logged In: YES user_id=826215 Originator: YES I saw it a few seconds after clicking the "submit" button ;) OK, please forget my last message and this complete thread. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 19:37 Message: Logged In: YES user_id=849994 Originator: NO Note that we already have a patch for that, in #1675951. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2007-03-13 19:35 Message: Logged In: YES user_id=826215 Originator: YES Wow, you digged up something I forgot for my own sake :) Seriously, did I really made this horrible piece of crap ? All my apologies for that... Allthough, if sb is interested in gzip support in httplib, I should have something somewhere on my computer which should do the job in a better way (can't make worst, anyway ;)). It's a complete rewrite of the GzipFile class which doesn't need a random access to the data... I'll upload it tomorrow... ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-12 00:40 Message: Logged In: YES user_id=51702 Originator: NO I have applied and tested this patch. The code seems to be correct. Fetching gzipped data from www.mozilla.org works as it should. What the patch does is change Accept-Encoding from identity to identity,gzip;q=0.9. That hints the HTTP server that we can handle gzipped data. Some servers take the hint and sends us gzipped data (www.mozilla.org is such a server). We check if that is so by checking the Content-Encoding header in the HTTP response headers. If that is set to gzip, the body of the response is gzipped data. What then happens is that we create a hacked GzipFile object that works on a wrapped version of the HTTPResponse itself. It has to be hacked, because GzipFile works by seeking to the end of the file object. That ofcourse does not work for us, because the whole file is not available. But this hacked version employs some kind of StringIO trick so that instead of seeking to the end of the file, it seeks to the end of the read data. So HTTPResponse aquires a reference to GzipFile2 which it reads from. GzipFile2 in turn, has a reference to GzipedHTTPIO (the wrapper) which in turn references the HTTPResponse. The read method in HTTPResponse invokes the read method on GzipedFile2 which invokes the read of GzipedHTTPIO which invokes the read of HTTPResponse. But GzipedHTTPIO breaks the potential recursion by specifying raw=True which means that it want HTTPResponse to feed it uncompressed data. A very, very clever scheme. I hope this information is useful. It took me way to long to get this far. Originally I thought that this patch should be rejected because it is just to damn complicated, but then I saw that the rest of httplib.py is equally complicated. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-31 22:38 Message: Logged In: YES user_id=1188172 This will need documentation and test suite changes, too. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 18:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:03:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:03:19 -0700 Subject: [Patches] [ python-Patches-1530482 ] pydoc render_doc Message-ID: Patches item #1530482, was opened at 2006-07-28 15:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: ganges master (gangesmaster) >Assigned to: Georg Brandl (gbrandl) Summary: pydoc render_doc Initial Comment: a patch for improving pydoc's inner working. instead of doc() doing both the text rendering and sending it to the pager, introduce a new function, render_doc(), that renders the text. doc() now calls render_doc() and sends the text to the pager. this allows external programs to generate a "text only" version of the documentation, without having to read it from stdout. reference: http://mail.python.org/pipermail/python-dev/2006-July/067776.html the patch is against revision 50881: http://svn.python.org/view/python/trunk/Lib/pydoc.py?rev=50881&view=markup ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:03 Message: Logged In: YES user_id=849994 Originator: NO Committed in rev. 54352. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:08:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:08:26 -0700 Subject: [Patches] [ python-Patches-1504199 ] Switch syntax (partial PEP 275) Message-ID: Patches item #1504199, was opened at 2006-06-11 02:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504199&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Switch syntax (partial PEP 275) Initial Comment: Attached is a partial implementation of PEP 275. It should offer a slight performance enhancement over if/elif/else, although it won't be nearly as fast as a lookup table generated at compile time (as the PEP suggests). However, it is more flexible than a compile-time generated lookup table in that it accepts expressions - not just constants - for each case clause. No new opcodes were added. Cheers, Tom ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:08 Message: Logged In: YES user_id=849994 Originator: NO The PEP was rejected, so rejecting the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504199&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:17:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:17:37 -0700 Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault in object_reduce_ex Message-ID: Patches item #1462488, was opened at 2006-04-01 00:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) >Assigned to: ?iga Seilnacht (zseil) Summary: Patch for bug #931877 Segfault in object_reduce_ex Initial Comment: This prevents unbounded recursion in typeobject.c's object_reduce_ex(). It does so by splitting implementation for object.__reduce_ex__ and object.__reduce__ into two different C functions. See the apended file details.txt for more detailed explanation. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:17 Message: Logged In: YES user_id=849994 Originator: NO I think this patch is fine, but you should include at least some of the detailed description as a comment for the new reduce method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:23:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:23:59 -0700 Subject: [Patches] [ python-Patches-1489771 ] Updates to syntax rules in reference manual Message-ID: Patches item #1489771, was opened at 2006-05-16 19:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) >Assigned to: ?iga Seilnacht (zseil) Summary: Updates to syntax rules in reference manual Initial Comment: I tried to update the reference manual to the current Python syntax. Some things are still missing, most notably the yield expression. Detailed description of changes below. I can also attach the generated webpages, if someone is interested. Expressions =========== List Displays ------------- Reordered the rules so that the style is consistent with the rest of the manual. Separated listmaker into expression_list and list_comprehension, for better readability. Replaced "expression_list" between "for" and "in" with "target_list". See this thread for details: http://mail.python.org/pipermail/python-dev/2006-April/064264.html The only thing missing is old_lambdadef. Generator Expressions --------------------- Simmilar as above. Calls ----- Fixed the latex syntax (somebody forgot to remove a line when generators were introduced). Replaced test with expression. Fixed allowed positions for commas (func(*args,) is not allowed). Boolean operations ------------------ Restructured the new conditional expression so that it is more readable. Simple Statements ================= Augmented assignment statements ------------------------------- Removed comments from "productionlist" macro, since they broke the generated grammar.txt file. Removed empty groups that are not needed anymore, since automatic conversion to guillemets was disabled. Unfortunately the escaped operator characters would still need manual fixing in the grammar.txt file. The print statement ------------------- Removed all uses of the "optional" macro and replaced them with sqare brackets, since it broke the generated grammar.txt file. The import statement -------------------- Replaced all invalid uses of name with identifier. Added relative import notation to the grammar section. Description of relative imports is still needed. The exec statement ------------------ Corrected a minor mistake, since exec "a = 1" or "a = 2" is not valid Python syntax. Added a (commented out) section about a strange feature (you can already treat exec as a function) that should IMHO be included in documentation and its use encouraged over the current notation. Compound statements =================== The with statement ------------------ Added missing macro. Function definition ------------------- Cleaned up "parameter_list" so that it is correct and expresses all the restrictions, but is still easier to understand (I hope). Still needed ------------ Yield became an expression in version 2.5, but this is not documented. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:23 Message: Logged In: YES user_id=849994 Originator: NO You can probably look at this/complete it and apply it yourself now ;) ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 13:33 Message: Logged In: YES user_id=1326842 Yes, the only thing missing was old lambda. The new patch ('reference_manual_old_lambda') includes it. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 11:01 Message: Logged In: YES user_id=849994 The testlist in list comprehensions ("testlist_safe" in Grammar/Grammar) is different from the normal testlist. Does your patch address this? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-29 23:56 Message: Logged In: YES user_id=1326842 Attaching a patch updated to the current trunk with two minor fixes: - I reverted the changes to the __future__ statement because they broke the output; - fixed a mistake in the function definition section; I didn't know that ``def f(a, (b, c)=(1, 2)): pass`` is valid syntax. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-18 03:46 Message: Logged In: YES user_id=1326842 I created another patch and updated the previous two with the following fixes: - Disabled an example of the EBNF notation in introduction to prevent name clashes and inclusion into the generated grammar file. - yield can be a bare statement in 2.5. - Reintroduced "name" in import statements, so that explanation can stay the same. - Reformated __future__ import statement, but left the latex syntax broken so that it still won't be included into grammar.txt. - Fixed a paragraph about valid __future__ features. The new patch is more of an example how hard it would be to synchronise the names. It is more or less consistent with the Grammar file, but as a consequence is completely out of sync with the surrounding text. While I would like to see less differences betwen Grammar and Reference manual, I don't think it is that easy, since someone would also have to check the rest of the text and fix all incorrect references. I would guess that the same holds for changing the Grammar file; you would simply have to change too much code. I think that the simplest solution is to add the table from my previous comment to the PEP 306. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-17 22:55 Message: Logged In: YES user_id=764593 I agree that it would be better if they were consistent. But does the manual have better names? If so, alpha is a good time to fix the grammar file. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-17 16:54 Message: Logged In: YES user_id=1326842 Token names in reference manual already differ from those in Grammar file. I only added new tokens where it helps readability: - I've split listmaker into expression_list (already present in reference manual and often used) and list_comprehension. - I added conditional_expression, because I thought it helps readability. - Differences in function definiton and call syntax can't be avoided since Grammar file doesn't express all the limitations. - Same goes for target_list; Grammar uses testlist, but that was one of the problems raised in the thread mentioned above. The biggest problem is that what is known as "test" in Grammar/Grammar, is "expression" in the reference manual, and I think I fixed all parts that didn't take this in cosideration. I'm attaching two new patches. reference_manual_updated.diff contains another fix (removed unneeded markup and comments), but is otherwise the same as the previous patch. reference_manual_conservative.diff also contains this fix, but removes tokens list_comprehension and conditional_expression. This means that there are still large differences between Grammar file and reference manual, most notably: Grammar manual --------------------------------------------- NAME identifier expr or_expr test expression old_test test testlist expression_list | target_list testlist_safe testlist All of these differences were already present before my changes. Let me know if you want them fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 15:01 Message: Logged In: YES user_id=849994 I think the token names in the reference should not be different from those in python/Grammar/Grammar. Aside from this, the patch is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:26:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:26:57 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 14:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:26 Message: Logged In: YES user_id=849994 Originator: NO How is the atexit module to work after this patch? (It could be reimplemented in C and reuse the old exitfunc functionality.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:30:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:30:24 -0700 Subject: [Patches] [ python-Patches-1517586 ] Patch to commands.py to enable callback support Message-ID: Patches item #1517586, was opened at 2006-07-05 15:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517586&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Brad Doctor (bdoctor) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to commands.py to enable callback support Initial Comment: This is a patch to commands.py to enable callback support, which is very useful for long-running commands. Whenever there is stdout from the process the callback is fed whatever it got. Example usage: import commands cmd = 'top -b -n2' def fancy(out): print 'GOT(%s)' % out.strip() commands.cb = fancy (s,o) = commands.getstatusoutput(cmd) print 'OUTPUT (%s)' % o Please consider adding this. The existing API is not changed, however as you can see it is simple to use the callback. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:30 Message: Logged In: YES user_id=849994 Originator: NO Rejecting this for a number of reasons: Module-level globals to be set by the user of a module are bad 1) it is not obvious if it's not set directly before the getstatusoutput() call 2) it's completely confusing with threads 3) commands is quasi-deprecated in favor of subprocess ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-07 23:29 Message: Logged In: YES user_id=51702 Originator: NO Your semantic for the cb name seems kind of arbitrary. Why is it called for each line of the output and only once with all the output. Plus, iterating through the output line for line can make it much slower than reading it all at once. Also, the next time you run getstatusoutput(), maybe even from another module, the callback will still be called. That could be unexpected. Plus commands is almost deprecated in favour of subprocess. I recommend rejecting this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517586&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:30:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:30:40 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 10:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-13 16:30 Message: Logged In: YES user_id=1344176 Originator: YES Guido suggested renaming sys.exitfunc to sys._exitfunc: http://mail.python.org/pipermail/python-3000/2007-March/006100.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 16:26 Message: Logged In: YES user_id=849994 Originator: NO How is the atexit module to work after this patch? (It could be reimplemented in C and reuse the old exitfunc functionality.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:33:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:33:58 -0700 Subject: [Patches] [ python-Patches-1516309 ] Remove deprecated functions from operator Message-ID: Patches item #1516309, was opened at 2006-07-03 12:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove deprecated functions from operator Initial Comment: This patch removes the isCallable() and sequenceIncludes() functions from the operator module. These functions have been deprecated since Python 2.0. This patch is against r47214. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:33 Message: Logged In: YES user_id=849994 Originator: NO I think you can safely commit this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:45:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:45:04 -0700 Subject: [Patches] [ python-Patches-1649190 ] Adding support for _Bool to ctypes as c_bool Message-ID: Patches item #1649190, was opened at 2007-01-31 22:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1649190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: David Remahl (chmod007) Assigned to: Thomas Heller (theller) Summary: Adding support for _Bool to ctypes as c_bool Initial Comment: Adds support for the C99 _Bool type to ctypes. Requires struct patch that has already been accepted in the python 2.6 train. Updates ctypes C extension, ctypes __init__.py, ctypes documentation and ctypes tests. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2007-03-13 21:45 Message: Logged In: YES user_id=11105 Originator: NO Committed as revision 54357. Thanks for the patch. ---------------------------------------------------------------------- Comment By: David Remahl (chmod007) Date: 2007-02-02 01:35 Message: Logged In: YES user_id=2135 Originator: YES Thanks for the review, Thomas! I've attached a new patch that addresses the points you bring up (I hope) in the suggested manner. I have not tested it on 2.5, but tests pass on 2.6. File Added: c_bool patch against r53623.diff ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2007-02-01 21:22 Message: Logged In: YES user_id=11105 Originator: NO David, I encountered these issues with the patch: 1. a typo in Lib/ctypes/test/test_numbers.py: 'bool_type' should be 'bool_types' It is trivial to fix this. 2. ctypes/__init__.py should be cean for 'from ctypes import *', but with your patch it exposes the 'struct_error' symbol. I would recommend to change Modules/_ctypes/cfield.c so that a c_bool type can be created even if HAVE_C99_BOOL is undefined (I think you took that approach in your _Bool struct patch). Then, ctypes/__init__.py would not have to depend on the struct 't' typecode at all. The '_check_size(c_bool, "t")' check can probably be removed. 3. ctypes/test/test_repr.py does not work. Easy to fix this: just add c_bool to the list of types starting at line 5. These changes would also ensure compatibility with previous Python versions, with one exception: A check for the _Bool type must be added to Modules/ctypes/libffi/configure.in. To answer your question: No, it is not needed to prepare a patch relative to ctypes/trunk/ctypes. This repository contains svn:external properties for the 'source' and 'ctypes' directories that point into the 'release25-maint/Modules/_ctypes' and 'release25-maint/Lib/ctypes' directories from Python. ---------------------------------------------------------------------- Comment By: David Remahl (chmod007) Date: 2007-02-01 16:50 Message: Logged In: YES user_id=2135 Originator: YES Should I prepare the patch relative to /ctypes/trunk/ctypes instead? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-01-31 23:05 Message: Logged In: YES user_id=21627 Originator: NO Thomas, can you take a look? I think this needs to take into account Python versions without bool support in the struct module, as the same ctypes code is used with older Python releases as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1649190&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:47:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:47:10 -0700 Subject: [Patches] [ python-Patches-1444529 ] kwdargs for compile/__import__ Message-ID: Patches item #1444529, was opened at 2006-03-07 00:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas Wouters (twouters) >Assigned to: Georg Brandl (gbrandl) Summary: kwdargs for compile/__import__ Initial Comment: Keyword arguments for compile() and __import__(), as discussed at PyCon. There is a slight speed difference on my development system: __import__ is ~1% slower, compile() is ~1.5% faster. I blame both on caches, alignment and what not, so I bet they're totally different for everyone. I'd say the advantage of managing the growing set of arguments outweighs the speed impact (if any.) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:47 Message: Logged In: YES user_id=849994 Originator: NO __import__ already accepted kwargs, committed the compile() part in rev. 54358. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-05 13:16 Message: Logged In: YES user_id=21627 Originator: NO Is anybody still working on this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-07 05:22 Message: Logged In: YES user_id=33168 These look good to me. Thanks Thomas. I had started a patch for import. BTW I think the new __import__ needs to be documented in libfuncs.txt or somewhere like that. If you don't get to it, I'll find my change and update the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1444529&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:47:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:47:47 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 14:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:47 Message: Logged In: YES user_id=849994 Originator: NO Hm, that doesn't make me too happy. Why do we need exitfunc at all if we have atexit? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-13 20:30 Message: Logged In: YES user_id=1344176 Originator: YES Guido suggested renaming sys.exitfunc to sys._exitfunc: http://mail.python.org/pipermail/python-3000/2007-March/006100.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:26 Message: Logged In: YES user_id=849994 Originator: NO How is the atexit module to work after this patch? (It could be reimplemented in C and reuse the old exitfunc functionality.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:49:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:49:51 -0700 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 13:35 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Martin v. L?wis (loewis) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-13 13:49 Message: Logged In: YES user_id=341410 Originator: YES I have just attached an updated patch (against trunk) for ntpath expandusers and expandvars that includes documentation and test updates. File Added: ntpath_full.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 01:41 Message: Logged In: YES user_id=849994 Originator: NO This fixes #796219. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 01:39 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good to me; documentation updates and new tests will be needed though. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 14:25 Message: Logged In: YES user_id=341410 I've just attached an updated version of the patch to handle expandusers (without recursive environment variable expansion), as well as a variant of http://python.org/sf/1574252 to handle %VAR% style expansions on Windows. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 03:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 03:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-14 18:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 13:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 13:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 13:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\\Documents and Settings\\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\\bob') '~billy\\bob' >>> ntpath.expanduser('~\\bob') 'C:\\Documents and Settings\\jcarlson\\bob' >>> ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') '~billy\\%TESTING%\\%TESTING1%\\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\\billy' >>> ntpath_patched.expanduser('~billy\\bob') 'C:Documents and Settings\\billy\\bob' >>> ntpath_patched.expanduser('~\\bob') 'C:Documents and Settings\\jcarlson\\bob' >>> ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') 'C:Documents and Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:51:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:51:09 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 10:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-13 16:51 Message: Logged In: YES user_id=1344176 Originator: YES Me, either. I'd prefer to reimplement atexit in C and make use of something like the Py_AtExit-related functionality in pythonrun.c. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 16:47 Message: Logged In: YES user_id=849994 Originator: NO Hm, that doesn't make me too happy. Why do we need exitfunc at all if we have atexit? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-13 16:30 Message: Logged In: YES user_id=1344176 Originator: YES Guido suggested renaming sys.exitfunc to sys._exitfunc: http://mail.python.org/pipermail/python-3000/2007-March/006100.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 16:26 Message: Logged In: YES user_id=849994 Originator: NO How is the atexit module to work after this patch? (It could be reimplemented in C and reuse the old exitfunc functionality.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Tue Mar 13 21:54:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 13:54:31 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 14:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:54 Message: Logged In: YES user_id=849994 Originator: NO Then let's come up with a patch and sneak it in while Guido isn't watching ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-13 20:51 Message: Logged In: YES user_id=1344176 Originator: YES Me, either. I'd prefer to reimplement atexit in C and make use of something like the Py_AtExit-related functionality in pythonrun.c. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:47 Message: Logged In: YES user_id=849994 Originator: NO Hm, that doesn't make me too happy. Why do we need exitfunc at all if we have atexit? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-13 20:30 Message: Logged In: YES user_id=1344176 Originator: YES Guido suggested renaming sys.exitfunc to sys._exitfunc: http://mail.python.org/pipermail/python-3000/2007-March/006100.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:26 Message: Logged In: YES user_id=849994 Originator: NO How is the atexit module to work after this patch? (It could be reimplemented in C and reuse the old exitfunc functionality.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Tue Mar 13 22:09:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 14:09:14 -0700 Subject: [Patches] [ python-Patches-1393667 ] Add restart debugger command to pdb.py Message-ID: Patches item #1393667, was opened at 2005-12-30 15:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Rocky Bernstein (rockyb) Assigned to: Nobody/Anonymous (nobody) Summary: Add restart debugger command to pdb.py Initial Comment: The enclosed patch adds a restart command to pdb. (The short command name is "R" as it is in perldb). With an optional argument, the program arguments are reassigned. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:09 Message: Logged In: YES user_id=849994 Originator: NO Committed and added docs in rev. 54360. ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-06-18 20:46 Message: Logged In: YES user_id=158581 Tried on both GNu/Linux and NetBSD: restart Undefined command: "restart". Try "help". (gdb) show version GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu". (gdb) info checkpoint Undefined info command: "checkpoint". Try "help info". ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 19:36 Message: Logged In: YES user_id=971153 For the record: gdb does have a "restart" command http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html (it's used to restart from a particular checkpoint) ---------------------------------------------------------------------- Comment By: Rocky Bernstein (rockyb) Date: 2006-06-08 08:06 Message: Logged In: YES user_id=158581 Sorry for not responding earlier. As getting this was taking a bit of time moving forward, in the interrum I had been making much faster progress by splitting this off into it's own little project under the bash debugger project I have on sourceforge (http://bashdb.sourceforge.net/pydb). Being able to make public releases earlier and oftener has offorded the oppertunity to move much further along much quicker than via the patch method (where we still haven't gotten past restarting the debugger). Now back to your comments/questions. In pydb, there are two kinds of "restart". "run" is like gdb's run. Debugger state (breakpoints, watchpoints, display expressions, debugger settings for list size, etc.) are preserved. Same as in gdb. Gdb does not to my knowledge have a command called "restart". However I've taken your suggestion of not having a "restart" be the same thing as "run". "restart" is a re-exec of the debugger. No state is save. As a debugger writer, I personally find that one useful ;-) Having the R be an alias for "run" is helpful since it's short and matches what's used Perl where people use the debugger more frequently. In fact there's a whole book written on the Perl debugger. (And I also use 'R' in the GNU Make and bash debuggers.) As for "ru", well, since I've added command completion, I feel this issue is less important. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-02 04:51 Message: Logged In: YES user_id=971153 one suggestion though: do we really need 'restart' alias? The main problem is that gdb uses "restart" for a very different purpose (restarting a program from a known state)..And we probably shouldn't deviate from gdb's command set unless we have to. Also I think we should not pollute the command space without a real need...(a similar argument could be made agaist "ru" abbreviation as well, but it's of lesser importance) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-02-02 04:40 Message: Logged In: YES user_id=971153 The patch works for me. I think the feature is desirable. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-20 21:44 Message: Logged In: YES user_id=1188172 Patch looks good from my POV. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1393667&group_id=5470 From noreply at sourceforge.net Tue Mar 13 22:40:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 14:40:38 -0700 Subject: [Patches] [ python-Patches-1312980 ] httplib error handling and HTTP/0.9 fix Message-ID: Patches item #1312980, was opened at 2005-10-04 15:12 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1312980&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Yusuke Shinyama (euske) Assigned to: Nobody/Anonymous (nobody) Summary: httplib error handling and HTTP/0.9 fix Initial Comment: HTTPResponse.begin did not initialize self.length if the protocol version is 0.9, which later causes an AttributeError. Also, error handling for "chunk_left = int(line, 16)" in HTTPResponse._read_chunked is missing, which might cause a ValueError. The patch fixes the above two problems. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:40 Message: Logged In: YES user_id=849994 Originator: NO The "length" problem is already fixed and the chunked handling is tracked in #1486335. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1312980&group_id=5470 From noreply at sourceforge.net Tue Mar 13 22:47:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 14:47:22 -0700 Subject: [Patches] [ python-Patches-900744 ] catch invalid chunk length in httplib read routine Message-ID: Patches item #900744, was opened at 2004-02-19 23:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wummel (calvin) Assigned to: Georg Brandl (gbrandl) Summary: catch invalid chunk length in httplib read routine Initial Comment: In HTTPResponse._read_chunked the chunk length is not checked to be a valid integer, and a ValueError will be raised in such a case. The attached patch catches ValueError (which should not normally happen, so this try:except: is reasonably fast), and raises IncompleteRead exception instead. I have no test case for this yet, but am trying to construct one :) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:47 Message: Logged In: YES user_id=849994 Originator: NO See also #1486335. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-19 16:05 Message: Logged In: YES user_id=21627 Originator: NO I meant to suggest that your patch (based on agwego's recommendation) should be accepted. Now that you ask, I'm not so sure anymore: errors should never pass silently. So I now think, that it should raise IncompleteRead, based also on the observation that these methods can *already* raise IncompleteRead, and that this already carries the data that we received. OTOH, IIUC, the error also means that we lost protocol synchronisation with the server, so we should in any case close the connection. So merging these changes is probably the right thing :-) Withdrawing my acceptance again, and hoping that somebody can produce a complete patch (which includes the test case in a style that works with regrtest) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-02-19 12:10 Message: Logged In: YES user_id=849994 Originator: NO Martin: which patch? Mine, which returns what was read so far, or calvin's, which raises IncompleteRead? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-18 08:39 Message: Logged In: YES user_id=21627 Originator: NO Georg, the patch is fine for 2.6, please apply (for 2.5, I would be cautious because of the behaviour change). ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2006-02-01 22:16 Message: Logged In: YES user_id=9205 I attached a simple testcase that triggers the bug. IMHO this patch should be applied for Python 2.5. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-19 01:07 Message: Logged In: YES user_id=80475 Technically, the patch is fine and it is the way the code should have been written in the first place. Please bring-up on python-dev to determine whether it should be done. I can imagine that a fair amount of existing code has through trial and error discovered the ValueError and chosen to catch that. Changing the exception may unnecessarily break people's code. Sometimes we take that step when it needs to be done, but there should be a good pay-off and, in this case, I don't see it. You may also want to mention it on comp.lang.python to see if anyone cares If the patch goes forward, see if you can mock-up a test that triggers the exception so we have a good unittest. In anycase, this should not be backported (we avoid giving people reasons to not upgrade). ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-18 19:34 Message: Logged In: YES user_id=1188172 Attaching patch which does what agwego said (httplib-chunked.diff). Please review. ---------------------------------------------------------------------- Comment By: agwego (agwego) Date: 2005-02-28 16:53 Message: Logged In: YES user_id=1228982 I've run into this problem in conjunction with mod_python 3.1.4 (and although the problem is caused in mod_python) my python skills aren't up to the task. Which leaves me with fixing httplib. Although the above patch works when it comes to end of file situations, I think it would be better to return what has been consumed so far and leave it at that. A few lines down there's a comment about consuming trailers, this is the case that is tripping up httplib as far as I can tell. This is happening in Python 2.3.4. --- packages/Python-2.3.4/Lib/httplib.py Sun Nov 2 11:51:38 2003 +++ httplib.py Mon Feb 28 11:26:48 2005 @@ -423,7 +423,11 @@ i = line.find(';') if i >= 0: line = line[:i] # strip chunk-extensions - chunk_left = int(line, 16) + try: + chunk_left = int(line, 16) + except ValueError, msg: + self.close() + return value if chunk_left == 0: break if amt is None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 From noreply at sourceforge.net Tue Mar 13 22:55:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 14:55:07 -0700 Subject: [Patches] [ python-Patches-1517947 ] assert for NULL in Py_INCREF Py_DECREF Message-ID: Patches item #1517947, was opened at 2006-07-06 06:43 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Rene Dudfield (illume) Assigned to: Nobody/Anonymous (nobody) Summary: assert for NULL in Py_INCREF Py_DECREF Initial Comment: Since Py_INCREF and Py_DECREF should not be able to take NULLs they should do an assert check for this. This would have caught at least one bug earlier in cPickle.loads() http://sourceforge.net/tracker/index.php?func=detail&aid=1512695&group_id=5470&atid=105470 It will also help other extension module authors find this error in their code more easily. Include/object.h #define Py_INCREF(op) ( \ (assert((op) != NULL)) , \ _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ (op)->ob_refcnt++) #define Py_DECREF(op) \ if ((assert((op) != NULL)) , _Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --(op)->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:55 Message: Logged In: YES user_id=849994 Originator: NO Quoting Martin v. L?wis: """ I think it's pointless. If they ever be NULL, the INCRE/DECREF will crash right away, anyway, so you'll certainly notice. As you will have a debug build when the assertion triggers, you can just as well fine the location of the crash quickly in the debugger (e.g. using the core file on systems that support that, or the JIT-debugger on other systems). """ Rejecting on that basis. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-07-07 00:21 Message: Logged In: YES user_id=357491 I don't think that the cPickle bug would have been any sooner. The segfault happens just as early as an assertion would have since both going to access bad memory. Regardless, the adding of the assert() in Py_DECREF might warrant using ``while{} do(0)`` to simplify the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517947&group_id=5470 From noreply at sourceforge.net Tue Mar 13 22:58:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 14:58:55 -0700 Subject: [Patches] [ python-Patches-1429539 ] pdb: fix for 1326406 (import __main__ pdb failure) Message-ID: Patches item #1429539, was opened at 2006-02-11 03:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb: fix for 1326406 (import __main__ pdb failure) Initial Comment: The patch allows pdb to debug program which import from __main__ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:58 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed as rev. 54363. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-17 01:11 Message: Logged In: YES user_id=971153 Another iteration of the patch Now __main__ namespace is explicitly initialized before the program (re)starts. The new patch should both support imports from __main__ AND separate program's and pdb's namespaces.. As a side effect, __file__ will now be set correctly in the main program ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-05-11 03:50 Message: Logged In: YES user_id=971153 I'm attaching an alternative patch: the program stil runs in __main__ namespace, but pdb gets imported first: import pdb pdb.main() So the main program cann't accidentally stomp on pdb internals (e.g by doing help=None) (there is still a bit of namespace pollution in the main program) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-04-23 18:10 Message: Logged In: YES user_id=971153 > 1. Could you give some code examples for that? Do you mean examples of intentional interference with debugger? Well, you could just traverse the stack and check whether the program runs under debugger and then do anything you want... But why do you think intentional interference would ever be an issue? After all python is not a language to write debugger-resistant applications ;-) Anyway, here are some examples of unintentional interference: 1. If you need a custom version of std module, you can modify sys.path and then import the module.. Which works by itself. But if pdb is loaded first and imports the module, then it does not work... 2. Similar problem with any application which changes sys.stdout/sys.stdin (there is actually a SF bug for that) 3. Also I don't see how pdb in its current form can control any program which needs a full-screen control of the terminal... 4. Any program which tries to do any magic with stack and assumes that top level stack frame is the main application will not work under pdb (where top level stack frame is pdb) --------------------------------------------------- And there is a whole separate bunch of intereference issues when pdb restarts the program. --------------------------------------------------- When a program does run in pdb's namespace (as would be the case if this patch is applied), pdb could save copies of all module global symbols which it needs and thus become immune to the accidental overwriting of those symbols in the main program... There could be a better way... ---------------------------------------------------------------------- Comment By: Kuba Ko?czyk (jakamkon) Date: 2006-04-21 15:28 Message: Logged In: YES user_id=1491175 Sorry I forget to login in;)The comment below is from me. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-04-21 15:25 Message: Logged In: NO 1. Could you give some code examples for that? 2,3. Did you notice that google search for "from __main__ import" give hits similar to: t = Timer("test()", "from __main__ import test") in most situations? I think it's hard to value uses of "from..." based on google search or similar method.Maybe we shoud ask on python-list what are the others opinions? >As a middle ground it might be a good idea to expand the >patch to reduce pdb's dependency on module global symbols I'am interesting how would you do that? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-04-21 02:39 Message: Logged In: YES user_id=971153 I do see your point (In fact it was me who submitted the patch #896011 which separated pdb namespace from the program's -- and thus broke imports from __main__ ;-)).. I do want to bring a couple of points: 1. I don't think it matters whether a program can intentionally interfere with pdb...Even when pdb's namespace is separated, it's easy for the program to interfere with debugger.. (Or delete your home directory for that matter) 2. Importing from __main_ may not be common in the std lib, but that's simply because stdlib doesn't contain that many executable hence there are very few places where there is __main__ to import from. google search for "from __main__ import" results in about 1M hits. 3. Just for the record, profile module does not separate its namespace from programs's either... So, basically, it boils down to this: what's worse breaking imports from __main__ or risking accidental interference between pdb and the program (e.g if your program redefines a help symbol)... As a middle ground it might be a good idea to expand the patch to reduce pdb's dependency on module global symbols and thus reducing the risk of interference. What do you think? ---------------------------------------------------------------------- Comment By: Kuba Ko?czyk (jakamkon) Date: 2006-04-20 11:17 Message: Logged In: YES user_id=1491175 I think that exposing pdb's namespaces for debugged code is dangerous.When debugged code have this kind of access he can dynamic change pdb's behaviour without your control: y.py: die = """\ def destroy(x,y): print 'Iam crashing your HOME and deleting your FILES' Pdb.__dict__['do_break'] = destroy # pdb's break = destroy """ x.py: # innocently looking code;) import y exec(y.puff) print "X" with your patch: $ python2.5 -m pdb x.py > /home/xyz/python/x.py(1)() -> import y (Pdb) Pdb.__dict__['do_break'] (Pdb) break (Pdb) n > /home/xyz/python/x.py(2)() -> exec(y.puff) (Pdb) n > /home/xyz/python/x.py(3)() -> print "X" (Pdb) Pdb.__dict__['do_break'] (Pdb) break Iam crashing your HOME and deleting your FILES I think that this patch can't be accepted due to above reason.According to my advanced reaserch;) ( find Lib/ -name '*.py' -exec grep 'from __main__ import' {} -ls \; ) 'from __main__' is rare case so maybe it will be reasonable to simply handle ImportError and print something like '** 'from __main__ import' not supported' message.What do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1429539&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:08:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:08:06 -0700 Subject: [Patches] [ python-Patches-957650 ] Fix for bugs relating to ntpath.expanduser() Message-ID: Patches item #957650, was opened at 2004-05-20 20:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Josiah Carlson (josiahcarlson) >Assigned to: Georg Brandl (gbrandl) Summary: Fix for bugs relating to ntpath.expanduser() Initial Comment: Attached is a patch for sf bug #796219 that fixes ntpath.expanduser() for paths that embed other environment variables, and also includes functionality that mirrors *nix-style ~user\extra expansions. I will comment with output from both the unpatched and patched version of ntpath. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 22:08 Message: Logged In: YES user_id=849994 Originator: NO Thanks! Committed as rev. 54364. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-13 20:49 Message: Logged In: YES user_id=341410 Originator: YES I have just attached an updated patch (against trunk) for ntpath expandusers and expandvars that includes documentation and test updates. File Added: ntpath_full.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:41 Message: Logged In: YES user_id=849994 Originator: NO This fixes #796219. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 08:39 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good to me; documentation updates and new tests will be needed though. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-22 21:25 Message: Logged In: YES user_id=341410 I've just attached an updated version of the patch to handle expandusers (without recursive environment variable expansion), as well as a variant of http://python.org/sf/1574252 to handle %VAR% style expansions on Windows. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 10:46 Message: Logged In: YES user_id=6656 bugger, wrong report :-/ ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-15 10:45 Message: Logged In: YES user_id=6656 This looks much better to me! ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-06-15 01:11 Message: Logged In: YES user_id=341410 What problem is needed? Perhaps you mean "this solution is desireable". ---------------------------------------------------------------------- Comment By: alan johnson (chomo) Date: 2004-06-14 20:44 Message: Logged In: YES user_id=943591 this problem maybe is whats needed ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:38 Message: Logged In: YES user_id=341410 I uploaded the testing as text to alleviate text wrapping issues that could confuse. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2004-05-20 20:36 Message: Logged In: YES user_id=341410 #test setup: >>> import os >>> os.environ['TESTING'] = '%TESTING1%' >>> os.environ['TESTING1'] = '%TESTING2%' >>> os.environ['TESTING2'] = 'Final\\Path' #test standard ntpath >>> import ntpath >>> ntpath.expanduser('~') 'C:\\Documents and Settings\\jcarlson' >>> ntpath.expanduser('~billy') '~billy' >>> ntpath.expanduser('~billy\\bob') '~billy\\bob' >>> ntpath.expanduser('~\\bob') 'C:\\Documents and Settings\\jcarlson\\bob' >>> ntpath.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') '~billy\\%TESTING%\\%TESTING1%\\%TESTING2%' #test patched ntpath >>> import ntpath_patched >>> ntpath_patched.expanduser('~') 'C:Documents and Settings\\jcarlson' >>> ntpath_patched.expanduser('~billy') 'C:Documents and Settings\\billy' >>> ntpath_patched.expanduser('~billy\\bob') 'C:Documents and Settings\\billy\\bob' >>> ntpath_patched.expanduser('~\\bob') 'C:Documents and Settings\\jcarlson\\bob' >>> ntpath_patched.expanduser('~billy\\%TESTING%\\%TESTING1%\\%TESTING2%') 'C:Documents and Settings\\billy\\Final\\Path\\Final\\Path\\Final\\Path' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=957650&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:17:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:17:06 -0700 Subject: [Patches] [ python-Patches-1194449 ] pydoc requires o.__nonzero__() == True Message-ID: Patches item #1194449, was opened at 2005-05-03 13:18 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Ka-Ping Yee (ping) Summary: pydoc requires o.__nonzero__() == True Initial Comment: On Tue, 2005-05-03 at 07:44, Nadav Horesh wrote: >>> import numarray as N > >>> a = N.array((2.3, 4.3)) > >>> N.__version__ > '1.3.1' > >>> help(a.stddev) > > Traceback (most recent call last): > File "", line 1, in -toplevel- > help(a.stddev) > File "/usr/local/lib/python2.4/site.py", line 328, in __call__ > return pydoc.help(*args, **kwds) > File "/usr/local/lib/python2.4/pydoc.py", line 1647, in __call__ > self.help(request) > File "/usr/local/lib/python2.4/pydoc.py", line 1691, in help > else: doc(request, 'Help on %s:') > File "/usr/local/lib/python2.4/pydoc.py", line 1475, in doc > pager(title % desc + '\n\n' + text.document(object, name)) > File "/usr/local/lib/python2.4/pydoc.py", line 297, in document > if inspect.isroutine(object): return self.docroutine(*args) > File "/usr/local/lib/python2.4/pydoc.py", line 1226, in docroutine > if object.im_self: > File "/usr/local/lib/python2.4/site-packages/numarray/generic.py", > line 537, in __nonzero__ > raise RuntimeError("An array doesn't make sense as a truth value. > Use any(a) or all(a).") > RuntimeError: An array doesn't make sense as a truth value. Use any(a) > or all(a). > >>> help(a.sum) > > In my opinion, this is a limitation (bug is maybe too strong) of pydoc, in that pydoc's docroutine method requires that an object be evaluable as a truth value and that the result be True. I think that's a common, but wrong, idiom. I believe it's widely recognized that array's don't make much sense as truth values because it leads to code like this: >>> a = array(5); b = array(8) >>> a & b array(0) >>> if a & b: ... print "foo!" foo! Numeric expressions like the above implicitly mean any(a & b) and appear to work but really contain subtle bugs. Hence, in numarray and Numeric3 (now or eventually), the exception: >>> if a & b: ... print "foo!" ... Traceback (most recent call last): ... RuntimeError: An array doesn't make sense as a truth value. Use any(a) or all(a). I think the pydoc docroutine() code should be changed to read: if object.im_self is not None: and that particular limitation will be removed. I submitted a patch. Regards, Todd ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 22:17 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, fixed in rev. 54365, 54366 (2.5). ---------------------------------------------------------------------- Comment By: Jay T Miller (jaytmiller) Date: 2005-05-03 13:26 Message: Logged In: YES user_id=320512 The attached patch fixed my immediate problem but is untested against the Python test suites. I did not do a careful analysis for other uses of the "if o:" idiom but noted that there are many of which I'm fixing two. I only have anonymous access to Python CVS and it is unusable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1194449&group_id=5470 From noreply at sourceforge.net Tue Mar 13 23:50:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 15:50:51 -0700 Subject: [Patches] [ python-Patches-1185447 ] binascii.b2a_qp does not handle binary data correctly Message-ID: Patches item #1185447, was opened at 2005-04-18 21:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185447&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: binascii.b2a_qp does not handle binary data correctly Initial Comment: The binascii.b2a_qp function does not quote characters with ASCII values less than 32. Attached is a patch to fix this problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 22:50 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, used it in rev. 54367. Not backporting since this is a behavior change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1185447&group_id=5470 From noreply at sourceforge.net Wed Mar 14 00:05:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 16:05:30 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Wed Mar 14 02:25:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 18:25:05 -0700 Subject: [Patches] [ python-Patches-968063 ] Add fileinput.islastline() Message-ID: Patches item #968063, was opened at 2004-06-07 11:45 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Relm Arrowny (relm) Assigned to: Nobody/Anonymous (nobody) Summary: Add fileinput.islastline() Initial Comment: You can test for the first line of a file with fileinput.isfirstline(), but there is no corresponding fileinput.islastline() to test for the last line of a file. Note that there is already an unapplied patch for this at request ID 776100, but it is faulty in that it only tests for end of buffer and not end of file. I was not sure how to append this patch to the existing request, so have started a new one. Hope this is okay. This patch also includes documentation and test updates. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 02:25 Message: Logged In: YES user_id=51702 Originator: NO I have applied this patch and it works as specified. Although it does not apply cleanly and it contains an error; self._lastline = None should probably be in the __init__() method. Please reconsider this patch and see Relms attached wc program. It is definitely sensible and useful for fileinput to have a islastline method. In fact, every program that uses fileinput and wants to make a summary for each read file. ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2004-08-05 20:17 Message: Logged In: YES user_id=971153 An alternative to islastline() would be to add a single-line look-ahead capability: nextline() which would return a structure containing next line, and its file name (or have 2 functions nextline() and nextlinefile() ) This would cover most of the OP's needs but would also provide extra useful functionality....E.g. when processing files which have a header line [data line]* structure its very convenient to know in advance when section ends while processing the last line of section not when enountering the header line of the next section... Another use case would be processing of files with line groups: group1line1 group1line2 group1line3 group2line1 group2line2 (grouping could be for example on the value of a certian field in the line) again it would be very useful to know when a group ends while still processing this group ---------------------------------------------------------------------- Comment By: Dave Harrison (dharriso) Date: 2004-07-04 13:24 Message: Logged In: YES user_id=1076674 I would say that I'm -0.5 on this feature. After looking over the current code for fileinput.py in the cvs tree, it looks like the current code implements an iterator model. Since fileinput.py uses the next() call to move along its input, and raises StopIteration if there are no more lines to be returned, this function would have to be polled to find out if the final line had been reached - where a try/except block that caught StopIteration would seem more intuitive to me (Inkeeping with the current code). However it might be considered that the nextfile() function be changed to raise StopIteration after the last file had been completed to maintain consistency between the lines and files aspects of the class. ---------------------------------------------------------------------- Comment By: Relm Arrowny (relm) Date: 2004-06-15 20:42 Message: Logged In: YES user_id=1058331 The OP's use case was too simplified to convey the usefulness of fileinput.islastline(). It does not just save a couple of lines. I am attaching a "wc" or "word count" program to demonstrate. Note the following problems with the current work-around: 1. Instead of doing end-of-file processing at the end of a file, we must do it at the beginning of the *next* file. 2. Useful functions such as fileinput.filelineno() and fileinput.filename() now refer to the *wrong* file, so now we need to manually keep track of these values ourselves. 3. Perhaps a minor point, but this work-around only works at the *beginning* of the loop instead of the end. It feels somewhat awkward. 4. End-of-file processing must occur both in the loop and once outside. A function avoids code duplication, but to refer to variables in the loop, they must be passed into and out of the function (6 in, 2 out for the "wc" example... maybe keyword arguments would have helped). 5. Most important is readablility. It's not obvious that `fileinput.isfirstline() and fileinput.lineno() != 1` means we are the end of the (previous!) file. Using `fileinput.islastline()` would be much clearer. And not that it is a reason, but Perl and Ruby solve this with an `eof` function and `eof?` method, respectively. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-15 14:05 Message: Logged In: YES user_id=80475 I'm -0 on complicating this venerable interface. Also, I find it unnatural for the inside of a loop to be able to ascertain whether it is in its final iteration. The closest approximation is the for-else clause which is vary rarely used in normal python programming. While the OP was able to sketch a use case, it involved only saving a couple of lines over what can be done with the existing API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=968063&group_id=5470 From noreply at sourceforge.net Wed Mar 14 05:01:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 13 Mar 2007 21:01:44 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 03:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-13 21:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 10:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 09:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 05:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 09:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 05:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 05:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 10:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 10:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 05:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-30 16:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Wed Mar 14 08:00:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 00:00:59 -0700 Subject: [Patches] [ python-Patches-1411097 ] httplib patch to make _read_chunked() more robust Message-ID: Patches item #1411097, was opened at 2006-01-20 20:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: httplib patch to make _read_chunked() more robust Initial Comment: To reproduce: import urllib2 print urllib2.urlopen("http://66.117.37.13/").read() The attached patch "fixes" the hang, but that patch is not acceptable because it also removes the .readline() and .readlines() methods on the response object returned by urllib2.urlopen(). The patch seems to demonstrate that the problem is caused by the (ab)use of socket._fileobject in urllib2.AbstractHTTPHandler (I believe this hack was introduced when urllib2 switched to using httplib.HTTPConnection). Not sure yet what the actual problem is... ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 07:00 Message: Logged In: YES user_id=849994 Originator: NO Ping! ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-05-03 18:57 Message: Logged In: YES user_id=261020 I *hope* to get back to it soon. But if anybody beats me to it, that's fine :-) One problem: I don't understand the need for HTTPConnection._safe_read(), rather than checking for an EINTR resulting from the recv() call (or WSAEINTR on Windows). Can anybody explain that? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-03 05:17 Message: Logged In: YES user_id=849994 Are you still working on your slightly modified patch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 21:20 Message: Logged In: YES user_id=261020 Please ignore last comment (posted to wrong tracker item). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 21:18 Message: Logged In: YES user_id=261020 Conservative or not, I see no utility in changing the default, and several major harmful effects: old code breaks, and people have to pore over the specs to figure out why "urlopen() doesn't work". ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 20:36 Message: Logged In: YES user_id=261020 I missed the fact that, if the connection will not close at the end of the transaction, the behaviour should not change from what's currently in SVN (we should not assume that the chunked response has ended unless we see the proper terminating CRLF). I intend to upload a slightly modified patch that tests for self._will_close, and behaves accordingly. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:24 Message: Logged In: YES user_id=261020 Oops, fixed chunk.patch to .strip() before comparing to "". ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 00:38 Message: Logged In: YES user_id=261020 First, expanding a bit on what I wrote on 2006-01-21: The problem does relate to chunked encoding, and is unrelated to urllib2's use of _fileobject. My hack to remove use of socket._fileobject from urllib2 merely breaks handling of chunked encoding by cutting httplib.HTTPResponse out of the picture. The problem is seen in urllib2 in recent Pythons thanks to urllib2 switching to use of httplib.HTTPConnection and HTTP/1.1, hence chunked encoding is allowed. urllib still uses httplib.HTTP, hence HTTP/1.0, so is unaffected. To reproduce with httplib: import httplib conn = httplib.HTTPConnection("66.117.37.13") conn.request("GET", "/", headers={"Connection": "close"}) r1 = conn.getresponse() print r1.read() The Connection: close is required -- if it's not there the server doesn't use chunked transfer-encoding. I verified with a packet sniffer that the problem is that this server does not send the final trailing CRLF required by section 3.6.1 of RFC 2616. However, that section also says that trailers (trailing HTTP headers) MUST NOT be sent by the server unless either a TE header was present and indicated that trailers are acceptable (httplib does not send the TE header), or the trailers are optional metadata and may be discarded by the client. So, I propose the attached patch to httplib (chunk.patch) as a work-around. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-01-21 22:10 Message: Logged In: YES user_id=261020 In fact the commit message for rev 36871 states the real reason _fileobject is used (handling chunked encoding), showing my workaround is even more harmful than I thought. Moreover, doing a urlopen on 66.117.37.13 shows the response *is* chunked. The problem seems to be caused by httplib failing to find a CRLF at the end of the chunked response, so the loop at the end of _read_chunked() never terminates. Haven't looked in detail yet, but I'm guessing a) it's the server's fault and b) httplib should work around it. Here's the commit message from 36871: Fix urllib2.urlopen() handling of chunked content encoding. The change to use the newer httplib interface admitted the possibility that we'd get an HTTP/1.1 chunked response, but the code didn't handle it correctly. The raw socket object can't be pass to addinfourl(), because it would read the undecoded response. Instead, addinfourl() must call HTTPResponse.read(), which will handle the decoding. One extra wrinkle is that the HTTPReponse object can't be passed to addinfourl() either, because it doesn't implement readline() or readlines(). As a quick hack, use socket._fileobject(), which implements those methods on top of a read buffer. (suggested by mwh) Finally, add some tests based on test_urllibnet. Thanks to Andrew Sawyers for originally reporting the chunked problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411097&group_id=5470 From noreply at sourceforge.net Wed Mar 14 09:28:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 01:28:52 -0700 Subject: [Patches] [ python-Patches-1668132 ] Fix for 767111, 'AttributeError thrown by urllib.open_http' Message-ID: Patches item #1668132, was opened at 2007-02-25 00:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668132&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Atul Varma (varmaa) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 767111, 'AttributeError thrown by urllib.open_http' Initial Comment: This is a fix for bug 767111: http://sourceforge.net/tracker/index.php?func=detail&aid=767111&group_id=5470&atid=105470 I am also attaching a unit test that reliably reproduces the bug using an in-process web server. I didn't want to modify httplib because it would mean altering its interface such that the HTTP.getfile() method would never return None, and that could break existing code. So instead I modified urllib at a point that it appears to assume that HTTP.getfile() will always return a file object. I hope this is a reasonable place to fix the problem, and I don't think it can break any existing code. I also ran the existing "test/test_urllib.py" and "test/test_urllibnet.py" test suites and they both work fine with this patch. Looking at the code, I also believe that a "parallel bug" exists with urllib.open_https(), and I fixed that as well (though I don't have a unit test to prove this). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 08:28 Message: Logged In: YES user_id=849994 Originator: NO Fixed with a different patch in rev. 54376, 54377 (2.5). ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-06 07:34 Message: Logged In: YES user_id=1727609 Originator: NO Hi Atul, I took a quick look at your patch and verified that the test case produces an AttributeError on trunk. After manually patching urllib.py the test case passes. A few observations: 1. Your patch changes the code from giving an AttributeError to giving an empty file back when the remote webserver gives a bad http status line. The official Python documentation says that urlopen either generates an IOError when it can't connect to the server, or returns a file-like object when all goes well. In this case all didn't go well, so the documentation is incomplete. Would it be more appropriate to raise an exception rather than return an empty file? 2. I believe your test file will not work on systems without networking support. Other Python tests that require networking support have this at the top of them: test_support.requires('network') See Lib/test/test_socketserver.py for example. 3. Consider merging your test into Lib/test/test_urllib.py and supplying a patch against that file. 4. Could the test be performed without actually getting a network connection? Some of the tests in test_urllib.py use a FakeSocket class that might also work for your test. 5. Whitespace police - foo(arg1) instead of foo( arg1 ). See PEP 8 at http://www.python.org/dev/peps/pep-0008/ Other than that, things look good. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2007-02-25 00:56 Message: Logged In: YES user_id=863202 Originator: YES File Added: UrllibBug767111Tester.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1668132&group_id=5470 From noreply at sourceforge.net Wed Mar 14 10:36:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 02:36:16 -0700 Subject: [Patches] [ python-Patches-1680015 ] __slots__ tuple modified inplace if it contains unicode name Message-ID: Patches item #1680015, was opened at 2007-03-13 17:44 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) >Assigned to: ?iga Seilnacht (zseil) Summary: __slots__ tuple modified inplace if it contains unicode name Initial Comment: Function _unicode_to_string() in typeobject.c tries to copy the original tuple by asking for a complete slice of the original tuple. This case is special cased in tupleslice() to only incref the original tuple. As a consequence, the user's tuple could be modified (see the test). There are also some reference leaks if an unicode name can't be encoded with the default codec. The patch fixes this and adds tests for both cases. I also moved a comment about possible leaks to the appropriate place. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 18:57 Message: Logged In: YES user_id=849994 Originator: NO Perhaps moving the "leak" comment into the if block isn't such a good idea. Ah, and while you're at it, you could improve the variable names ("o" and "o1" is not very useful :) Otherwise the patch looks fine, I'd say you can apply it then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 From noreply at sourceforge.net Wed Mar 14 12:22:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 04:22:22 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 11:48 Message generated for change (Comment added) made by therve You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: TH (therve) Date: 2007-03-14 11:22 Message: Logged In: YES user_id=1038797 Originator: YES > Ziga, there are a lot of changes to the doc that appear to be whitespace > only. Could you review them from the patch before checkin? I guess you mean "remove them" ? > I see _PyString_Eq is used. It's possible that __slots__ contain unicode, > possibly other types (I didn't check). It seems __slots__ can be unicode, but only with ascii content. This behavior is a bit weird... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-14 04:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 17:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 16:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 13:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 17:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 13:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 18:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 18:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 13:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 00:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Wed Mar 14 13:38:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 05:38:15 -0700 Subject: [Patches] [ python-Patches-1680015 ] __slots__ tuple modified inplace if it contains unicode name Message-ID: Patches item #1680015, was opened at 2007-03-13 17:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: __slots__ tuple modified inplace if it contains unicode name Initial Comment: Function _unicode_to_string() in typeobject.c tries to copy the original tuple by asking for a complete slice of the original tuple. This case is special cased in tupleslice() to only incref the original tuple. As a consequence, the user's tuple could be modified (see the test). There are also some reference leaks if an unicode name can't be encoded with the default codec. The patch fixes this and adds tests for both cases. I also moved a comment about possible leaks to the appropriate place. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 13:38 Message: Logged In: YES user_id=1326842 Originator: YES I moved the comment back to its old place and renamed variables to "slot_name" and "new_name". Commited as revision 54378, 54379 (2.5). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 18:57 Message: Logged In: YES user_id=849994 Originator: NO Perhaps moving the "leak" comment into the if block isn't such a good idea. Ah, and while you're at it, you could improve the variable names ("o" and "o1" is not very useful :) Otherwise the patch looks fine, I'd say you can apply it then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680015&group_id=5470 From noreply at sourceforge.net Wed Mar 14 15:19:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 07:19:36 -0700 Subject: [Patches] [ python-Patches-1516309 ] Remove deprecated functions from operator Message-ID: Patches item #1516309, was opened at 2006-07-03 14:47 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove deprecated functions from operator Initial Comment: This patch removes the isCallable() and sequenceIncludes() functions from the operator module. These functions have been deprecated since Python 2.0. This patch is against r47214. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2007-03-14 15:19 Message: Logged In: YES user_id=34209 Originator: NO Please don't actually remove them until after 2.6 is out; the use of the functions should actually warn (with DeprecationWarning) for at least a release, and they don't warn currently. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:33 Message: Logged In: YES user_id=849994 Originator: NO I think you can safely commit this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 From noreply at sourceforge.net Wed Mar 14 15:24:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 07:24:27 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 12:48 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: TH (therve) Assigned to: Nobody/Anonymous (nobody) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 15:24 Message: Logged In: YES user_id=1326842 Originator: NO The ht_slots tuple can't contain unicode names; they are converted to strings in type_new(). type_new() also raises an error for any non string object found in __slots__. At the end of type_new(), ht_slots tuple can only contain valid identifiers minus __weakref__ and __dict__. I changed the patch to use PyObject_Compare() anyway, because it reduces the amount of code. I also removed whitespace changes in the docs, changed the tests as suggested and added a test with unicode slots. File Added: same_slots_added_5.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-14 12:22 Message: Logged In: YES user_id=1038797 Originator: YES > Ziga, there are a lot of changes to the doc that appear to be whitespace > only. Could you review them from the patch before checkin? I guess you mean "remove them" ? > I see _PyString_Eq is used. It's possible that __slots__ contain unicode, > possibly other types (I didn't check). It seems __slots__ can be unicode, but only with ascii content. This behavior is a bit weird... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-14 05:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 18:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 17:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 14:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 18:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 19:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 14:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Wed Mar 14 17:00:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 09:00:26 -0700 Subject: [Patches] [ python-Patches-1516309 ] Remove deprecated functions from operator Message-ID: Patches item #1516309, was opened at 2006-07-03 12:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove deprecated functions from operator Initial Comment: This patch removes the isCallable() and sequenceIncludes() functions from the operator module. These functions have been deprecated since Python 2.0. This patch is against r47214. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 16:00 Message: Logged In: YES user_id=849994 Originator: NO My bad, I had thought this patch to be for Python 3000. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-14 14:19 Message: Logged In: YES user_id=34209 Originator: NO Please don't actually remove them until after 2.6 is out; the use of the functions should actually warn (with DeprecationWarning) for at least a release, and they don't warn currently. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:33 Message: Logged In: YES user_id=849994 Originator: NO I think you can safely commit this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 From noreply at sourceforge.net Wed Mar 14 17:52:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 09:52:11 -0700 Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault in object_reduce_ex Message-ID: Patches item #1462488, was opened at 2006-04-01 02:30 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: Patch for bug #931877 Segfault in object_reduce_ex Initial Comment: This prevents unbounded recursion in typeobject.c's object_reduce_ex(). It does so by splitting implementation for object.__reduce_ex__ and object.__reduce__ into two different C functions. See the apended file details.txt for more detailed explanation. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 17:52 Message: Logged In: YES user_id=1326842 Originator: YES I would like to backport this patch to the 2.5 branch so I made a new wersion that is fully backwards compatible (well, except for the segfault :). Georg, could you please take another look? And thanks for all the reviews, I can hardly keep up :). File Added: typeobject_reduce_2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:17 Message: Logged In: YES user_id=849994 Originator: NO I think this patch is fine, but you should include at least some of the detailed description as a comment for the new reduce method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 From noreply at sourceforge.net Wed Mar 14 20:48:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 12:48:12 -0700 Subject: [Patches] [ python-Patches-1680959 ] Add tests for pipes module (test_pipes) Message-ID: Patches item #1680959, was opened at 2007-03-14 14:48 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=1680959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Add tests for pipes module (test_pipes) Initial Comment: The attached file contains a patch to: - remove the "just import it" test for pipes from test_sundry.py - add test_pipes to expected skips on win32 in regrtest.py - remove the "small test program and example" from pipes.py (it seems to me this is best put in either tests or docs instead of the module itself) It also includes a new test_pipes.py module. At the moment this covers about 86% of the pipes.py code; I'll try to get that higher, but I wanted to throw this out there for initial feedback. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 From noreply at sourceforge.net Wed Mar 14 20:50:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 12:50:22 -0700 Subject: [Patches] [ python-Patches-1559298 ] test_popen fails on Windows if installed to "Program Files" Message-ID: Patches item #1559298, was opened at 2006-09-15 14:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: test_popen fails on Windows if installed to "Program Files" Initial Comment: test_popen fails in 2.5c2. The reason is that popen invokes cmd.exe /c "c:\program files\python25\python.exe" -c "import sys;print sys.argv" cmd.exe does not support that syntax, and gives an error (which silently disappears); the pipe read then returns an empty string. This problem exists atleast since Python 2.3. To fix this, cmd.exe needs to be invoked as cmd.exe /c "c:\program files\python25\python.exe" -c "import sys;print sys.argv" The attached patch fixes this by always wrapping the command line with an addition pair of quotes. It's not clear to me whether this can go into 2.5.1: an application may already work around this problem by passing extra quotes to popen, which would then break if popen adds even more quotes. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-14 20:50 Message: Logged In: YES user_id=21627 Originator: YES Indeed, this should read cmd.exe /c ""c:\program files\python25\python.exe" -c "import sys;print sys.argv"" ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 10:39 Message: Logged In: YES user_id=849994 Originator: NO I don't see a difference between your two command lines here... did you mean to add additional quotes in the second example? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559298&group_id=5470 From noreply at sourceforge.net Wed Mar 14 20:51:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 12:51:11 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 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=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Wed Mar 14 20:51:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 12:51:45 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 14:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Later Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 19:51 Message: Logged In: YES user_id=849994 Originator: NO See #1680961 for an atexit rewrite. In any case, I think we can close this. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:54 Message: Logged In: YES user_id=849994 Originator: NO Then let's come up with a patch and sneak it in while Guido isn't watching ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-13 20:51 Message: Logged In: YES user_id=1344176 Originator: YES Me, either. I'd prefer to reimplement atexit in C and make use of something like the Py_AtExit-related functionality in pythonrun.c. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:47 Message: Logged In: YES user_id=849994 Originator: NO Hm, that doesn't make me too happy. Why do we need exitfunc at all if we have atexit? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-13 20:30 Message: Logged In: YES user_id=1344176 Originator: YES Guido suggested renaming sys.exitfunc to sys._exitfunc: http://mail.python.org/pipermail/python-3000/2007-March/006100.html ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:26 Message: Logged In: YES user_id=849994 Originator: NO How is the atexit module to work after this patch? (It could be reimplemented in C and reuse the old exitfunc functionality.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:05:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:05:10 -0700 Subject: [Patches] [ python-Patches-1559413 ] test_cmd_line fails on Windows Message-ID: Patches item #1559413, was opened at 2006-09-15 17:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559413&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin v. L?wis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: test_cmd_line fails on Windows Initial Comment: test_cmd_line fails in 2.5c2 if Python is installed into a directory with spaces in its name. This is a shallow problem, and can be fixe with attached patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-14 21:05 Message: Logged In: YES user_id=21627 Originator: YES You are right. Committed as r54386 and r54387 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 10:36 Message: Logged In: YES user_id=849994 Originator: NO Wouldn't the quotes work for non-Windows platforms too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1559413&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:08:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:08:36 -0700 Subject: [Patches] [ python-Patches-1516309 ] Remove deprecated functions from operator Message-ID: Patches item #1516309, was opened at 2006-07-03 08:47 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Later Priority: 5 Private: No Submitted By: Collin Winter (collinwinter) Assigned to: Collin Winter (collinwinter) Summary: Remove deprecated functions from operator Initial Comment: This patch removes the isCallable() and sequenceIncludes() functions from the operator module. These functions have been deprecated since Python 2.0. This patch is against r47214. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-14 16:08 Message: Logged In: YES user_id=1344176 Originator: YES I'll go ahead and add deprecation warnings for 2.6 and remove them in 3.0. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 12:00 Message: Logged In: YES user_id=849994 Originator: NO My bad, I had thought this patch to be for Python 3000. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-14 10:19 Message: Logged In: YES user_id=34209 Originator: NO Please don't actually remove them until after 2.6 is out; the use of the functions should actually warn (with DeprecationWarning) for at least a release, and they don't warn currently. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 16:33 Message: Logged In: YES user_id=849994 Originator: NO I think you can safely commit this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:09:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:09:07 -0700 Subject: [Patches] [ python-Patches-1680959 ] Add tests for pipes module (test_pipes) Message-ID: Patches item #1680959, was opened at 2007-03-14 15:48 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) >Assigned to: Collin Winter (collinwinter) Summary: Add tests for pipes module (test_pipes) Initial Comment: The attached file contains a patch to: - remove the "just import it" test for pipes from test_sundry.py - add test_pipes to expected skips on win32 in regrtest.py - remove the "small test program and example" from pipes.py (it seems to me this is best put in either tests or docs instead of the module itself) It also includes a new test_pipes.py module. At the moment this covers about 86% of the pipes.py code; I'll try to get that higher, but I wanted to throw this out there for initial feedback. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:21:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:21:27 -0700 Subject: [Patches] [ python-Patches-1680978 ] Use "alive" instead of "active" in the docs for threading Message-ID: Patches item #1680978, was opened at 2007-03-14 21: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=1680978&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Use "alive" instead of "active" in the docs for threading Initial Comment: The documentation for the threading module uses the words "alive" and "active" interchangeably for describing a thread whose start() method has been called, but whose run() method has not finished. This patch intends to make the docs a little clearer by only using the "alive" word. The patch fixes Bug #912943 and is supposed to obsolete Patch #1107656 (which changes "alive" -> "active" and deprecates Thread.isAlive()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680978&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:38:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:38:27 -0700 Subject: [Patches] [ python-Patches-1411097 ] httplib patch to make _read_chunked() more robust Message-ID: Patches item #1411097, was opened at 2006-01-20 20:26 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411097&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: httplib patch to make _read_chunked() more robust Initial Comment: To reproduce: import urllib2 print urllib2.urlopen("http://66.117.37.13/").read() The attached patch "fixes" the hang, but that patch is not acceptable because it also removes the .readline() and .readlines() methods on the response object returned by urllib2.urlopen(). The patch seems to demonstrate that the problem is caused by the (ab)use of socket._fileobject in urllib2.AbstractHTTPHandler (I believe this hack was introduced when urllib2 switched to using httplib.HTTPConnection). Not sure yet what the actual problem is... ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2007-03-14 20:38 Message: Logged In: YES user_id=261020 Originator: YES Haven't forgotten, just haven't done it... I never did figure out what should be done re EINTR. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 07:00 Message: Logged In: YES user_id=849994 Originator: NO Ping! ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-05-03 19:57 Message: Logged In: YES user_id=261020 I *hope* to get back to it soon. But if anybody beats me to it, that's fine :-) One problem: I don't understand the need for HTTPConnection._safe_read(), rather than checking for an EINTR resulting from the recv() call (or WSAEINTR on Windows). Can anybody explain that? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-03 06:17 Message: Logged In: YES user_id=849994 Are you still working on your slightly modified patch? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 21:20 Message: Logged In: YES user_id=261020 Please ignore last comment (posted to wrong tracker item). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 21:18 Message: Logged In: YES user_id=261020 Conservative or not, I see no utility in changing the default, and several major harmful effects: old code breaks, and people have to pore over the specs to figure out why "urlopen() doesn't work". ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 20:36 Message: Logged In: YES user_id=261020 I missed the fact that, if the connection will not close at the end of the transaction, the behaviour should not change from what's currently in SVN (we should not assume that the chunked response has ended unless we see the proper terminating CRLF). I intend to upload a slightly modified patch that tests for self._will_close, and behaves accordingly. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 01:24 Message: Logged In: YES user_id=261020 Oops, fixed chunk.patch to .strip() before comparing to "". ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-02-06 00:38 Message: Logged In: YES user_id=261020 First, expanding a bit on what I wrote on 2006-01-21: The problem does relate to chunked encoding, and is unrelated to urllib2's use of _fileobject. My hack to remove use of socket._fileobject from urllib2 merely breaks handling of chunked encoding by cutting httplib.HTTPResponse out of the picture. The problem is seen in urllib2 in recent Pythons thanks to urllib2 switching to use of httplib.HTTPConnection and HTTP/1.1, hence chunked encoding is allowed. urllib still uses httplib.HTTP, hence HTTP/1.0, so is unaffected. To reproduce with httplib: import httplib conn = httplib.HTTPConnection("66.117.37.13") conn.request("GET", "/", headers={"Connection": "close"}) r1 = conn.getresponse() print r1.read() The Connection: close is required -- if it's not there the server doesn't use chunked transfer-encoding. I verified with a packet sniffer that the problem is that this server does not send the final trailing CRLF required by section 3.6.1 of RFC 2616. However, that section also says that trailers (trailing HTTP headers) MUST NOT be sent by the server unless either a TE header was present and indicated that trailers are acceptable (httplib does not send the TE header), or the trailers are optional metadata and may be discarded by the client. So, I propose the attached patch to httplib (chunk.patch) as a work-around. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-01-21 22:10 Message: Logged In: YES user_id=261020 In fact the commit message for rev 36871 states the real reason _fileobject is used (handling chunked encoding), showing my workaround is even more harmful than I thought. Moreover, doing a urlopen on 66.117.37.13 shows the response *is* chunked. The problem seems to be caused by httplib failing to find a CRLF at the end of the chunked response, so the loop at the end of _read_chunked() never terminates. Haven't looked in detail yet, but I'm guessing a) it's the server's fault and b) httplib should work around it. Here's the commit message from 36871: Fix urllib2.urlopen() handling of chunked content encoding. The change to use the newer httplib interface admitted the possibility that we'd get an HTTP/1.1 chunked response, but the code didn't handle it correctly. The raw socket object can't be pass to addinfourl(), because it would read the undecoded response. Instead, addinfourl() must call HTTPResponse.read(), which will handle the decoding. One extra wrinkle is that the HTTPReponse object can't be passed to addinfourl() either, because it doesn't implement readline() or readlines(). As a quick hack, use socket._fileobject(), which implements those methods on top of a read buffer. (suggested by mwh) Finally, add some tests based on test_urllibnet. Thanks to Andrew Sawyers for originally reporting the chunked problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1411097&group_id=5470 From noreply at sourceforge.net Wed Mar 14 21:55:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 13:55:15 -0700 Subject: [Patches] [ python-Patches-1681002 ] binary and new-style octal literals Message-ID: Patches item #1681002, was opened at 2007-03-14 21:55 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=1681002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Guido van Rossum (gvanrossum) Summary: binary and new-style octal literals Initial Comment: Incomplete patch that adds '0t777' and '0b101010' style literals. It lacks a NEWS item, documentation and compiler-package changes (although it may not need any.) 2to3 recipe also not included. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681002&group_id=5470 From noreply at sourceforge.net Wed Mar 14 22:06:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 14:06:00 -0700 Subject: [Patches] [ python-Patches-1681002 ] binary and new-style octal literals Message-ID: Patches item #1681002, was opened at 2007-03-14 21:55 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Guido van Rossum (gvanrossum) Summary: binary and new-style octal literals Initial Comment: Incomplete patch that adds '0t777' and '0b101010' style literals. It lacks a NEWS item, documentation and compiler-package changes (although it may not need any.) 2to3 recipe also not included. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2007-03-14 22:06 Message: Logged In: YES user_id=34209 Originator: YES The compiler package does indeed not need any changes, as it still uses Python's own tokenizer. And in case there's any doubt, I'm still -1 on this change :) (But unfortunately the easy implementation of it didn't exactly give me new ammo.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681002&group_id=5470 From noreply at sourceforge.net Wed Mar 14 22:22:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 14:22:41 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 21:43 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- >Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-14 22:22 Message: Logged In: YES user_id=376953 Originator: YES I think the best way to solve this would be to use the subprocess module, as amk suggested. I included a new patch which for CGIHTTPServer which uses subprocess. Unfortunately this does not work ion Windows due to a problem with subprocess: On Windows passing the request.rfile (a _fileobject wrapper arround the socket) as stdin/out lead to an error. I'll file a bugreport on that case. Beside of this, the patch should solve the problem in a platform-independent way. File Added: CGIHTTPServer.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:36 Message: Logged In: YES user_id=849994 Originator: NO Note that commands.mkarg() is written for UNIX shells. While it may work with spaces in the file name, it may produce illegal Windows command line commands in other cases. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 19:54 Message: Logged In: YES user_id=11375 Would it simplify matters if CGIHTTPServer used the subprocess module, which tries to provide a platform-independent interface? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From noreply at sourceforge.net Wed Mar 14 22:30:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 14:30:40 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 14:51 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 16:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Wed Mar 14 23:30:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 15:30:03 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Wed Mar 14 23:43:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 15:43:22 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Thu Mar 15 00:08:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 16:08:31 -0700 Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault in object_reduce_ex Message-ID: Patches item #1462488, was opened at 2006-04-01 00:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: Patch for bug #931877 Segfault in object_reduce_ex Initial Comment: This prevents unbounded recursion in typeobject.c's object_reduce_ex(). It does so by splitting implementation for object.__reduce_ex__ and object.__reduce__ into two different C functions. See the apended file details.txt for more detailed explanation. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 23:08 Message: Logged In: YES user_id=849994 Originator: NO Looks good to me -- as you say, there shouldn't be any behavioral differences. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 16:52 Message: Logged In: YES user_id=1326842 Originator: YES I would like to backport this patch to the 2.5 branch so I made a new wersion that is fully backwards compatible (well, except for the segfault :). Georg, could you please take another look? And thanks for all the reviews, I can hardly keep up :). File Added: typeobject_reduce_2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:17 Message: Logged In: YES user_id=849994 Originator: NO I think this patch is fine, but you should include at least some of the detailed description as a comment for the new reduce method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 From noreply at sourceforge.net Thu Mar 15 00:54:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 16:54:50 -0700 Subject: [Patches] [ python-Patches-1375011 ] Improper handling of duplicate cookies Message-ID: Patches item #1375011, was opened at 2005-12-07 04:50 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375011&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Viraj Alankar (valankar) Assigned to: Nobody/Anonymous (nobody) Summary: Improper handling of duplicate cookies Initial Comment: This patch implements part of bug 1372650. Sometimes a web client will send 2 instances of the same name: Cookie: mycookie=foo; mycookie=bar The specs listed here: http://wp.netscape.com/newsref/std/cookie_spec.html state that the first one is the one that should be used. The other cookies listed are the inherited ones from paths that a prefix of the current URL. When this is parsed by the Cookie module, mycookie gets set to bar when it should be foo. This patch changes Cookie.py to only use the first instance of duplicate cookies when parsing cookie strings. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-15 00:54 Message: Logged In: YES user_id=51702 Originator: NO That link is misleading and just confuses you. :) Instead read John J. Lee's great explanation at the referenced bug report. I have tested the patch and it works as expected. Without the patch: >>> c = SimpleCookie('foo=33;foo=34') >>> print c Set-Cookie: foo=34 With the patch: >>> c = SimpleCookie('foo=33;foo=34') >>> print c Set-Cookie: foo=33 There should be a unit test though and something in the documentation. The keys dict should be a set instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1375011&group_id=5470 From noreply at sourceforge.net Thu Mar 15 01:09:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 17:09:45 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 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=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Thu Mar 15 04:03:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 20:03:57 -0700 Subject: [Patches] [ python-Patches-1621421 ] normalize namespace from minidom Message-ID: Patches item #1621421, was opened at 2006-12-23 15:01 Message generated for change (Comment added) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1621421&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Pacheco (paulpach) Assigned to: Nobody/Anonymous (nobody) Summary: normalize namespace from minidom Initial Comment: This is a patch that fixes bug 1371937, along with a test case that reproduces the original problem. The patch is a port of the algorithm described here pretty much verbatim: http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html#normalizeDocumentAlgo to resolve namespace declarations. The patch also calls the normalizeNamespace method before calling writexml Note the patch is against minidom that comes with python 2.5, NOT WITH PYXML. I need this for an embedded project where pyxml is too big. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-14 23:03 Message: Logged In: YES user_id=18139 Originator: NO Thanks for the patch. I think this is probably *not* desirable in this form. As a side effect of writexml(), this fixes up tagNames and attributes of elements in the document. DOM Level 3 Load and Save made the opposite decision: "The XML data is written to a string or an output stream. Any changes or fixups made during the serialization affect only the serialized data. The Document object and its children are never altered by the serialization operation." -- http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/load-save.html#LS-LSSerializer (first paragraph) I think that is the right approach. The new method Element.normalizeNamespace() isn't really a DOM method, though the appendix sort of makes it look that way. Incomplete - no doc patch. (I think there's also a bug in the line added to Document.writexml()-- can't Documents have children that aren't Elements?) ---------------------------------------------------------------------- Comment By: Paul Pacheco (paulpach) Date: 2006-12-24 10:32 Message: Logged In: YES user_id=794762 Originator: YES File Added: test_toxml.py ---------------------------------------------------------------------- Comment By: Paul Pacheco (paulpach) Date: 2006-12-24 10:29 Message: Logged In: YES user_id=794762 Originator: YES File Added: normalizeNamespace.diff ---------------------------------------------------------------------- Comment By: Paul Pacheco (paulpach) Date: 2006-12-23 15:02 Message: Logged In: YES user_id=794762 Originator: YES File Added: normalizeNamespace.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1621421&group_id=5470 From noreply at sourceforge.net Thu Mar 15 05:05:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 21:05:30 -0700 Subject: [Patches] [ python-Patches-1681153 ] Patch for [ 1603150 ] wave module forgets to close... Message-ID: Patches item #1681153, was opened at 2007-03-15 00:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681153&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patricio Olivares (polivare) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 1603150 ] wave module forgets to close... Initial Comment: Pretty straightforward patch for bug """[ 1603150 ] wave module forgets to close file on exception""" If the file is opened by wave.open and an error ocurrs in there, then close the file and re-raise the exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681153&group_id=5470 From noreply at sourceforge.net Thu Mar 15 06:42:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 22:42:55 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 03:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: TH (therve) >Assigned to: ?iga Seilnacht (zseil) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-14 22:42 Message: Logged In: YES user_id=33168 Originator: NO Sorry about the typo, I did mean remove, not review. The latest patch looks good. I have some questions though. What would happen if an exception is raised when comparing slots? I think it will be ok, the exception would get overwritten with the one about incompatible types/__slots__. I just want to be safe and it might be good to at least test this manually. Is the original object saved in ht_slots or is it always a tuple? If the original object is used, what if you have two classes with the same slots, but one uses a list and the other uses a tuple for __slots__? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 07:24 Message: Logged In: YES user_id=1326842 Originator: NO The ht_slots tuple can't contain unicode names; they are converted to strings in type_new(). type_new() also raises an error for any non string object found in __slots__. At the end of type_new(), ht_slots tuple can only contain valid identifiers minus __weakref__ and __dict__. I changed the patch to use PyObject_Compare() anyway, because it reduces the amount of code. I also removed whitespace changes in the docs, changed the tests as suggested and added a test with unicode slots. File Added: same_slots_added_5.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-14 04:22 Message: Logged In: YES user_id=1038797 Originator: YES > Ziga, there are a lot of changes to the doc that appear to be whitespace > only. Could you review them from the patch before checkin? I guess you mean "remove them" ? > I see _PyString_Eq is used. It's possible that __slots__ contain unicode, > possibly other types (I didn't check). It seems __slots__ can be unicode, but only with ascii content. This behavior is a bit weird... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-13 21:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 10:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 09:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 05:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 09:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 05:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 05:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 10:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 10:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 05:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-30 16:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Thu Mar 15 07:11:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 14 Mar 2007 23:11:16 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 08:28:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 00:28:43 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 08:38:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 00:38:31 -0700 Subject: [Patches] [ python-Patches-1680978 ] Use "alive" instead of "active" in the docs for threading Message-ID: Patches item #1680978, was opened at 2007-03-14 20:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680978&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Use "alive" instead of "active" in the docs for threading Initial Comment: The documentation for the threading module uses the words "alive" and "active" interchangeably for describing a thread whose start() method has been called, but whose run() method has not finished. This patch intends to make the docs a little clearer by only using the "alive" word. The patch fixes Bug #912943 and is supposed to obsolete Patch #1107656 (which changes "alive" -> "active" and deprecates Thread.isAlive()). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:38 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed in rev. 54392, 54393 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680978&group_id=5470 From noreply at sourceforge.net Thu Mar 15 08:43:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 00:43:54 -0700 Subject: [Patches] [ python-Patches-1681153 ] Patch for [ 1603150 ] wave module forgets to close... Message-ID: Patches item #1681153, was opened at 2007-03-15 04:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681153&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Patricio Olivares (polivare) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for [ 1603150 ] wave module forgets to close... Initial Comment: Pretty straightforward patch for bug """[ 1603150 ] wave module forgets to close file on exception""" If the file is opened by wave.open and an error ocurrs in there, then close the file and re-raise the exception. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:43 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed as rev. 54394, 54396 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681153&group_id=5470 From noreply at sourceforge.net Thu Mar 15 08:48:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 00:48:39 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 19:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:48 Message: Logged In: YES user_id=849994 Originator: NO Which error is that? Is it perhaps this: http://python.org/sf/1124861 ? ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-14 21:22 Message: Logged In: YES user_id=376953 Originator: YES I think the best way to solve this would be to use the subprocess module, as amk suggested. I included a new patch which for CGIHTTPServer which uses subprocess. Unfortunately this does not work ion Windows due to a problem with subprocess: On Windows passing the request.rfile (a _fileobject wrapper arround the socket) as stdin/out lead to an error. I'll file a bugreport on that case. Beside of this, the patch should solve the problem in a platform-independent way. File Added: CGIHTTPServer.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 19:36 Message: Logged In: YES user_id=849994 Originator: NO Note that commands.mkarg() is written for UNIX shells. While it may work with spaces in the file name, it may produce illegal Windows command line commands in other cases. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 17:54 Message: Logged In: YES user_id=11375 Would it simplify matters if CGIHTTPServer used the subprocess module, which tries to provide a platform-independent interface? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From richard_kaihara at comcast.net Thu Mar 15 09:11:48 2007 From: richard_kaihara at comcast.net (richard_kaihara at comcast.net) Date: Thu, 15 Mar 2007 08:11:48 +0000 Subject: [Patches] mailing list Message-ID: <031520070811.27460.45F8FFC4000A743500006B4422058864420E9D0E08070E05A10B9D0E080C079D@comcast.net> Please remove me from your mailing list. thanks, rich kaihara 415-519-1396 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20070315/da6a6587/attachment.htm From noreply at sourceforge.net Thu Mar 15 10:05:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 02:05:36 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 21:43 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- >Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 10:05 Message: Logged In: YES user_id=376953 Originator: YES No, the error it's related to http://python.org/sf/1175984 (and maybe http://python.org/sf/1260171). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 08:48 Message: Logged In: YES user_id=849994 Originator: NO Which error is that? Is it perhaps this: http://python.org/sf/1124861 ? ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-14 22:22 Message: Logged In: YES user_id=376953 Originator: YES I think the best way to solve this would be to use the subprocess module, as amk suggested. I included a new patch which for CGIHTTPServer which uses subprocess. Unfortunately this does not work ion Windows due to a problem with subprocess: On Windows passing the request.rfile (a _fileobject wrapper arround the socket) as stdin/out lead to an error. I'll file a bugreport on that case. Beside of this, the patch should solve the problem in a platform-independent way. File Added: CGIHTTPServer.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:36 Message: Logged In: YES user_id=849994 Originator: NO Note that commands.mkarg() is written for UNIX shells. While it may work with spaces in the file name, it may produce illegal Windows command line commands in other cases. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 19:54 Message: Logged In: YES user_id=11375 Would it simplify matters if CGIHTTPServer used the subprocess module, which tries to provide a platform-independent interface? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From noreply at sourceforge.net Thu Mar 15 10:58:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 02:58:01 -0700 Subject: [Patches] [ python-Patches-1680978 ] Use "alive" instead of "active" in the docs for threading Message-ID: Patches item #1680978, was opened at 2007-03-14 21:21 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680978&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Use "alive" instead of "active" in the docs for threading Initial Comment: The documentation for the threading module uses the words "alive" and "active" interchangeably for describing a thread whose start() method has been called, but whose run() method has not finished. This patch intends to make the docs a little clearer by only using the "alive" word. The patch fixes Bug #912943 and is supposed to obsolete Patch #1107656 (which changes "alive" -> "active" and deprecates Thread.isAlive()). ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-15 10:58 Message: Logged In: YES user_id=51702 Originator: YES Thansk. Don't forget to close Patch #1107656. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 08:38 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed in rev. 54392, 54393 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680978&group_id=5470 From noreply at sourceforge.net Thu Mar 15 12:13:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 04:13:52 -0700 Subject: [Patches] [ python-Patches-1681333 ] email.header unicode fix Message-ID: Patches item #1681333, was opened at 2007-03-15 11:13 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=1681333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: email.header unicode fix Initial Comment: email.header.Header class has its unicode representation which is slightly different from str representation. >>> h = email.Header.make_header((('[XXX]', 'us-ascii'), ('Re:', 'us-ascii'))) >>> unicode(h) u'[XXX]Re:' >>> str(h) '[XXX] Re:' Note that a white space between ']' and 'R' is absent from unicode representation. A word-separating space should be needed in following contexts: lastcs \ nextcs | ascii | other | ascii | sp | sp | other | sp | nosp | Current code fails to put a space for ascii\ascii case. Also, if the ascii string has a trailing space, it may result in a extraneous double space which has semantically equivalent to a single space and sometimes annoying. You should use qp encoding for ascii charset if you insist on the presence of the space. The patch includes test code. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681333&group_id=5470 From noreply at sourceforge.net Thu Mar 15 12:15:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 04:15:26 -0700 Subject: [Patches] [ python-Patches-1681333 ] email.header unicode fix Message-ID: Patches item #1681333, was opened at 2007-03-15 11:13 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.header unicode fix Initial Comment: email.header.Header class has its unicode representation which is slightly different from str representation. >>> h = email.Header.make_header((('[XXX]', 'us-ascii'), ('Re:', 'us-ascii'))) >>> unicode(h) u'[XXX]Re:' >>> str(h) '[XXX] Re:' Note that a white space between ']' and 'R' is absent from unicode representation. A word-separating space should be needed in following contexts: lastcs \ nextcs | ascii | other | ascii | sp | sp | other | sp | nosp | Current code fails to put a space for ascii\ascii case. Also, if the ascii string has a trailing space, it may result in a extraneous double space which has semantically equivalent to a single space and sometimes annoying. You should use qp encoding for ascii charset if you insist on the presence of the space. The patch includes test code. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681333&group_id=5470 From noreply at sourceforge.net Thu Mar 15 12:51:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 04:51:30 -0700 Subject: [Patches] [ python-Patches-1462488 ] Patch for bug #931877 Segfault in object_reduce_ex Message-ID: Patches item #1462488, was opened at 2006-04-01 02:30 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: Patch for bug #931877 Segfault in object_reduce_ex Initial Comment: This prevents unbounded recursion in typeobject.c's object_reduce_ex(). It does so by splitting implementation for object.__reduce_ex__ and object.__reduce__ into two different C functions. See the apended file details.txt for more detailed explanation. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-15 12:51 Message: Logged In: YES user_id=1326842 Originator: YES Commited as revision 54397, 54398 (2.5). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 00:08 Message: Logged In: YES user_id=849994 Originator: NO Looks good to me -- as you say, there shouldn't be any behavioral differences. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 17:52 Message: Logged In: YES user_id=1326842 Originator: YES I would like to backport this patch to the 2.5 branch so I made a new wersion that is fully backwards compatible (well, except for the segfault :). Georg, could you please take another look? And thanks for all the reviews, I can hardly keep up :). File Added: typeobject_reduce_2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:17 Message: Logged In: YES user_id=849994 Originator: NO I think this patch is fine, but you should include at least some of the detailed description as a comment for the new reduce method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1462488&group_id=5470 From noreply at sourceforge.net Thu Mar 15 14:09:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 06:09:50 -0700 Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to random Message-ID: Patches item #1681432, was opened at 2007-03-15 14:09 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=1681432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wladmir (miathan6) Assigned to: Nobody/Anonymous (nobody) Summary: Add triangular distribution to random Initial Comment: This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly. http://en.wikipedia.org/wiki/Triangular_distribution ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 From noreply at sourceforge.net Thu Mar 15 16:16:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 08:16:47 -0700 Subject: [Patches] [ python-Patches-914340 ] gzip.GzipFile to accept stream as fileobj. Message-ID: Patches item #914340, was opened at 2004-03-11 19:45 Message generated for change (Comment added) made by lucas_malor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Igor Belyi (belyi) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile to accept stream as fileobj. Initial Comment: When gzip.GzipFile is initialized with a fileobj which does not have tell() and seek() methods (non-rewinding stream) it throws exception. The interesting thing is that it doesn't have to. The following patch updates gzip.py to allow any stream with just a read() method to be used. This is helpful if you want to be able to do something like: gzip.GzipFile(fileobj=urllib.urlopen("file:///README.gz")).readlines() or use GzipFile with sys.stdin stream. But keep in mind that seek() and rewind() methond of the GzipFile() won't for such stream even with the patch. Igor ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 16:16 Message: Logged In: YES user_id=1403274 Originator: NO There's a problem with this path. If previously in my code I read some bytes of the the GzipFile object, _read_gzip_header returns IOError, 'Not a gzipped file', because it starts to read at the current position, not at the start. Unluckily seek() could not be used for urllib objects. I don't see any possible workaround. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:59 Message: Logged In: YES user_id=849994 Originator: NO It looks like Patch #1675951 provides the same feature, plus speedups. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 15:51 Message: Logged In: YES user_id=21627 Originator: NO The patch in this form is incomplete: it lacks test suite changes. Can somebody please provide patches to Lib/test/test_gzip.py that exercises this new functionality? ---------------------------------------------------------------------- Comment By: Jakob Truelsen (antialize) Date: 2006-06-19 10:35 Message: Logged In: YES user_id=379876 Is there any reson this patch is not accepted? If this patch is accepted then I have a patch to urlib2 to (automaticaly) accept gzipped content as described here http://www.http-compression.com/#client_request, if there is some reson this patch is not acceptable please detail, so it can be fixed, in tired of using popen and gunzip :) ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 15:14 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-19 05:27 Message: Logged In: YES user_id=995711 I thought I need to add a little bit more verbose explanation for the changes... Current implementation of GzipFile() uses tell() and seek() to scroll stream of data in the following 2 cases: 1. When EOF is reached and the last 8 bytes of the file contain checksum and uncompress data size 2. When after decompression there's left some 'unused_data' meaning that a stream may contains more than one compressed item. What my change does it introduces 2 helper buffers: 'inputbuf' which keeps read but unused data from the stream and 'last8' which keeps last 8 'used' bytes Plus, my change introduces helper method _read_internal() which is used instead of the direct call to self.fileobj.read(). In this method data from the stream are read as needed with the call to self.fileobj.read() and correct values of 'inputbuf' and ''last8' are maintained. When case 1 above happen we use 'last8' buffer to read checksum and size. When case 2 above happen we add value of the 'unused_data' to inputbuf. There's one more instance of the self.fileobj.seek() call left in rewind() method but it is used only when rewind() or seek() methods of GzipFile class are used. And it won't be logical to expect those methods to work if the underlying fileobj does not support them. Igor ---------------------------------------------------------------------- Comment By: Igor Belyi (belyi) Date: 2004-03-11 21:04 Message: Logged In: YES user_id=995711 Previous revision of the patch does not work correctly with mutliple compressed members in one stream. I've updated the patch file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914340&group_id=5470 From noreply at sourceforge.net Thu Mar 15 17:42:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 09:42:59 -0700 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by lucas_malor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 17:42 Message: Logged In: YES user_id=1403274 Originator: NO Excuse me, but I can't apply the patch. I have Windows XP without any SP and I tried to do the command patch -u gzip.py gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Thu Mar 15 17:49:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 09:49:07 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 18:00:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 10:00:27 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 18:22:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 10:22:07 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 18:43:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 10:43:38 -0700 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-15 18:43 Message: Logged In: YES user_id=1736372 Originator: YES Hm, works one Linux. Try this one File Added: gzip.py.diff ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 17:42 Message: Logged In: YES user_id=1403274 Originator: NO Excuse me, but I can't apply the patch. I have Windows XP without any SP and I tried to do the command patch -u gzip.py gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Thu Mar 15 19:01:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 11:01:40 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 18:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 19:30:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 11:30:39 -0700 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by lucas_malor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 19:30 Message: Logged In: YES user_id=1403274 Originator: NO I applied the patch by hand, I think the problem is simply it's for python 2.6 (I have the stable 2.5 version) Anyway like I wrote for an old similar patch of another user, the patch starts to read the header at the current position, and not at the start of the file. You can see it trying this piece of code: --------------------------------------- import urllib2 import array import gzip urlfile = urllib2.urlopen(someurl) header = array.array("B") header.fromstring(urlfile.read(1)) gzfile = gzip.GzipFile(fileobj=urlfile) print gzfile.read() ----------------------------------------- Error: ------------------------------------------------------------------------------ File "c:\My Programs\Python\lib\gzip.py", line 285, in read self._read_gzip_header(self.fileobj) File "c:\My Programs\Python\lib\gzip.py", line 177, in _read_gzip_header raise IOError, 'Not a gzipped file' IOError: Not a gzipped file >Exit code: 1 ------------------------------------------------------------------------------ I don't know how you can solve this without seek() Anyway if you are interested I created the diff for Python 2.5 : http://digilander.libero.it/LucasMalor/gzip_2.5.py.diff.gz ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-15 18:43 Message: Logged In: YES user_id=1736372 Originator: YES Hm, works one Linux. Try this one File Added: gzip.py.diff ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 17:42 Message: Logged In: YES user_id=1403274 Originator: NO Excuse me, but I can't apply the patch. I have Windows XP without any SP and I tried to do the command patch -u gzip.py gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Thu Mar 15 19:31:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 11:31:04 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 18:32 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 15:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 13:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 18:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Thu Mar 15 19:51:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 11:51:21 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 12:48 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: TH (therve) Assigned to: ?iga Seilnacht (zseil) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-15 19:51 Message: Logged In: YES user_id=1326842 Originator: NO Hi Neal, Yes, an exception in slots comparison would get overwritten, but I think that this is highly unlikely to happen. The user would have to put a malicious string into __slots__, and that string would have to go through list sorting in type_new() without raising an error. The original object is never stored in ht_slots; type_new() always constructs a new tuple from the sorted slot names. I'll leave the patch open until tomorow in case you have any other concerns, and then check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 06:42 Message: Logged In: YES user_id=33168 Originator: NO Sorry about the typo, I did mean remove, not review. The latest patch looks good. I have some questions though. What would happen if an exception is raised when comparing slots? I think it will be ok, the exception would get overwritten with the one about incompatible types/__slots__. I just want to be safe and it might be good to at least test this manually. Is the original object saved in ht_slots or is it always a tuple? If the original object is used, what if you have two classes with the same slots, but one uses a list and the other uses a tuple for __slots__? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 15:24 Message: Logged In: YES user_id=1326842 Originator: NO The ht_slots tuple can't contain unicode names; they are converted to strings in type_new(). type_new() also raises an error for any non string object found in __slots__. At the end of type_new(), ht_slots tuple can only contain valid identifiers minus __weakref__ and __dict__. I changed the patch to use PyObject_Compare() anyway, because it reduces the amount of code. I also removed whitespace changes in the docs, changed the tests as suggested and added a test with unicode slots. File Added: same_slots_added_5.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-14 12:22 Message: Logged In: YES user_id=1038797 Originator: YES > Ziga, there are a lot of changes to the doc that appear to be whitespace > only. Could you review them from the patch before checkin? I guess you mean "remove them" ? > I see _PyString_Eq is used. It's possible that __slots__ contain unicode, > possibly other types (I didn't check). It seems __slots__ can be unicode, but only with ascii content. This behavior is a bit weird... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-14 05:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 18:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 17:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 14:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 18:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 19:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 14:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Thu Mar 15 19:53:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 11:53:25 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 16:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) >Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 14:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 14:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 12:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 17:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Thu Mar 15 20:35:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 12:35:01 -0700 Subject: [Patches] [ python-Patches-1535504 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Patches item #1535504, was opened at 2006-08-06 21:43 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: This is a patch for Bug #1436206: On Windows, if the path name of a CGI script to be run contains space characters, it need to be quoted properly when called via os.popen2/3. Otherwise the script can not be executed. Solved by using commands.mkarg() to quote arguments where necessary. ---------------------------------------------------------------------- >Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 20:35 Message: Logged In: YES user_id=376953 Originator: YES The bugreport I spoke of has been filed as http://python.org/sf/1681674. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-15 10:05 Message: Logged In: YES user_id=376953 Originator: YES No, the error it's related to http://python.org/sf/1175984 (and maybe http://python.org/sf/1260171). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 08:48 Message: Logged In: YES user_id=849994 Originator: NO Which error is that? Is it perhaps this: http://python.org/sf/1124861 ? ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2007-03-14 22:22 Message: Logged In: YES user_id=376953 Originator: YES I think the best way to solve this would be to use the subprocess module, as amk suggested. I included a new patch which for CGIHTTPServer which uses subprocess. Unfortunately this does not work ion Windows due to a problem with subprocess: On Windows passing the request.rfile (a _fileobject wrapper arround the socket) as stdin/out lead to an error. I'll file a bugreport on that case. Beside of this, the patch should solve the problem in a platform-independent way. File Added: CGIHTTPServer.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:36 Message: Logged In: YES user_id=849994 Originator: NO Note that commands.mkarg() is written for UNIX shells. While it may work with spaces in the file name, it may produce illegal Windows command line commands in other cases. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 19:54 Message: Logged In: YES user_id=11375 Would it simplify matters if CGIHTTPServer used the subprocess module, which tries to provide a platform-independent interface? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1535504&group_id=5470 From noreply at sourceforge.net Thu Mar 15 21:38:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 13:38:49 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 14:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:06:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:06:22 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:14:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:14:45 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 18:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:27:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:27:17 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 14:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:35:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:35:22 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 18:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:40:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:40:16 -0700 Subject: [Patches] [ python-Patches-1107656 ] Add Thread.isActive() Message-ID: Patches item #1107656, was opened at 2005-01-23 05:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107656&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Alan Green (alanvgreen) Assigned to: Nobody/Anonymous (nobody) Summary: Add Thread.isActive() Initial Comment: The documentation for threading.Thread states: """Once the thread's activity is started, the thread is considered 'alive' and 'active' (these concepts are almost, but not quite exactly, the same; their definition is intentionally somewhat vague). It stops being alive and active when its run() method terminates - either normally, or by raising an unhandled exception.""" This is confusing. There doesn't seem to be a need to expose both 'alive' and 'active' concepts in the API. The confusion was reported as part of Issue 912943 "7.5.6 Thread Objects is too vague" This patch: - adds an isActive() method to Thread, that tests whether the thread is active. - adds documentation for isActive() - modifies the documentation for isAlive(), noting that it is deprecated and explaining why. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:40 Message: Logged In: YES user_id=849994 Originator: NO Superseded by patch #1680968. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-05-09 00:02 Message: Logged In: YES user_id=51702 I'm confused. Wouldn't it be better to just keep the isAlive() method instead of deprecating it and introducing isActive() in its place? In that way you only have to change the documentation and the API can remain intact. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1107656&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:45:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:45:55 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 14:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Thu Mar 15 22:53:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 14:53:57 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Thu Mar 15 23:56:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 15:56:55 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 03:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: TH (therve) Assigned to: ?iga Seilnacht (zseil) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 15:56 Message: Logged In: YES user_id=33168 Originator: NO Go ahead and check in. Thanks! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-15 11:51 Message: Logged In: YES user_id=1326842 Originator: NO Hi Neal, Yes, an exception in slots comparison would get overwritten, but I think that this is highly unlikely to happen. The user would have to put a malicious string into __slots__, and that string would have to go through list sorting in type_new() without raising an error. The original object is never stored in ht_slots; type_new() always constructs a new tuple from the sorted slot names. I'll leave the patch open until tomorow in case you have any other concerns, and then check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-14 22:42 Message: Logged In: YES user_id=33168 Originator: NO Sorry about the typo, I did mean remove, not review. The latest patch looks good. I have some questions though. What would happen if an exception is raised when comparing slots? I think it will be ok, the exception would get overwritten with the one about incompatible types/__slots__. I just want to be safe and it might be good to at least test this manually. Is the original object saved in ht_slots or is it always a tuple? If the original object is used, what if you have two classes with the same slots, but one uses a list and the other uses a tuple for __slots__? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 07:24 Message: Logged In: YES user_id=1326842 Originator: NO The ht_slots tuple can't contain unicode names; they are converted to strings in type_new(). type_new() also raises an error for any non string object found in __slots__. At the end of type_new(), ht_slots tuple can only contain valid identifiers minus __weakref__ and __dict__. I changed the patch to use PyObject_Compare() anyway, because it reduces the amount of code. I also removed whitespace changes in the docs, changed the tests as suggested and added a test with unicode slots. File Added: same_slots_added_5.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-14 04:22 Message: Logged In: YES user_id=1038797 Originator: YES > Ziga, there are a lot of changes to the doc that appear to be whitespace > only. Could you review them from the patch before checkin? I guess you mean "remove them" ? > I see _PyString_Eq is used. It's possible that __slots__ contain unicode, > possibly other types (I didn't check). It seems __slots__ can be unicode, but only with ascii content. This behavior is a bit weird... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-13 21:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 10:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 09:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 05:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 09:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 05:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 05:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 10:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 10:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 05:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-30 16:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Fri Mar 16 03:01:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 19:01:12 -0700 Subject: [Patches] [ python-Patches-1681333 ] email.header unicode fix Message-ID: Patches item #1681333, was opened at 2007-03-15 11:13 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681333&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.header unicode fix Initial Comment: email.header.Header class has its unicode representation which is slightly different from str representation. >>> h = email.Header.make_header((('[XXX]', 'us-ascii'), ('Re:', 'us-ascii'))) >>> unicode(h) u'[XXX]Re:' >>> str(h) '[XXX] Re:' Note that a white space between ']' and 'R' is absent from unicode representation. A word-separating space should be needed in following contexts: lastcs \ nextcs | ascii | other | ascii | sp | sp | other | sp | nosp | Current code fails to put a space for ascii\ascii case. Also, if the ascii string has a trailing space, it may result in a extraneous double space which has semantically equivalent to a single space and sometimes annoying. You should use qp encoding for ascii charset if you insist on the presence of the space. The patch includes test code. :) ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2007-03-16 02:01 Message: Logged In: YES user_id=67709 Originator: YES Sorry but I am withdrawing the latter part of the patch for ascii encoding. Revised patch is for only unicode representation. File Added: email_header_unicode.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681333&group_id=5470 From noreply at sourceforge.net Fri Mar 16 03:22:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 19:22:54 -0700 Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to random Message-ID: Patches item #1681432, was opened at 2007-03-15 09:09 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wladmir van der Laan (miathan6) Assigned to: Nobody/Anonymous (nobody) Summary: Add triangular distribution to random Initial Comment: This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly. http://en.wikipedia.org/wiki/Triangular_distribution ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 22:22 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up some tests (Lib/test/test_random.py) and docs (Doc/lib/librandom.tex) for this? An explanation of why you think this should be included in the standard library would be helpful, too. Also, it seems you made this patch against Python 2.3. While this particular patch still applied (relatively) cleanly to Python 2.6a0 source, Python 2.3 is no longer supported and most patches made against it have a high probability of inapplicability. See http://www.python.org/dev/faq/ for information on how to obtain a read-only checkout of the latest source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 From noreply at sourceforge.net Fri Mar 16 03:40:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 19:40:14 -0700 Subject: [Patches] [ python-Patches-1680959 ] Add tests for pipes module (test_pipes) Message-ID: Patches item #1680959, was opened at 2007-03-14 15:48 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Collin Winter (collinwinter) Summary: Add tests for pipes module (test_pipes) Initial Comment: The attached file contains a patch to: - remove the "just import it" test for pipes from test_sundry.py - add test_pipes to expected skips on win32 in regrtest.py - remove the "small test program and example" from pipes.py (it seems to me this is best put in either tests or docs instead of the module itself) It also includes a new test_pipes.py module. At the moment this covers about 86% of the pipes.py code; I'll try to get that higher, but I wanted to throw this out there for initial feedback. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 22:40 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! Initial comments: * test_pipes does not conform to PEP 8 (whitespace issues, line length, etc). * SVN reports that test_pipes has inconsistent line endings. * Calling os.path.exists() as a check before os.unlink() creates a race condition; just catch the exception. * In the future, please include new files in the patch itself. "svn add" the file, then "svn diff" will include it when creating the diff. Please address these issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 From noreply at sourceforge.net Fri Mar 16 03:46:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 19:46:26 -0700 Subject: [Patches] [ python-Patches-1676994 ] Refactor test_popen2.py to use unittest. Message-ID: Patches item #1676994, was opened at 2007-03-09 01:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_popen2.py to use unittest. Initial Comment: This patch turns test_popen2.py into a unittest file. There should be no changes in what the file tests. Modifying test_popen2.py to use unittest also required making a small change to popen2.py, which also contains some testing code. Lib/test/output/test_popen2 should be removed when this patch is applied. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 22:46 Message: Logged In: YES user_id=1344176 Originator: NO Why not fold popen2._test() into test_popen2? Is there a reason for the "verbose = False" assignment at the top? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 From noreply at sourceforge.net Fri Mar 16 03:47:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 19:47:09 -0700 Subject: [Patches] [ python-Patches-1192590 ] debugger ``condition`` and ``ignore`` exception handling Message-ID: Patches item #1192590, was opened at 2005-04-29 14:25 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jeremy Jones (jmjones) Assigned to: Collin Winter (collinwinter) Summary: debugger ``condition`` and ``ignore`` exception handling Initial Comment: Fixed ``ignore`` and ``condition`` functions in the debugger (pdb.py) where they were not handling an ``IndexError`` exception which occurs when an invalid breakpoint number is passed in. Added a function ``do_show()`` which lists all breakpoints. ``do_show()`` takes a filename pattern as an argument. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 12:06 Message: Logged In: YES user_id=1344176 Originator: NO Applied the bug fix portion of the patch as r54271 (trunk), r54273 (release25-maint). Thanks for the fix! ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 11:54 Message: Logged In: YES user_id=1344176 Originator: NO I'll apply the fixes to do_ignore() and do_condition(), but I'm not so sure about adding do_show(). This meaning of "show" would diverge wildly from gdb's command of the same name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192590&group_id=5470 From noreply at sourceforge.net Fri Mar 16 03:49:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 19:49:04 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 17:30 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 22:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-13 19:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 13:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 15:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 03:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Fri Mar 16 04:04:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 20:04:34 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 14:23 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-15 23:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 16:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 09:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 13:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 06:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 12:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 07:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 02:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:11:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:11:20 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:13:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:13:22 -0700 Subject: [Patches] [ python-Patches-1642547 ] Fix error/crash in AST: syntaxerror in complex ifs Message-ID: Patches item #1642547, was opened at 2007-01-23 09:02 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 9 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Fix error/crash in AST: syntaxerror in complex ifs Initial Comment: Fix a bug in Python/ast.c, where a particular syntaxerror in an 'if' with one or more 'elif's would be ignored or mishandled: timberwolf:~/python/python/trunk > cat test2.py def bug(): if w: dir()=1 elif v: pass timberwolf:~/python/python/trunk > python2.4 test2.py File "test2.py", line 3 dir()=1 SyntaxError: can't assign to function call timberwolf:~/python/python/trunk > python2.5 test2.py Exception exceptions.SyntaxError: ("can't assign to function call", 3) in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted The actual problem is the lack of error checks on the return values of ast_for_expr() and ast_for_suite, in ast_for_if_stmt. Attached patch fixes. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-16 00:13 Message: Logged In: YES user_id=1344176 Originator: NO Updated to apply against SVN HEAD and incorporated the additional error checking Martin pointed out. Checked in as r54404 (trunk), r54405 (release25-maint). Any objection to cleaning up ast.c's indentation? It's an ungodly mess. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-14 04:46 Message: Logged In: YES user_id=21627 Originator: NO The patch looks fine to me, please apply (or let me know if you want me to apply it). I think there are a few other places where return values of ast_for_ aren't checked: - ast_for_listcomp, not checking ast_for_expr results - ast_for_withexpr, not checking context_expr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:16:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:16:55 -0700 Subject: [Patches] [ python-Patches-1642547 ] Fix error/crash in AST: syntaxerror in complex ifs Message-ID: Patches item #1642547, was opened at 2007-01-23 06:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 9 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Fix error/crash in AST: syntaxerror in complex ifs Initial Comment: Fix a bug in Python/ast.c, where a particular syntaxerror in an 'if' with one or more 'elif's would be ignored or mishandled: timberwolf:~/python/python/trunk > cat test2.py def bug(): if w: dir()=1 elif v: pass timberwolf:~/python/python/trunk > python2.4 test2.py File "test2.py", line 3 dir()=1 SyntaxError: can't assign to function call timberwolf:~/python/python/trunk > python2.5 test2.py Exception exceptions.SyntaxError: ("can't assign to function call", 3) in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted The actual problem is the lack of error checks on the return values of ast_for_expr() and ast_for_suite, in ast_for_if_stmt. Attached patch fixes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 21:16 Message: Logged In: YES user_id=33168 Originator: NO It would be great to clean up the indentation in ast.c. I think I fixed it (at least made it consistent) in compile.c. Probably symtable.c could use it too. All the files that were new from the AST branch should be cleaned up and use the proper formatting we are using for 3k. I don't remember exactly what it is, but I think it's 4 space indents, but possibly still using tabs. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:13 Message: Logged In: YES user_id=1344176 Originator: NO Updated to apply against SVN HEAD and incorporated the additional error checking Martin pointed out. Checked in as r54404 (trunk), r54405 (release25-maint). Any objection to cleaning up ast.c's indentation? It's an ungodly mess. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-14 01:46 Message: Logged In: YES user_id=21627 Originator: NO The patch looks fine to me, please apply (or let me know if you want me to apply it). I think there are a few other places where return values of ast_for_ aren't checked: - ast_for_listcomp, not checking ast_for_expr results - ast_for_withexpr, not checking context_expr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:20:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:20:57 -0700 Subject: [Patches] [ python-Patches-1642547 ] Fix error/crash in AST: syntaxerror in complex ifs Message-ID: Patches item #1642547, was opened at 2007-01-23 09:02 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 9 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Fix error/crash in AST: syntaxerror in complex ifs Initial Comment: Fix a bug in Python/ast.c, where a particular syntaxerror in an 'if' with one or more 'elif's would be ignored or mishandled: timberwolf:~/python/python/trunk > cat test2.py def bug(): if w: dir()=1 elif v: pass timberwolf:~/python/python/trunk > python2.4 test2.py File "test2.py", line 3 dir()=1 SyntaxError: can't assign to function call timberwolf:~/python/python/trunk > python2.5 test2.py Exception exceptions.SyntaxError: ("can't assign to function call", 3) in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted The actual problem is the lack of error checks on the return values of ast_for_expr() and ast_for_suite, in ast_for_if_stmt. Attached patch fixes. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-16 00:20 Message: Logged In: YES user_id=1344176 Originator: NO PEP 7's section on Py3k says 4-space indents, no tabs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 00:16 Message: Logged In: YES user_id=33168 Originator: NO It would be great to clean up the indentation in ast.c. I think I fixed it (at least made it consistent) in compile.c. Probably symtable.c could use it too. All the files that were new from the AST branch should be cleaned up and use the proper formatting we are using for 3k. I don't remember exactly what it is, but I think it's 4 space indents, but possibly still using tabs. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 00:13 Message: Logged In: YES user_id=1344176 Originator: NO Updated to apply against SVN HEAD and incorporated the additional error checking Martin pointed out. Checked in as r54404 (trunk), r54405 (release25-maint). Any objection to cleaning up ast.c's indentation? It's an ungodly mess. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-14 04:46 Message: Logged In: YES user_id=21627 Originator: NO The patch looks fine to me, please apply (or let me know if you want me to apply it). I think there are a few other places where return values of ast_for_ aren't checked: - ast_for_listcomp, not checking ast_for_expr results - ast_for_withexpr, not checking context_expr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:22:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:22:57 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04: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=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:51:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:51:34 -0700 Subject: [Patches] [ python-Patches-1676994 ] Refactor test_popen2.py to use unittest. Message-ID: Patches item #1676994, was opened at 2007-03-08 23:38 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_popen2.py to use unittest. Initial Comment: This patch turns test_popen2.py into a unittest file. There should be no changes in what the file tests. Modifying test_popen2.py to use unittest also required making a small change to popen2.py, which also contains some testing code. Lib/test/output/test_popen2 should be removed when this patch is applied. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-15 22:51 Message: Logged In: YES user_id=1727609 Originator: YES File Added: refactor_test_popen2.py.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:46 Message: Logged In: YES user_id=1344176 Originator: NO Why not fold popen2._test() into test_popen2? Is there a reason for the "verbose = False" assignment at the top? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 From noreply at sourceforge.net Fri Mar 16 05:53:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 21:53:25 -0700 Subject: [Patches] [ python-Patches-1676994 ] Refactor test_popen2.py to use unittest. Message-ID: Patches item #1676994, was opened at 2007-03-08 23:38 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_popen2.py to use unittest. Initial Comment: This patch turns test_popen2.py into a unittest file. There should be no changes in what the file tests. Modifying test_popen2.py to use unittest also required making a small change to popen2.py, which also contains some testing code. Lib/test/output/test_popen2 should be removed when this patch is applied. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-15 22:53 Message: Logged In: YES user_id=1727609 Originator: YES patch v2 changes: verbose = False was a bug. Removed. Folded popen2._test() moved into test_popen2 (good idea, btw). Refactored some more. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-15 22:51 Message: Logged In: YES user_id=1727609 Originator: YES File Added: refactor_test_popen2.py.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:46 Message: Logged In: YES user_id=1344176 Originator: NO Why not fold popen2._test() into test_popen2? Is there a reason for the "verbose = False" assignment at the top? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:01:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:01:31 -0700 Subject: [Patches] [ python-Patches-894936 ] Have a split corresponding with os.path.join Message-ID: Patches item #894936, was opened at 2004-02-11 08:36 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=894936&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nicolas Fleury (nidoizo) Assigned to: Nobody/Anonymous (nobody) Summary: Have a split corresponding with os.path.join Initial Comment: I would be nice to have a function to do the exact opposite of os.path.join, something like an os.path.splitall or fullsplit. Rationale: Currently, on Windows, using os.path.split produce the following result: os.path.split('Z:/xyz') => ('Z:/', 'xyz') It exceptionaly keep the \ after the drive. This exception makes str.split incompatible with os.path.join that is expecting the \. Spliting fully a path is useful when transforming absolute paths to relative paths. I could also be nice to have a function to do that in os.path. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:01 Message: Logged In: YES user_id=33168 Originator: NO This is close enough to a patch so moving. As a patch, this has more chance of being resolved one way or the other. ---------------------------------------------------------------------- Comment By: Nicolas Fleury (nidoizo) Date: 2004-05-25 06:13 Message: Logged In: YES user_id=151545 I have attached a possible implementation (not tested on Unix). Feel free to ask if I can do more. ---------------------------------------------------------------------- Comment By: Nicolas Fleury (nidoizo) Date: 2004-05-25 06:12 Message: Logged In: YES user_id=151545 I have attached a possible implementation (not tested on Unix). Feel free to ask if I can do more. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-20 23:17 Message: Logged In: YES user_id=80475 Do you have a patch in mind? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=894936&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:21:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:21:45 -0700 Subject: [Patches] [ python-Patches-1521196 ] smtplib login fails with aol smtp server Message-ID: Patches item #1521196, was opened at 2006-07-12 13:32 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521196&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter (ps1956) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib login fails with aol smtp server Initial Comment: Sending email to AOL's smtp server fails with "501 INVALID SASL FORMAT OR LENGTH". This patch allows the default order (AUTH_CRAM_MD5, AUTH_PLAIN, AUTH_LOGIN) used to select the AUTH method to be overridden with a new optional preferred_auths parameter. By changing the order so that AUTH_LOGIN comes before AUTH_PLAIN, AOL's smtp server is happy. This patch may be useful for other stmp servers that fail on login when using the default AUTH selection order. Sample usage: if aol: auths = [smtplib.AUTH_CRAM_MD5, smtplib.AUTH_LOGIN, smtplib.AUTH_PLAIN] smtp.login(fromUser.split("@")[0], passwd, auths) else: smtp.login(fromUser, passwd) I tested the patch using python 2.4.3 on slackware 10.2 (kernel 2.4.32). ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 06:21 Message: Logged In: YES user_id=1720594 Originator: NO This seems reasonable to me; the preference of which authentication modes to use shouldn't be a hardcoded decision in smtplib, especially if one of the biggest email servers around breaks if we can't. However, I think it needs a couple things done before it should be accepted: #1) The code patch itself needs to be done against the trunk, as it doesn't currently apply cleanly (it's a trivial fix) #2) The documentation patch should include mention of the "constants" of smtplib.AUTH_* ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521196&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:23:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:23:19 -0700 Subject: [Patches] [ python-Patches-1165404 ] ConfigParser alternative key-value delimitier Message-ID: Patches item #1165404, was opened at 2005-03-17 08:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1165404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergey Dorofeev (fidoman) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser alternative key-value delimitier Initial Comment: ConfigParser is module which parses commonly used INI files. It gets sections from file and values from sections. By now, it gets from file key and value divided by symbol ":" or "=". For FTN application, a want to use FTN addresses as keys. FTN address looks like "2:5020/12000". So if I try to use it as key, ConfigParser considers "2" as key and "5020/12000 = ..." as value. I made patch, which allows to use any set of symbols (or '=' and ':' by default for compatibility) as delimitier between key and value in INI file. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:23 Message: Logged In: YES user_id=33168 Originator: NO Note: delimmap doesn't look like it's needed. Should be able to just check if vi in self.delim. (Although I'm kinda tired and don't feel like thinking too hard, so maybe that's just bs.). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1165404&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:32:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:32:39 -0700 Subject: [Patches] [ python-Patches-1395552 ] add support for thread function result storage Message-ID: Patches item #1395552, was opened at 2006-01-02 20:23 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1395552&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tobias Simon (tosi-in) Assigned to: Nobody/Anonymous (nobody) Summary: add support for thread function result storage Initial Comment: Here comes a little add-on for python's threading library: It provides a way of reading a thread function's result after the termination. after a thread, which was created using safe_result = True as a constructor parameter, the thread object will gain the function result as a parameter, called "result". If the thread function did not return till the result attribute access, an AttributeError is raised. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 06:32 Message: Logged In: YES user_id=1720594 Originator: NO I'm not sure this is generally useful. It might be sometimes, but it seems to me that it would often be insufficient for many tasks. There are many different ways that someone could get a result back from a thread; a Queue, a callback, being all sexy with pydispatcher, or many other ways. Since there are so many different approaches to this job, each with strengths and weaknesses in a specific situation, and none that are 'generally' useful over a broad range of activities, I don't think adding this one particular method to the core is a good idea. It's an ASPN Python Cookbook recipe for a threading.Thread subclass. E.g., I'm recommending this patch be rejected. P.S. Should that make me feel like a bad person? -.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1395552&group_id=5470 From noreply at sourceforge.net Fri Mar 16 07:41:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 15 Mar 2007 23:41:55 -0700 Subject: [Patches] [ python-Patches-1240614 ] release lock on exception in threading.Thread.join() Message-ID: Patches item #1240614, was opened at 2005-07-19 02:25 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dirk Groeneveld (marvinalone) Assigned to: Nobody/Anonymous (nobody) Summary: release lock on exception in threading.Thread.join() Initial Comment: If an exception happens in threading.Thread.join(), the lock self.__block never gets released. The next time Thread.join() is called, it blocks forever. The only exception I can think of right now that triggers this error is KeyboardInterrupt, but there might be more. The patch puts everything between self.__block.acquire() and self.__block.release() into a try ... finally block, and releases the lock in the finally clause. A transcript of the error follows: >>> import threading >>> def f(): ... while True: ... pass ... >>> t = threading.Thread(target = f) >>> t.setDaemon(True) >>> def j(t): ... while True: ... print "trying to join" ... t.join(1) ... >>> t.start() >>> j(t) trying to join trying to join trying to join Traceback (most recent call last): File "", line 1, in ? File "", line 4, in j File "/usr/lib/python2.4/threading.py", line 550, in join self.__block.wait(delay) File "/usr/lib/python2.4/threading.py", line 222, in wait _sleep(delay) KeyboardInterrupt >>> j(t) trying to join ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 06:41 Message: Logged In: YES user_id=1720594 Originator: NO This is redundant in the current HEAD of the repository; there's already a try/finally with a release in it. Recommend close. ---------------------------------------------------------------------- Comment By: Dirk Groeneveld (marvinalone) Date: 2005-07-22 07:12 Message: Logged In: YES user_id=146647 The (a?) corresponding bug report is #1171023, at http://www.python.org/sf/1171023. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:08:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:08:46 -0700 Subject: [Patches] [ python-Patches-850728 ] Semaphore.acquire() timeout parameter Message-ID: Patches item #850728, was opened at 2003-11-28 12:47 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850728&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Semaphore.acquire() timeout parameter Initial Comment: New optional timeout parameter for Semaphore.acquire(). acquire(block=True, timeout=None) When invoked with blocking set to true and timeout set to a positive number, it blocks at most timeout seconds and return false if the internal counter is still zero; otherwise return true. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 07:08 Message: Logged In: YES user_id=1720594 Originator: NO This applies cleanly against the HEAD, and passes all of the threading tests. I don't see any reason NOT to have a timeout on the Semaphores, and the implementation is clean enough. I do think that it should have some tests written since its a newish feature before being accepted, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=850728&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:10:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:10:28 -0700 Subject: [Patches] [ python-Patches-1240614 ] release lock on exception in threading.Thread.join() Message-ID: Patches item #1240614, was opened at 2005-07-19 02:25 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dirk Groeneveld (marvinalone) Assigned to: Nobody/Anonymous (nobody) Summary: release lock on exception in threading.Thread.join() Initial Comment: If an exception happens in threading.Thread.join(), the lock self.__block never gets released. The next time Thread.join() is called, it blocks forever. The only exception I can think of right now that triggers this error is KeyboardInterrupt, but there might be more. The patch puts everything between self.__block.acquire() and self.__block.release() into a try ... finally block, and releases the lock in the finally clause. A transcript of the error follows: >>> import threading >>> def f(): ... while True: ... pass ... >>> t = threading.Thread(target = f) >>> t.setDaemon(True) >>> def j(t): ... while True: ... print "trying to join" ... t.join(1) ... >>> t.start() >>> j(t) trying to join trying to join trying to join Traceback (most recent call last): File "", line 1, in ? File "", line 4, in j File "/usr/lib/python2.4/threading.py", line 550, in join self.__block.wait(delay) File "/usr/lib/python2.4/threading.py", line 222, in wait _sleep(delay) KeyboardInterrupt >>> j(t) trying to join ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 07:10 Message: Logged In: YES user_id=1720594 Originator: NO I peaked around; the patch that got applied to resolve this was 1314396 in r41524. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 06:41 Message: Logged In: YES user_id=1720594 Originator: NO This is redundant in the current HEAD of the repository; there's already a try/finally with a release in it. Recommend close. ---------------------------------------------------------------------- Comment By: Dirk Groeneveld (marvinalone) Date: 2005-07-22 07:12 Message: Logged In: YES user_id=146647 The (a?) corresponding bug report is #1171023, at http://www.python.org/sf/1171023. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:21:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:21:27 -0700 Subject: [Patches] [ python-Patches-1240614 ] release lock on exception in threading.Thread.join() Message-ID: Patches item #1240614, was opened at 2005-07-18 19:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dirk Groeneveld (marvinalone) Assigned to: Nobody/Anonymous (nobody) Summary: release lock on exception in threading.Thread.join() Initial Comment: If an exception happens in threading.Thread.join(), the lock self.__block never gets released. The next time Thread.join() is called, it blocks forever. The only exception I can think of right now that triggers this error is KeyboardInterrupt, but there might be more. The patch puts everything between self.__block.acquire() and self.__block.release() into a try ... finally block, and releases the lock in the finally clause. A transcript of the error follows: >>> import threading >>> def f(): ... while True: ... pass ... >>> t = threading.Thread(target = f) >>> t.setDaemon(True) >>> def j(t): ... while True: ... print "trying to join" ... t.join(1) ... >>> t.start() >>> j(t) trying to join trying to join trying to join Traceback (most recent call last): File "", line 1, in ? File "", line 4, in j File "/usr/lib/python2.4/threading.py", line 550, in join self.__block.wait(delay) File "/usr/lib/python2.4/threading.py", line 222, in wait _sleep(delay) KeyboardInterrupt >>> j(t) trying to join ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 00:21 Message: Logged In: YES user_id=33168 Originator: NO Makes sense to me. Thanks for the comment! ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 00:10 Message: Logged In: YES user_id=1720594 Originator: NO I peaked around; the patch that got applied to resolve this was 1314396 in r41524. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-15 23:41 Message: Logged In: YES user_id=1720594 Originator: NO This is redundant in the current HEAD of the repository; there's already a try/finally with a release in it. Recommend close. ---------------------------------------------------------------------- Comment By: Dirk Groeneveld (marvinalone) Date: 2005-07-22 00:12 Message: Logged In: YES user_id=146647 The (a?) corresponding bug report is #1171023, at http://www.python.org/sf/1171023. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1240614&group_id=5470 From noreply at sourceforge.net Fri Mar 16 08:34:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 00:34:49 -0700 Subject: [Patches] [ python-Patches-1273829 ] extending os.walk to support following symlinks Message-ID: Patches item #1273829, was opened at 2005-08-26 07:21 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1273829&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erick Tryzelaar (idadesub) Assigned to: Nobody/Anonymous (nobody) Summary: extending os.walk to support following symlinks Initial Comment: this is a very simple extension to os.walk to optionally walk down into symlink directories, when it is supported by the operating system. This patch keeps a compatible interface by having this option disabled. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 07:34 Message: Logged In: YES user_id=1720594 Originator: NO I'm not sure if this is a good idea; although I am certain it would be useful at times. Dangerous! But if its documented, ... and there's our problem :) Patch applies cleanly to the HEAD, but needs documentation. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-26 08:23 Message: Logged In: YES user_id=1188172 The docs to os.walk say: """ Note: On systems that support symbolic links, links to subdirectories appear in dirnames lists, but walk() will not visit them (infinite loops are hard to avoid when following symbolic links). To visit linked directories, you can identify them with os.path.islink(path), and invoke walk(path) on each directly. """ Nevertheless, we could offer this option with a caution message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1273829&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:00:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:00:23 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:22:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:22:56 -0700 Subject: [Patches] [ python-Patches-1273829 ] extending os.walk to support following symlinks Message-ID: Patches item #1273829, was opened at 2005-08-26 07:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1273829&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Erick Tryzelaar (idadesub) Assigned to: Nobody/Anonymous (nobody) Summary: extending os.walk to support following symlinks Initial Comment: this is a very simple extension to os.walk to optionally walk down into symlink directories, when it is supported by the operating system. This patch keeps a compatible interface by having this option disabled. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:22 Message: Logged In: YES user_id=849994 Originator: NO Added docs and tests and committed in rev. 54407. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 07:34 Message: Logged In: YES user_id=1720594 Originator: NO I'm not sure if this is a good idea; although I am certain it would be useful at times. Dangerous! But if its documented, ... and there's our problem :) Patch applies cleanly to the HEAD, but needs documentation. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-26 08:23 Message: Logged In: YES user_id=1188172 The docs to os.walk say: """ Note: On systems that support symbolic links, links to subdirectories appear in dirnames lists, but walk() will not visit them (infinite loops are hard to avoid when following symbolic links). To visit linked directories, you can identify them with os.path.islink(path), and invoke walk(path) on each directly. """ Nevertheless, we could offer this option with a caution message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1273829&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:24:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:24:50 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 18:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:24 Message: Logged In: YES user_id=849994 Originator: NO Since there is an "Availability" remark, I wouldn't be concerned. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 21:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 14:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 18:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 11:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 17:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 12:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 06:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:26:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:26:31 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 22:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 02:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-13 23:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 17:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 20:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 08:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:27:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:27:52 -0700 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-16 09:27 Message: Logged In: YES user_id=1736372 Originator: YES There is a simple solution for that problem: DON'T! If you pass a file descriptor to the GzipFile class it is your responsibility that the file is a gzip file and that the file pointer is at the right position. After having a short look into original code I don't think it can cope with the use case you brought up. I'd even argue that seeking to the beginning of the file is broken behaviour. What if the gzip content doesn't start at the beginning of the file? In fact prepending some header before compressed data is quite common. If the file you where reading really had a header your example had just worked. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 19:30 Message: Logged In: YES user_id=1403274 Originator: NO I applied the patch by hand, I think the problem is simply it's for python 2.6 (I have the stable 2.5 version) Anyway like I wrote for an old similar patch of another user, the patch starts to read the header at the current position, and not at the start of the file. You can see it trying this piece of code: --------------------------------------- import urllib2 import array import gzip urlfile = urllib2.urlopen(someurl) header = array.array("B") header.fromstring(urlfile.read(1)) gzfile = gzip.GzipFile(fileobj=urlfile) print gzfile.read() ----------------------------------------- Error: ------------------------------------------------------------------------------ File "c:\My Programs\Python\lib\gzip.py", line 285, in read self._read_gzip_header(self.fileobj) File "c:\My Programs\Python\lib\gzip.py", line 177, in _read_gzip_header raise IOError, 'Not a gzipped file' IOError: Not a gzipped file >Exit code: 1 ------------------------------------------------------------------------------ I don't know how you can solve this without seek() Anyway if you are interested I created the diff for Python 2.5 : http://digilander.libero.it/LucasMalor/gzip_2.5.py.diff.gz ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-15 18:43 Message: Logged In: YES user_id=1736372 Originator: YES Hm, works one Linux. Try this one File Added: gzip.py.diff ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 17:42 Message: Logged In: YES user_id=1403274 Originator: NO Excuse me, but I can't apply the patch. I have Windows XP without any SP and I tried to do the command patch -u gzip.py gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:28:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:28:26 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:28 Message: Logged In: YES user_id=849994 Originator: YES It's not specified that exit handlers can do cleanup only, in theory they could do things like sending an email etc. Please let's not introduce gratuitous breakage here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 18:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Fri Mar 16 09:57:45 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 01:57:45 -0700 Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to random Message-ID: Patches item #1681432, was opened at 2007-03-15 14:09 Message generated for change (Comment added) made by miathan6 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wladmir van der Laan (miathan6) Assigned to: Nobody/Anonymous (nobody) Summary: Add triangular distribution to random Initial Comment: This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly. http://en.wikipedia.org/wiki/Triangular_distribution ---------------------------------------------------------------------- >Comment By: Wladmir van der Laan (miathan6) Date: 2007-03-16 09:57 Message: Logged In: YES user_id=49336 Originator: YES Yes, I will add some tests and docs, although usage is quite straightforward. That's the main reason also for adding this distribution, it has three parameters which are intuitive (left, center and right) the distribution is just a linear interpolation (P(left)=0 and P(center)=1 and P(right)=0 ). I am writing an event simulation and I added it because I was missing some kind of assymetric distribution for timings; in an uniform distribution t-x and t+y would be just as likely as t, in a gaussian distribution you can only set sigma but not the upper and lower bound. With all the other distributions in there I thought it might come in handy for other people too. I also believe it has its uses in sound generation/processing. Sorry for providing a patch against 2.3 and not 2.5 or higher, I cooked it up at work and it seems I have this ancient version here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:22 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up some tests (Lib/test/test_random.py) and docs (Doc/lib/librandom.tex) for this? An explanation of why you think this should be included in the standard library would be helpful, too. Also, it seems you made this patch against Python 2.3. While this particular patch still applied (relatively) cleanly to Python 2.6a0 source, Python 2.3 is no longer supported and most patches made against it have a high probability of inapplicability. See http://www.python.org/dev/faq/ for information on how to obtain a read-only checkout of the latest source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 From noreply at sourceforge.net Fri Mar 16 10:06:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 02:06:46 -0700 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by lucas_malor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-16 10:06 Message: Logged In: YES user_id=1403274 Originator: NO Indeed the problem is seek() is not implementes for urllib objects. It's not a bug of your patch, sorry if I explained it bad. ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-16 09:27 Message: Logged In: YES user_id=1736372 Originator: YES There is a simple solution for that problem: DON'T! If you pass a file descriptor to the GzipFile class it is your responsibility that the file is a gzip file and that the file pointer is at the right position. After having a short look into original code I don't think it can cope with the use case you brought up. I'd even argue that seeking to the beginning of the file is broken behaviour. What if the gzip content doesn't start at the beginning of the file? In fact prepending some header before compressed data is quite common. If the file you where reading really had a header your example had just worked. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 19:30 Message: Logged In: YES user_id=1403274 Originator: NO I applied the patch by hand, I think the problem is simply it's for python 2.6 (I have the stable 2.5 version) Anyway like I wrote for an old similar patch of another user, the patch starts to read the header at the current position, and not at the start of the file. You can see it trying this piece of code: --------------------------------------- import urllib2 import array import gzip urlfile = urllib2.urlopen(someurl) header = array.array("B") header.fromstring(urlfile.read(1)) gzfile = gzip.GzipFile(fileobj=urlfile) print gzfile.read() ----------------------------------------- Error: ------------------------------------------------------------------------------ File "c:\My Programs\Python\lib\gzip.py", line 285, in read self._read_gzip_header(self.fileobj) File "c:\My Programs\Python\lib\gzip.py", line 177, in _read_gzip_header raise IOError, 'Not a gzipped file' IOError: Not a gzipped file >Exit code: 1 ------------------------------------------------------------------------------ I don't know how you can solve this without seek() Anyway if you are interested I created the diff for Python 2.5 : http://digilander.libero.it/LucasMalor/gzip_2.5.py.diff.gz ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-15 18:43 Message: Logged In: YES user_id=1736372 Originator: YES Hm, works one Linux. Try this one File Added: gzip.py.diff ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 17:42 Message: Logged In: YES user_id=1403274 Originator: NO Excuse me, but I can't apply the patch. I have Windows XP without any SP and I tried to do the command patch -u gzip.py gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Fri Mar 16 13:02:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 05:02:22 -0700 Subject: [Patches] [ python-Patches-1623563 ] Allow __class __ assignment for classes with __slots__ Message-ID: Patches item #1623563, was opened at 2006-12-28 12:48 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: TH (therve) Assigned to: ?iga Seilnacht (zseil) Summary: Allow __class __ assignment for classes with __slots__ Initial Comment: I made a modification in typeobject.c to allow __class__ modification for classes with slots. It's basically a change in same_slots_added to count the offset of the slots and check if the names of the slots are the same (in the naive way). I don't check if slots are in a different order, that may be an improve. The patch is against trunk, with some tests. It's my first submission on Python, so every feedback will be welcome :). ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-16 13:02 Message: Logged In: YES user_id=1326842 Originator: NO Commited as revision 54412. Thanks for the patch, Thomas! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 23:56 Message: Logged In: YES user_id=33168 Originator: NO Go ahead and check in. Thanks! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-15 19:51 Message: Logged In: YES user_id=1326842 Originator: NO Hi Neal, Yes, an exception in slots comparison would get overwritten, but I think that this is highly unlikely to happen. The user would have to put a malicious string into __slots__, and that string would have to go through list sorting in type_new() without raising an error. The original object is never stored in ht_slots; type_new() always constructs a new tuple from the sorted slot names. I'll leave the patch open until tomorow in case you have any other concerns, and then check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-15 06:42 Message: Logged In: YES user_id=33168 Originator: NO Sorry about the typo, I did mean remove, not review. The latest patch looks good. I have some questions though. What would happen if an exception is raised when comparing slots? I think it will be ok, the exception would get overwritten with the one about incompatible types/__slots__. I just want to be safe and it might be good to at least test this manually. Is the original object saved in ht_slots or is it always a tuple? If the original object is used, what if you have two classes with the same slots, but one uses a list and the other uses a tuple for __slots__? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-14 15:24 Message: Logged In: YES user_id=1326842 Originator: NO The ht_slots tuple can't contain unicode names; they are converted to strings in type_new(). type_new() also raises an error for any non string object found in __slots__. At the end of type_new(), ht_slots tuple can only contain valid identifiers minus __weakref__ and __dict__. I changed the patch to use PyObject_Compare() anyway, because it reduces the amount of code. I also removed whitespace changes in the docs, changed the tests as suggested and added a test with unicode slots. File Added: same_slots_added_5.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-14 12:22 Message: Logged In: YES user_id=1038797 Originator: YES > Ziga, there are a lot of changes to the doc that appear to be whitespace > only. Could you review them from the patch before checkin? I guess you mean "remove them" ? > I see _PyString_Eq is used. It's possible that __slots__ contain unicode, > possibly other types (I didn't check). It seems __slots__ can be unicode, but only with ascii content. This behavior is a bit weird... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-14 05:01 Message: Logged In: YES user_id=33168 Originator: NO Ziga, there are a lot of changes to the doc that appear to be whitespace only. Could you review them from the patch before checkin? If you want to make whitespace/formatting changes, that's fine, but it's a lot easier to review if there are 2 separate checkins. In the test, it looks like it would be much easier to unpack the classes in the loop, since you know there are two. That would eliminate 2 of the inner loops which don't seem necessary. for cls1, cls2 in ((G, H), (P, Q)): Also, when doing data driven tests, it's important to add an error message about which iteration failed. Right now, you wouldn't know if G/H failed or P/Q failed since the line number will be the same. If you add a message to the assertions which contains data, then it's clear from the message which one failed. typeobject.c I see _PyString_Eq is used. It's possible that __slots__ contain unicode, possibly other types (I didn't check). What happens if non-strings are in __slots__ with this patch applied? The calculation for size could be done outside the loop with a multiply. I don't know which would be faster. I don't really care which is used either. Just something I noticed. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-13 18:12 Message: Logged In: YES user_id=1038797 Originator: YES That's great, thanks a lot for you help. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-13 17:16 Message: Logged In: YES user_id=1326842 Originator: NO The only problem that I see with this patch is that slot names have to be listed in both classes in the same order for __class__ assignment to work. This could have strange consequences when a dict is used for __slots__. I'm attaching a patch that fixes this, with modified test and documentation. The change had to be done in type_new() function, by sorting slotnames before the creation of member descriptors. Most of the documentation changes are whitespace cleanup. File Added: same_slots_added_4.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-08 14:08 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_3.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-07 18:07 Message: Logged In: YES user_id=1326842 Originator: NO The PyObject * cast is reduntant, but otherwise the patch looks good to me. I added a few more tests, but I can't attach a file so I posted them here: http://freeweb.siol.net/chollus/ ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:05 Message: Logged In: YES user_id=1038797 Originator: YES Thanks, I wasn't able to find this function. I updated the patch for using this. File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-03-07 14:04 Message: Logged In: YES user_id=1038797 Originator: YES File Added: same_slots_added_2.diff ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-06 19:07 Message: Logged In: YES user_id=1326842 Originator: NO You should use _PyString_Eq() for string comparison instead of relying on the internal details of PyStringObject. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-02-08 19:41 Message: Logged In: YES user_id=764593 Originator: NO Review five other patches. Post the review summaries (and tracker numbers) to the python-dev mailing list. In that same message, ask someone with commit privileges to do the 5:1 deal, pointing at this tracker number. ---------------------------------------------------------------------- Comment By: TH (therve) Date: 2007-02-06 14:43 Message: Logged In: YES user_id=1038797 Originator: YES Is there anything I can do to have a resolution on this ? Thanks. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-12-31 01:26 Message: Logged In: YES user_id=764593 Originator: NO Just going through the list doesn't seem so naive to me. If the slots are in a different order, then you would need to move the data around -- which borders on "maybe they ought to have written the translator themselves" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1623563&group_id=5470 From noreply at sourceforge.net Fri Mar 16 13:28:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 05:28:00 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 13:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Fri Mar 16 13:35:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 05:35:21 -0700 Subject: [Patches] [ python-Patches-1642547 ] Fix error/crash in AST: syntaxerror in complex ifs Message-ID: Patches item #1642547, was opened at 2007-01-23 15:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Closed Resolution: Accepted Priority: 9 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: Fix error/crash in AST: syntaxerror in complex ifs Initial Comment: Fix a bug in Python/ast.c, where a particular syntaxerror in an 'if' with one or more 'elif's would be ignored or mishandled: timberwolf:~/python/python/trunk > cat test2.py def bug(): if w: dir()=1 elif v: pass timberwolf:~/python/python/trunk > python2.4 test2.py File "test2.py", line 3 dir()=1 SyntaxError: can't assign to function call timberwolf:~/python/python/trunk > python2.5 test2.py Exception exceptions.SyntaxError: ("can't assign to function call", 3) in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection Aborted The actual problem is the lack of error checks on the return values of ast_for_expr() and ast_for_suite, in ast_for_if_stmt. Attached patch fixes. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 13:35 Message: Logged In: YES user_id=21627 Originator: NO I don't object to reformatting, if it's a single commit. It would be good if you could add Emacs magic at the end so the file keeps its formatting when edited with Emacs. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 05:20 Message: Logged In: YES user_id=1344176 Originator: NO PEP 7's section on Py3k says 4-space indents, no tabs. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 05:16 Message: Logged In: YES user_id=33168 Originator: NO It would be great to clean up the indentation in ast.c. I think I fixed it (at least made it consistent) in compile.c. Probably symtable.c could use it too. All the files that were new from the AST branch should be cleaned up and use the proper formatting we are using for 3k. I don't remember exactly what it is, but I think it's 4 space indents, but possibly still using tabs. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 05:13 Message: Logged In: YES user_id=1344176 Originator: NO Updated to apply against SVN HEAD and incorporated the additional error checking Martin pointed out. Checked in as r54404 (trunk), r54405 (release25-maint). Any objection to cleaning up ast.c's indentation? It's an ungodly mess. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-14 10:46 Message: Logged In: YES user_id=21627 Originator: NO The patch looks fine to me, please apply (or let me know if you want me to apply it). I think there are a few other places where return values of ast_for_ aren't checked: - ast_for_listcomp, not checking ast_for_expr results - ast_for_withexpr, not checking context_expr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1642547&group_id=5470 From noreply at sourceforge.net Fri Mar 16 16:50:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 08:50:19 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 05:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 16:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 09:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 16:53:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 08:53:25 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 11:53 Message: Logged In: YES user_id=6380 Originator: YES New patch, gets rid of LOAD_LOCALS and BUILD_CLASS opcodes and adds LOAD_BUILD_CLASS opcode which avoids looking for __build_class__ in the globals; it only searches the builtins (like the IMPORT statement). Though this is debatable. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Fri Mar 16 17:35:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 09:35:12 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 15:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 17:36:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 09:36:38 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 15:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 17:48:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 09:48:35 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 16:48 Message: Logged In: YES user_id=849994 Originator: NO I don't understand why you have to use **kwargs. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 15:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 17:52:37 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 09:52:37 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:52 Message: Logged In: YES user_id=1720594 Originator: YES Well, because someone on the -dev list at some point raised an objection to taking an arbitrary positional argument in as a second argument and not throwing an error. Or something like that. splitext('filename.ext', '.') would make '.' head along into preserve_dotfiles If that's not a concern, I could readily just type-check to make sure preserve_keywords is only one of (True, False) and if not raise an error. Its a "keyword-only-argument", before such a thing is in :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 16:48 Message: Logged In: YES user_id=849994 Originator: NO I don't understand why you have to use **kwargs. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 15:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Fri Mar 16 19:50:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 11:50:25 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 14:50 Message: Logged In: YES user_id=6380 Originator: YES And another. This adds a unittest for the new build_class functionality, and fixes one bug (in the way __prepare__ was called) found this way. BTW doctest rocks for this purpose. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 11:53 Message: Logged In: YES user_id=6380 Originator: YES New patch, gets rid of LOAD_LOCALS and BUILD_CLASS opcodes and adds LOAD_BUILD_CLASS opcode which avoids looking for __build_class__ in the globals; it only searches the builtins (like the IMPORT statement). Though this is debatable. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Fri Mar 16 21:07:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 13:07:16 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:07 Message: Logged In: YES user_id=6380 Originator: YES Fixed two bugs, with the help of (improved) test_metaclass.py: - bug in symtable handling of keyword args that triggered an assert in debug mode - bug in build_class that mutated the keyword args dict in place I've got the feeling that there are leaks. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 14:50 Message: Logged In: YES user_id=6380 Originator: YES And another. This adds a unittest for the new build_class functionality, and fixes one bug (in the way __prepare__ was called) found this way. BTW doctest rocks for this purpose. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 11:53 Message: Logged In: YES user_id=6380 Originator: YES New patch, gets rid of LOAD_LOCALS and BUILD_CLASS opcodes and adds LOAD_BUILD_CLASS opcode which avoids looking for __build_class__ in the globals; it only searches the builtins (like the IMPORT statement). Though this is debatable. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Fri Mar 16 21:27:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 13:27:50 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:27 Message: Logged In: YES user_id=6380 Originator: YES Fixed all library and test code I could find that used __metaclass__. The only two remaining tests (without -uall) failing are test_ast and test_compiler. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:07 Message: Logged In: YES user_id=6380 Originator: YES Fixed two bugs, with the help of (improved) test_metaclass.py: - bug in symtable handling of keyword args that triggered an assert in debug mode - bug in build_class that mutated the keyword args dict in place I've got the feeling that there are leaks. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 14:50 Message: Logged In: YES user_id=6380 Originator: YES And another. This adds a unittest for the new build_class functionality, and fixes one bug (in the way __prepare__ was called) found this way. BTW doctest rocks for this purpose. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 11:53 Message: Logged In: YES user_id=6380 Originator: YES New patch, gets rid of LOAD_LOCALS and BUILD_CLASS opcodes and adds LOAD_BUILD_CLASS opcode which avoids looking for __build_class__ in the globals; it only searches the builtins (like the IMPORT statement). Though this is debatable. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Fri Mar 16 22:16:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 14:16:04 -0700 Subject: [Patches] [ python-Patches-1676994 ] Refactor test_popen2.py to use unittest. Message-ID: Patches item #1676994, was opened at 2007-03-09 01:38 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_popen2.py to use unittest. Initial Comment: This patch turns test_popen2.py into a unittest file. There should be no changes in what the file tests. Modifying test_popen2.py to use unittest also required making a small change to popen2.py, which also contains some testing code. Lib/test/output/test_popen2 should be removed when this patch is applied. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-16 17:16 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54417. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-16 00:53 Message: Logged In: YES user_id=1727609 Originator: YES patch v2 changes: verbose = False was a bug. Removed. Folded popen2._test() moved into test_popen2 (good idea, btw). Refactored some more. ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-16 00:51 Message: Logged In: YES user_id=1727609 Originator: YES File Added: refactor_test_popen2.py.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 22:46 Message: Logged In: YES user_id=1344176 Originator: NO Why not fold popen2._test() into test_popen2? Is there a reason for the "verbose = False" assignment at the top? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676994&group_id=5470 From noreply at sourceforge.net Fri Mar 16 23:02:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 15:02:00 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-16 18:02 Message: Logged In: YES user_id=1344176 Originator: NO Ok, I'm sold on the two-phase atexit structure. I've updated my patch to keep atexit's handlers separate from the call_ll_exitfuncs() handlers. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 04:28 Message: Logged In: YES user_id=849994 Originator: YES It's not specified that exit handlers can do cleanup only, in theory they could do things like sending an email etc. Please let's not introduce gratuitous breakage here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 14:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Fri Mar 16 23:16:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 15:16:40 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 14:23 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-16 18:16 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54419. Thanks for the patch, Richard! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 04:24 Message: Logged In: YES user_id=849994 Originator: NO Since there is an "Availability" remark, I wouldn't be concerned. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 23:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 16:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 09:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 13:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 06:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 12:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 07:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 02:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Mar 16 23:36:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 15:36:30 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 22:36 Message: Logged In: YES user_id=1720594 Originator: YES I should probably not submit a patch in the *middle* of a conversation, huh? I thought it was at the point where people were just debating things like.. policy... and.. stuff. And not at a point where someone would come up a whole new idea that ties directly in. Someone did! Nick Coghlan came up with a better way to spell the whole issue, and a logical companion feature; so I just implemented the patch that way. splitext(path, ignore_leading_dot=False, all_ext=False) Also added a bunch to the test just to be anal about being sure that no combination of options would screw up the 'default' behavior. File Added: splitext-leading_dot+all_ext.patch ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:52 Message: Logged In: YES user_id=1720594 Originator: YES Well, because someone on the -dev list at some point raised an objection to taking an arbitrary positional argument in as a second argument and not throwing an error. Or something like that. splitext('filename.ext', '.') would make '.' head along into preserve_dotfiles If that's not a concern, I could readily just type-check to make sure preserve_keywords is only one of (True, False) and if not raise an error. Its a "keyword-only-argument", before such a thing is in :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 16:48 Message: Logged In: YES user_id=849994 Originator: NO I don't understand why you have to use **kwargs. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-16 15:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Sat Mar 17 00:12:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 16:12:29 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 19:12 Message: Logged In: YES user_id=6380 Originator: YES Fix syntax error in pickletester.py File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:27 Message: Logged In: YES user_id=6380 Originator: YES Fixed all library and test code I could find that used __metaclass__. The only two remaining tests (without -uall) failing are test_ast and test_compiler. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:07 Message: Logged In: YES user_id=6380 Originator: YES Fixed two bugs, with the help of (improved) test_metaclass.py: - bug in symtable handling of keyword args that triggered an assert in debug mode - bug in build_class that mutated the keyword args dict in place I've got the feeling that there are leaks. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 14:50 Message: Logged In: YES user_id=6380 Originator: YES And another. This adds a unittest for the new build_class functionality, and fixes one bug (in the way __prepare__ was called) found this way. BTW doctest rocks for this purpose. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 11:53 Message: Logged In: YES user_id=6380 Originator: YES New patch, gets rid of LOAD_LOCALS and BUILD_CLASS opcodes and adds LOAD_BUILD_CLASS opcode which avoids looking for __build_class__ in the globals; it only searches the builtins (like the IMPORT statement). Though this is debatable. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Sat Mar 17 05:13:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 21:13:09 -0700 Subject: [Patches] [ python-Patches-672656 ] securing pydoc server Message-ID: Patches item #672656, was opened at 2003-01-22 19:45 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Altis (kasplat) Assigned to: Ka-Ping Yee (ping) Summary: securing pydoc server Initial Comment: It would be very simple to secure the pydoc server so that it doesn't accept connections from external boxes as well as provide for a way of extending connections to trusted hosts by keeping a list of valid IP addresses. This would make pydoc suitable for running on boxes that aren't behind firewalls, which currently it is not; most home machines don't have a firewall and are regularly port scanned by script kiddies... Since pydoc does not log connections, you can't tell who is connecting to your machine or what they are trying to reach. My solution is to simply make the default pydoc server only accept connections from the host it was started on. The change is for the DocServer class. a validIPList keeps track of the IP addresses that can legally connect to the server. The verify_request method is overridden to enforce this rule. import socket self.validIPList = ['127.0.0.1'] self.validIPList.append(socket.gethostbyname (socket.gethostname())) def verify_request(self, request, client_address): if client_address[0] in self.validIPList: return 1 else: return 0 This patch does not provide a UI change to allow the user to easily add additional IP addresses. If that is desired because of the assumption that people typically run the pydoc server not for personal use, but for a group of machines to reach, then the simplest change would be to have a checkbox for "Allow any host to connect" and then have a self.allowAny member variable to reflect that checkbox state, so the verify_request becomes def verify_request(self, request, client_address): if self.allowAny or client_address[0] in self.validIPList: return 1 else: return 0 ka ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-17 04:13 Message: Logged In: YES user_id=1720594 Originator: NO I think this is actually a good idea; but I don't think the implementation is really sufficient as it stands. Particularly, it's going to require that someone hand edit a file in Lib to adjust the behavior from the "default" of only allowing connections from localhost. A user interface is not required, but an easy to reach configuration file is, I think. Instead, I think it should read a pydoc.cfg ConfigParser file-- and just apply the defaults if said file doesn't exist. (Where to put it? I don't know. ~/pydoc.cfg?) Also, having to list specific IP addresses is going to greatly limit utility for those people who do want it more open. Some people might want to allow everyone in their subnet to access it, instead of just 'everyone' or 'specific people' as this patch implies. I don't think there's an easy way to do CIDR math in the Python library, but a simple regex in said configuration file would be plenty I imagine. Or even a list of strings you check to see if the ip address startswith. In the current form, I'd recommend rejection. I don't know if the submitter is interested in any major updates after a few years, but if they are.. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470 From noreply at sourceforge.net Sat Mar 17 05:47:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 16 Mar 2007 21:47:27 -0700 Subject: [Patches] [ python-Patches-1165404 ] ConfigParser alternative key-value delimitier Message-ID: Patches item #1165404, was opened at 2005-03-17 16:57 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1165404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergey Dorofeev (fidoman) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser alternative key-value delimitier Initial Comment: ConfigParser is module which parses commonly used INI files. It gets sections from file and values from sections. By now, it gets from file key and value divided by symbol ":" or "=". For FTN application, a want to use FTN addresses as keys. FTN address looks like "2:5020/12000". So if I try to use it as key, ConfigParser considers "2" as key and "5020/12000 = ..." as value. I made patch, which allows to use any set of symbols (or '=' and ':' by default for compatibility) as delimitier between key and value in INI file. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-17 04:47 Message: Logged In: YES user_id=1720594 Originator: NO I think the basis of this patch is a good one; I think 'delimiter' should be plural as delimiters, but that might be all picky. :) I don't think "self.delimmap = map(lambda x: x, self.delim)" should be done; map and lambda aren't needed here. Wouldn't it be cleaner to just accept a list and join it instead? More Pythonic? Since delimiter=":=" to me looks like you want the string ":=" to be a delimiter, but I might be having pascal flashbacks. To me its more clear. E.g.: def __init__(self, defaults=None, delimiters=(':', '=')): self._delimiters = ''.join(delimiters) As stated below, you don't need delimmap; "if vi in self.delim" will work fine. Anyways, all that aside (and that's just opinions, but--): 1) The patch no longer applies cleanly to the HEAD. I believe it would be very straightforward to fix the patch up though. 2) It needs documentation, and 3) It definitely needs tests added to test_cfgparser. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 06:23 Message: Logged In: YES user_id=33168 Originator: NO Note: delimmap doesn't look like it's needed. Should be able to just check if vi in self.delim. (Although I'm kinda tired and don't feel like thinking too hard, so maybe that's just bs.). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1165404&group_id=5470 From noreply at sourceforge.net Sat Mar 17 16:31:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 08:31:46 -0700 Subject: [Patches] [ python-Patches-1680959 ] Add tests for pipes module (test_pipes) Message-ID: Patches item #1680959, was opened at 2007-03-14 14:48 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Collin Winter (collinwinter) Summary: Add tests for pipes module (test_pipes) Initial Comment: The attached file contains a patch to: - remove the "just import it" test for pipes from test_sundry.py - add test_pipes to expected skips on win32 in regrtest.py - remove the "small test program and example" from pipes.py (it seems to me this is best put in either tests or docs instead of the module itself) It also includes a new test_pipes.py module. At the moment this covers about 86% of the pipes.py code; I'll try to get that higher, but I wanted to throw this out there for initial feedback. ---------------------------------------------------------------------- >Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-17 10:31 Message: Logged In: YES user_id=1115903 Originator: YES I adjusted things to conform to PEP 8 (I hope), changed the exists/unlink as suggested, ran reindent.py on test_pipes.py, and included test_pipes.py in the patch. File Added: pipes-tests-2.diff ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:40 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your patch! Initial comments: * test_pipes does not conform to PEP 8 (whitespace issues, line length, etc). * SVN reports that test_pipes has inconsistent line endings. * Calling os.path.exists() as a check before os.unlink() creates a race condition; just catch the exception. * In the future, please include new files in the patch itself. "svn add" the file, then "svn diff" will include it when creating the diff. Please address these issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680959&group_id=5470 From noreply at sourceforge.net Sat Mar 17 16:49:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 08:49:32 -0700 Subject: [Patches] [ python-Patches-1682205 ] TypeError swallowing in UNPACK_SEQUENCE opcode Message-ID: Patches item #1682205, was opened at 2007-03-16 15:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) >Summary: TypeError swallowing in UNPACK_SEQUENCE opcode Initial Comment: When UNPACK_SEQUENCE unpacks an iterable, it replaces any TypeError raised by the iterator with a new, catch-all TypeError('unpack non-sequence') instance (and empty traceback). This message is less useful than the ones it's (presumably) intended to replace (raised by PyObject_GetIter(), via unpack_iterable()), and obviously wrong when the TypeError originates in unrelated user code. The attached patch simply removes the check, which (as far as i can tell) has no ill effects. Examples (without the patch): >>> a, b, c = 7 TypeError: unpack non-sequence >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: unpack non-sequence With the patch applied, these result in: >>> a, b, c = 7 TypeError: 'int' object is not iterable >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: int() argument must be a string or a number, not 'tuple' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:49 Message: Logged In: YES user_id=849994 Originator: NO It's patch, after all :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682205&group_id=5470 From noreply at sourceforge.net Sat Mar 17 16:53:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 08:53:26 -0700 Subject: [Patches] [ python-Patches-1675423 ] Make PyComplex_AsCComplex use __complex__ Message-ID: Patches item #1675423, was opened at 2007-03-07 03:03 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Georg Brandl (gbrandl) Summary: Make PyComplex_AsCComplex use __complex__ Initial Comment: The functions in the math module have the (pleasantly) surprising and apparently undocumented property that they'll accept not just floats, but any Python object having a float method: >>> class test1(object): ... def __float__(self): ... return 3. ... >>> from math import sqrt >>> sqrt(test1()) 1.7320508075688772 Based on this, one might expect the functions in the complex math module cmath to have the same property with respect to __complex__. But this isn't so: >>> class test2(object): ... def __complex__(self): ... return -3 + 0j ... >>> from cmath import sqrt as csqrt >>> csqrt(test2()) Traceback (most recent call last): File "", line 1, in TypeError: a float is required The real surprise is that the cmath functions *will* call the __float__ method, if it's available: >>> csqrt(test1()) (1.7320508075688772+0j) This patch expands the PyComplex_AsCComplex method so that it looks for a __complex__ method before looking for the __float__ method. This `fixes' the above behaviour. Should it be a documented feature that the math functions will make use of __float__? If so, and if the patched behaviour seems desirable, I'll add suitable tests to test_math and test_cmath. ---------------------------------------------------------------------- >Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-17 15:53 Message: Logged In: YES user_id=703403 Originator: YES File Added: complex_patch.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:47 Message: Logged In: YES user_id=849994 Originator: NO Please include both old-style and new-style classes in the test case, and for each one test if the check for a complex return from __complex__ works. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:38 Message: Logged In: YES user_id=849994 Originator: NO I think it is the right thing to do. Test cases would be welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:09:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:09:34 -0700 Subject: [Patches] [ python-Patches-1675423 ] Make PyComplex_AsCComplex use __complex__ Message-ID: Patches item #1675423, was opened at 2007-03-07 03:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Mark Dickinson (marketdickinson) Assigned to: Georg Brandl (gbrandl) Summary: Make PyComplex_AsCComplex use __complex__ Initial Comment: The functions in the math module have the (pleasantly) surprising and apparently undocumented property that they'll accept not just floats, but any Python object having a float method: >>> class test1(object): ... def __float__(self): ... return 3. ... >>> from math import sqrt >>> sqrt(test1()) 1.7320508075688772 Based on this, one might expect the functions in the complex math module cmath to have the same property with respect to __complex__. But this isn't so: >>> class test2(object): ... def __complex__(self): ... return -3 + 0j ... >>> from cmath import sqrt as csqrt >>> csqrt(test2()) Traceback (most recent call last): File "", line 1, in TypeError: a float is required The real surprise is that the cmath functions *will* call the __float__ method, if it's available: >>> csqrt(test1()) (1.7320508075688772+0j) This patch expands the PyComplex_AsCComplex method so that it looks for a __complex__ method before looking for the __float__ method. This `fixes' the above behaviour. Should it be a documented feature that the math functions will make use of __float__? If so, and if the patched behaviour seems desirable, I'll add suitable tests to test_math and test_cmath. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 16:09 Message: Logged In: YES user_id=849994 Originator: NO OK, thank you! Committed the patch, new tests and docs in rev. 54421. ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-17 15:53 Message: Logged In: YES user_id=703403 Originator: YES File Added: complex_patch.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:47 Message: Logged In: YES user_id=849994 Originator: NO Please include both old-style and new-style classes in the test case, and for each one test if the check for a complex return from __complex__ works. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 13:38 Message: Logged In: YES user_id=849994 Originator: NO I think it is the right thing to do. Test cases would be welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675423&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:12:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:12:54 -0700 Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to random Message-ID: Patches item #1681432, was opened at 2007-03-15 13:09 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wladmir van der Laan (miathan6) Assigned to: Nobody/Anonymous (nobody) Summary: Add triangular distribution to random Initial Comment: This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly. http://en.wikipedia.org/wiki/Triangular_distribution ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-17 16:12 Message: Logged In: YES user_id=1740099 Originator: NO Some minor quibbles: the distributions in random name their parameters after the most common use in math text books. Is n't that 'a, b, c' here rather than 'left, right, center' (note, different order too)? Admittedly your parameter names are clearer. There's not total consistency in random, but it looks like 'triangularvariate' would be the right name for the function - although my knowledge of stats is sketchy, so perhaps there's a distinction I'm not aware of. Indentation and spacing around operators needs fixing also. ---------------------------------------------------------------------- Comment By: Wladmir van der Laan (miathan6) Date: 2007-03-16 08:57 Message: Logged In: YES user_id=49336 Originator: YES Yes, I will add some tests and docs, although usage is quite straightforward. That's the main reason also for adding this distribution, it has three parameters which are intuitive (left, center and right) the distribution is just a linear interpolation (P(left)=0 and P(center)=1 and P(right)=0 ). I am writing an event simulation and I added it because I was missing some kind of assymetric distribution for timings; in an uniform distribution t-x and t+y would be just as likely as t, in a gaussian distribution you can only set sigma but not the upper and lower bound. With all the other distributions in there I thought it might come in handy for other people too. I also believe it has its uses in sound generation/processing. Sorry for providing a patch against 2.3 and not 2.5 or higher, I cooked it up at work and it seems I have this ancient version here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 02:22 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up some tests (Lib/test/test_random.py) and docs (Doc/lib/librandom.tex) for this? An explanation of why you think this should be included in the standard library would be helpful, too. Also, it seems you made this patch against Python 2.3. While this particular patch still applied (relatively) cleanly to Python 2.6a0 source, Python 2.3 is no longer supported and most patches made against it have a high probability of inapplicability. See http://www.python.org/dev/faq/ for information on how to obtain a read-only checkout of the latest source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:14:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:14:59 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 16:14 Message: Logged In: YES user_id=849994 Originator: YES Looks good, four points: - should _clear keep its underscore? - unregistering will fail with bound methods, don't know if we should do something about that - you messed up the indentation in pythonrun.c and atexit.c (spaces in the former and tabs in the latter) ;) - do we need docs for Py_PyAtExit? If not, it should be nonpublic and get a leading underscore. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 22:02 Message: Logged In: YES user_id=1344176 Originator: NO Ok, I'm sold on the two-phase atexit structure. I've updated my patch to keep atexit's handlers separate from the call_ll_exitfuncs() handlers. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:28 Message: Logged In: YES user_id=849994 Originator: YES It's not specified that exit handlers can do cleanup only, in theory they could do things like sending an email etc. Please let's not introduce gratuitous breakage here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 18:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:23:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:23:52 -0700 Subject: [Patches] [ python-Patches-1652328 ] stream writing support in wave.py Message-ID: Patches item #1652328, was opened at 2007-02-05 11:45 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1652328&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: tom (tom375) Assigned to: Nobody/Anonymous (nobody) Summary: stream writing support in wave.py Initial Comment: allows wave files to be written to non-seekable file descriptors ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-17 16:23 Message: Logged In: YES user_id=1740099 Originator: NO The code ignores exceptions thrown during seeks and tells, skipping operations in the process. I can't see how this makes the written wave file correct. I would say this patch should be rejected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1652328&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:54:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:54:29 -0700 Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to random Message-ID: Patches item #1681432, was opened at 2007-03-15 13:09 Message generated for change (Comment added) made by marketdickinson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wladmir van der Laan (miathan6) Assigned to: Nobody/Anonymous (nobody) Summary: Add triangular distribution to random Initial Comment: This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly. http://en.wikipedia.org/wiki/Triangular_distribution ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-17 16:54 Message: Logged In: YES user_id=703403 Originator: NO Looks correct to me, and seems to work well with correct parameters. The arguments to the square roots are never negative; this means that we get silent failure (that is, some distribution that isn't the triangular distribution) if the input parameters don't satisfy left <= center <= right. Maybe the inputs should be checked, and a ValueError raised on bad input? If the test "x < (center-left)/(right-left)" is replaced by "x*(right-left) < (center - left)" then the code does the right thing in the limit-case when left == center == right (that is, it gives a delta distribution at center); currently it'll raise a ZeroDivisionError in this case. It's not clear to me which behaviour should be preferred. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-17 16:12 Message: Logged In: YES user_id=1740099 Originator: NO Some minor quibbles: the distributions in random name their parameters after the most common use in math text books. Is n't that 'a, b, c' here rather than 'left, right, center' (note, different order too)? Admittedly your parameter names are clearer. There's not total consistency in random, but it looks like 'triangularvariate' would be the right name for the function - although my knowledge of stats is sketchy, so perhaps there's a distinction I'm not aware of. Indentation and spacing around operators needs fixing also. ---------------------------------------------------------------------- Comment By: Wladmir van der Laan (miathan6) Date: 2007-03-16 08:57 Message: Logged In: YES user_id=49336 Originator: YES Yes, I will add some tests and docs, although usage is quite straightforward. That's the main reason also for adding this distribution, it has three parameters which are intuitive (left, center and right) the distribution is just a linear interpolation (P(left)=0 and P(center)=1 and P(right)=0 ). I am writing an event simulation and I added it because I was missing some kind of assymetric distribution for timings; in an uniform distribution t-x and t+y would be just as likely as t, in a gaussian distribution you can only set sigma but not the upper and lower bound. With all the other distributions in there I thought it might come in handy for other people too. I also believe it has its uses in sound generation/processing. Sorry for providing a patch against 2.3 and not 2.5 or higher, I cooked it up at work and it seems I have this ancient version here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 02:22 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up some tests (Lib/test/test_random.py) and docs (Doc/lib/librandom.tex) for this? An explanation of why you think this should be included in the standard library would be helpful, too. Also, it seems you made this patch against Python 2.3. While this particular patch still applied (relatively) cleanly to Python 2.6a0 source, Python 2.3 is no longer supported and most patches made against it have a high probability of inapplicability. See http://www.python.org/dev/faq/ for information on how to obtain a read-only checkout of the latest source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 From noreply at sourceforge.net Sat Mar 17 17:55:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 09:55:16 -0700 Subject: [Patches] [ python-Patches-1526367 ] str.__iter__ and unicode.__iter__ Message-ID: Patches item #1526367, was opened at 2006-07-21 11:39 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Walter D?rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: str.__iter__ and unicode.__iter__ Initial Comment: This patch add iterator classes for str and unicode, as discussed here: http://mail.python.org/pipermail/python-3000/2006-July/002650.html ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2007-03-17 17:55 Message: Logged In: YES user_id=89016 Originator: YES Code coverage is pretty good without any new tests (see ) The only function uncovered is unicodeiter_len (striter_len). I've added a test for this to the new version of the patch (diff2.txt). File Added: diff2.txt ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 20:41 Message: Logged In: YES user_id=849994 Originator: NO This looks good, but needs new tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 From noreply at sourceforge.net Sat Mar 17 18:09:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 10:09:24 -0700 Subject: [Patches] [ python-Patches-1681432 ] Add triangular distribution to random Message-ID: Patches item #1681432, was opened at 2007-03-15 13:09 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wladmir van der Laan (miathan6) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add triangular distribution to random Initial Comment: This patch adds the so called Triangular distribution for random values. It is often used in simulations when an upper and lower bound is known, and a most likely value but not the exact distribution. This distribution interpolates these values linearly. http://en.wikipedia.org/wiki/Triangular_distribution ---------------------------------------------------------------------- Comment By: Mark Dickinson (marketdickinson) Date: 2007-03-17 16:54 Message: Logged In: YES user_id=703403 Originator: NO Looks correct to me, and seems to work well with correct parameters. The arguments to the square roots are never negative; this means that we get silent failure (that is, some distribution that isn't the triangular distribution) if the input parameters don't satisfy left <= center <= right. Maybe the inputs should be checked, and a ValueError raised on bad input? If the test "x < (center-left)/(right-left)" is replaced by "x*(right-left) < (center - left)" then the code does the right thing in the limit-case when left == center == right (that is, it gives a delta distribution at center); currently it'll raise a ZeroDivisionError in this case. It's not clear to me which behaviour should be preferred. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-17 16:12 Message: Logged In: YES user_id=1740099 Originator: NO Some minor quibbles: the distributions in random name their parameters after the most common use in math text books. Is n't that 'a, b, c' here rather than 'left, right, center' (note, different order too)? Admittedly your parameter names are clearer. There's not total consistency in random, but it looks like 'triangularvariate' would be the right name for the function - although my knowledge of stats is sketchy, so perhaps there's a distinction I'm not aware of. Indentation and spacing around operators needs fixing also. ---------------------------------------------------------------------- Comment By: Wladmir van der Laan (miathan6) Date: 2007-03-16 08:57 Message: Logged In: YES user_id=49336 Originator: YES Yes, I will add some tests and docs, although usage is quite straightforward. That's the main reason also for adding this distribution, it has three parameters which are intuitive (left, center and right) the distribution is just a linear interpolation (P(left)=0 and P(center)=1 and P(right)=0 ). I am writing an event simulation and I added it because I was missing some kind of assymetric distribution for timings; in an uniform distribution t-x and t+y would be just as likely as t, in a gaussian distribution you can only set sigma but not the upper and lower bound. With all the other distributions in there I thought it might come in handy for other people too. I also believe it has its uses in sound generation/processing. Sorry for providing a patch against 2.3 and not 2.5 or higher, I cooked it up at work and it seems I have this ancient version here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 02:22 Message: Logged In: YES user_id=1344176 Originator: NO Could you work up some tests (Lib/test/test_random.py) and docs (Doc/lib/librandom.tex) for this? An explanation of why you think this should be included in the standard library would be helpful, too. Also, it seems you made this patch against Python 2.3. While this particular patch still applied (relatively) cleanly to Python 2.6a0 source, Python 2.3 is no longer supported and most patches made against it have a high probability of inapplicability. See http://www.python.org/dev/faq/ for information on how to obtain a read-only checkout of the latest source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681432&group_id=5470 From noreply at sourceforge.net Sat Mar 17 22:46:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 14:46:00 -0700 Subject: [Patches] [ python-Patches-664020 ] telnetlib option subnegotiation fix Message-ID: Patches item #664020, was opened at 2003-01-07 21:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664020&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Steve Reeves (sreeves) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib option subnegotiation fix Initial Comment: The telnetlib patch #630829 (committed as v1.20) for option subnegotiation doesn't work as-is. There are several problems. 1) The option negotiation callback should be a method of the Telnet class, not a separate function. The callback is supposed to call the read_sb_data method when it receives SB or SE, but of which object? I think the callback should have been a method all along. It should be able to change the object's state based on the negotiation. Generally when implementing a new protocol extension, you'll subclass Telnet, add the new behavior, and then have the callback set a flag in the object to activate the new behavior after it has been negotiated. The default DONT/WONT behavior can be moved out of the depths of process_rawq() into the callback method. Subclasses can then just forward to the parent class when they get an option they don't care about, instead of having to reimplement the default behavior. If the callback is a method, the socket argument is still available as self.sock. The set_option_negotiation_callback method and the checks for "if self.option_callback:" would not be needed. Changing the callback to a method will break compatibility with Python 2.2, however. 2) On receipt of SB and SE, the callback is always called with NOOPT. The option is never passed. (It actually gets stored as the first part of the parameter data and returned by read_sb_data().) 3) The callback is called on the receipt of both SB _and_ SE. The SB call is completely superfluous. The option and parameter data have not been read yet, so there is nothing for the callback to do. The attached patch fixes these and adds support for the NOP command. It also includes documentation changes and an example of implementing some options. Some other thoughts: The name "option_callback" is a little misleading. The callback is executed in response to all telnet protocol commands, not just the ones dealing with options. Why define and pass NOOPT for the case when there is no option rather than use None? The only place the SB parameter data will (can safely?) be used is in the callback. Why not pass it as another optional parameter and skip the need for read_sb_data()? A potential name conflict: the EOR telnet option defines a new command code also called EOR (with a much different numeric value). The C header file <arpa/telnet.h> prefixes all the options with TELOPT_, so there is no conflict there, but telnetlib drops the prefix. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 21:45 Message: Logged In: YES user_id=849994 Originator: NO Superseded by #1678077. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 00:16 Message: Logged In: YES user_id=51702 Originator: NO This patch is very similar to #1520081. They both suggest replacing set_option_negotiation_callback with a method on the Telnet object which I think makes perfect sense. They both contain big and useful updates to the documentation. This patch also contain a useful refactoring of the process_rawq() method. I think a merged patch of them both should be applied. But IMHO, it should wait to Py3k because then API can be broken and then set_option_negotiation_callback can be eliminated. ---------------------------------------------------------------------- Comment By: Steve Reeves (sreeves) Date: 2003-01-07 21:57 Message: Logged In: YES user_id=2647 Sorry, the patch wasn't uploaded for some reason. Trying again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=664020&group_id=5470 From noreply at sourceforge.net Sat Mar 17 22:46:40 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 14:46:40 -0700 Subject: [Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling. Message-ID: Patches item #1520081, was opened at 2006-07-10 16:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Ernest ter Kuile (ernestjwtk) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.py change to ease option handling. Initial Comment: Telnetlib.py has no automatic telnet option handling mechanism except for the possibility to register a callback function. If set, the callback is used for each option as they arrive. If not set, options are negated. Using this mechanisme is not elegant when extending the telnet class in a OO way, and there is currently no other way to handle this data. This patch adds to the callback mechanisme by also calling an internal function handle_option(), which by default doesn't do much. This function could then do something usefull when extending the telnet class. For backwards compatibility, the current callback mechanism has not been removed, and, if used, has priority over the internal function handle_option(), which is then ignored. Furthermore to explain the telnet option system, a lot of comments have been added. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 21:46 Message: Logged In: YES user_id=849994 Originator: NO Superseded by sonderblade's patch at #1678077. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2007-03-11 00:04 Message: Logged In: YES user_id=1552811 Originator: YES sonderblade: I just noticed your new patch and submission. Looks good at first glance. I'll keep my current patch for myself as I don't think Python 3 will come out just yet, But I'll gladly use your version when it does. I too think it best to get rid of the callback mechanism for the reasons described below, but since I didn't want to be too radical I only added to it. Cheers, Ernest. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2007-03-10 23:13 Message: Logged In: YES user_id=1552811 Originator: YES Wel it does, and this is why I needed it. For me it added two very important things: 1) it adds the possibility to create a descendant of the telnet class which can handle the options. Without this, the callback mechanism must always be handled externaly to the telnet object itself. 2) And since the callback has no concept of self (missing parameters) it adds the possibility to have more than one instance of the telnet class which did not need a different version of the callback function each time. I needed about 6 instances (one for each system I had to reach), so had to provide 6 _different_ callback functions. (This showed to me that the callback way of doing was totally broken) I wanted to (and did) encapsulate the telnet object with something which itself could provide the knowlege of handling some of the options (in fact a telnet 3270, which is a special case of the telnet protocol). This would have been very much harder to do without being able to handle the options within the objet. Sorry if I wasn't clear. Ernest. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:48 Message: Logged In: YES user_id=51702 Originator: NO Since this feature does not add something and is just a new way to do something that was already possible, maybe it can wait until py3k? I think having a handle_option() method is clearly a cleaner design than having a callback. But the advantage is not that great and in py3k you could break the api and replace the old method with the new one. ---------------------------------------------------------------------- Comment By: Ernest ter Kuile (ernestjwtk) Date: 2006-07-10 17:09 Message: Logged In: YES user_id=1552811 Changed Category to be Library instead of Modules. Telnetlib.py is not a module (sorry for confusion) Also attached is diff to latest svn telnetlib had some timeout patch had been applied. (as of 10 july) Actually, first look shows no difference between this one and the previous one, but just to be sure. Ernest ter Kuile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 From noreply at sourceforge.net Sat Mar 17 22:47:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 14:47:01 -0700 Subject: [Patches] [ python-Patches-1678077 ] improve telnetlib.Telnet so option negotiation becomes easie Message-ID: Patches item #1678077, was opened at 2007-03-10 22:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: improve telnetlib.Telnet so option negotiation becomes easie Initial Comment: This patch is a merger of #664020 (telnetlib option subnegotiation fix) and #1520081 (telnetlib.py change to ease option handling) which are both outdated. The purpose of it is to replace the set_option_negotiation_callback with a handle_option method that subclasses can reimplement. This should make it much easier to implement custom option negotiation handling. The patch also extends the documentation somewhat to make it clearer how to to implement custom option subnegotiation. It breaks compatibility with earlier Pythons because it removes set_option_negotiation_callback. But I think it should be good to apply it for Python 3.0. See the referenced patches for many more details. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 21:47 Message: Logged In: YES user_id=849994 Originator: NO Closed the other two patches as "superseded by this one". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678077&group_id=5470 From noreply at sourceforge.net Sat Mar 17 23:20:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 15:20:54 -0700 Subject: [Patches] [ python-Patches-1682878 ] Python 2.5 "What's New" document contains socket errors Message-ID: Patches item #1682878, was opened at 2007-03-17 18:20 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=1682878&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 "What's New" document contains socket errors Initial Comment: http://docs.python.org/whatsnew/modules.html talks about two new socket methods, recv_buf(buffer) and recvfrom_buf(buffer). I suppose it means to be talking about recv_into and recvfrom_into. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682878&group_id=5470 From noreply at sourceforge.net Sun Mar 18 02:54:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 18:54:47 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-17 21:54 Message: Logged In: YES user_id=1344176 Originator: NO - I think _clear() should keep the underscore; it's probably not something that people should be encouraged to use. - I've fixed bound method support. - I'm going to make Py_PyAtExit non-public. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 12:14 Message: Logged In: YES user_id=849994 Originator: YES Looks good, four points: - should _clear keep its underscore? - unregistering will fail with bound methods, don't know if we should do something about that - you messed up the indentation in pythonrun.c and atexit.c (spaces in the former and tabs in the latter) ;) - do we need docs for Py_PyAtExit? If not, it should be nonpublic and get a leading underscore. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 18:02 Message: Logged In: YES user_id=1344176 Originator: NO Ok, I'm sold on the two-phase atexit structure. I've updated my patch to keep atexit's handlers separate from the call_ll_exitfuncs() handlers. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 04:28 Message: Logged In: YES user_id=849994 Originator: YES It's not specified that exit handlers can do cleanup only, in theory they could do things like sending an email etc. Please let's not introduce gratuitous breakage here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 14:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Sun Mar 18 03:54:57 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 19:54:57 -0700 Subject: [Patches] [ python-Patches-1682942 ] ConfigParser support for alt delimiters Message-ID: Patches item #1682942, was opened at 2007-03-18 02:54 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=1682942&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser support for alt delimiters Initial Comment: This patch is in response to 1165404, which I was reviewing. It turns out I actually rather like the idea, since it would have made my life easier in a current project to not have to totally roll my own ConfigParser to read an external configuration file. So! I updated the previous patch to apply against the current HEAD, and then added some documentation and test cases (and made sure it didn't break existing test cases) I did alter the previously proposed API a touch too; 'delimiters' instead of 'delimiter' as its taking a list, and to actually take a sequence instead of a string containing characters because IMHO it just looks cleaner. Passing in ":=" as indicating either : or = are delimiters looks odd ot me (Hi, Pascal), it looks like it'd make the _string_ of ":=" the delimiter. I also adjusted the names slightly to fit into the style of the module. ('_delimiter' instead of 'delim'). I also updated the docstring on the module to document dict_type being an option (it wasn't before) My text editor seems to think the documentation is OK LaTeX-- but until uh, two days ago, I never touched LaTeX, so someone should eye that :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682942&group_id=5470 From noreply at sourceforge.net Sun Mar 18 03:56:49 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 19:56:49 -0700 Subject: [Patches] [ python-Patches-1165404 ] ConfigParser alternative key-value delimitier Message-ID: Patches item #1165404, was opened at 2005-03-17 16:57 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1165404&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sergey Dorofeev (fidoman) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser alternative key-value delimitier Initial Comment: ConfigParser is module which parses commonly used INI files. It gets sections from file and values from sections. By now, it gets from file key and value divided by symbol ":" or "=". For FTN application, a want to use FTN addresses as keys. FTN address looks like "2:5020/12000". So if I try to use it as key, ConfigParser considers "2" as key and "5020/12000 = ..." as value. I made patch, which allows to use any set of symbols (or '=' and ':' by default for compatibility) as delimitier between key and value in INI file. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-18 02:56 Message: Logged In: YES user_id=1720594 Originator: NO It actually turns out this patch would make *my* life easier, so instead of leaving it to the original submitter to make current and add stuff to, I modified it and added docs and tests as 1682942. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-17 04:47 Message: Logged In: YES user_id=1720594 Originator: NO I think the basis of this patch is a good one; I think 'delimiter' should be plural as delimiters, but that might be all picky. :) I don't think "self.delimmap = map(lambda x: x, self.delim)" should be done; map and lambda aren't needed here. Wouldn't it be cleaner to just accept a list and join it instead? More Pythonic? Since delimiter=":=" to me looks like you want the string ":=" to be a delimiter, but I might be having pascal flashbacks. To me its more clear. E.g.: def __init__(self, defaults=None, delimiters=(':', '=')): self._delimiters = ''.join(delimiters) As stated below, you don't need delimmap; "if vi in self.delim" will work fine. Anyways, all that aside (and that's just opinions, but--): 1) The patch no longer applies cleanly to the HEAD. I believe it would be very straightforward to fix the patch up though. 2) It needs documentation, and 3) It definitely needs tests added to test_cfgparser. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 06:23 Message: Logged In: YES user_id=33168 Originator: NO Note: delimmap doesn't look like it's needed. Should be able to just check if vi in self.delim. (Although I'm kinda tired and don't feel like thinking too hard, so maybe that's just bs.). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1165404&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:13:19 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:13:19 -0700 Subject: [Patches] [ python-Patches-1410680 ] Add 'surgical editing' to ConfigParser Message-ID: Patches item #1410680, was opened at 2006-01-21 00:12 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'surgical editing' to ConfigParser Initial Comment: See also: [ 1399309 ] ConfigParser to save with order [ 1371075 ] ConfigParser to accept a custom dict to allow ordering The attached patch adds a new method, update_file, to RawConfigParser. This method is similar to the existing write method, but preserves blank lines, comments, and ordering, as requested many times on python-dev and python-list. These are the three requirements that Guido specified in January 2005. IMO the attached patch is better than 1399309 because it includes all the functionality (passing a pointer to an empty file results in a sorted write() output), but is completely backwards compatible as write() is unchanged. The addition of preserving comments is also essential for many applications. IMO the attached patch is better than 1371075 because the latter really requires a custom class (e.g. the third party one suggested) in order to be useful. It also doesn't address the issue of preserving comments. The attached patch is essentially a tidied up version of the one included with SpamBayes (in the OptionClass.py module), which is used extensively within SpamBayes (and has been for several years). Also attached are additional unittests for the new method, and a documentation patch. Please let me know if there are recommended changes. This patch does not address any of the additional ConfigParser improvements that have been suggested at various times. ---------------------------------------------------------------------- >Comment By: Tony Meyer (anadelonbrin) Date: 2007-03-18 15:13 Message: Logged In: YES user_id=552329 Originator: YES I assume that Paul meant 1371075 and not 131075 was accepted. 1371075 didn't do what Guido wanted at the time this patch was opened (or have documentation or unit tests), but I guess opinion has changed over time. There is incomplete overlap between that patch and this. This patch is really about being able to modify a configuration file 'in place', without losing the ordering or (importantly) comments. 1371075 provides the first (if you write/find an appropriate ordered dict), but not the second. However, it seems unlikely that merely preserving comments is enough to make this change worthwhile. I have no problem with it being rejected or being subsumed into some other patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2007-03-08 02:41 Message: Logged In: YES user_id=113328 Originator: NO I've looked at the patches attached here. They look reasonable, and in isolation I would be happy for them to be accepted, although I have no personal use for the functionality. However, patch 131075 (ConfigParser to accept a custom dict to allow ordering) has since been accepted, and in the light of that, this patch may no longer be appropriate. From the descriptions, and a review of the code, I am not clear how the two are related. The justification should be updated to reflect the fact that patch 131075 has been accepted - or if there is no longer sufficient justification for what may well be a second way to do the same thing, then this patch should be withdrawn. I have looked at Scott Dial's updated patches, but I am not clear on what they add. There has obviously been some discussion which happened off the tracker - as a result I can't comment on the DEFAULTSECT issue. The whitespace stripping issue needs a clearer description. I don't see what is happening here. One or other of the patches is presumably mishandling leading or trailing whitespace in options, but I can't tell which. The "growing blank lines" fix sounds sensible. Recommendation: 1. The OP should review the justification in the light of the acceptance of patch 1371075. 2. Scott should clarify the issues around the 2 areas I mentioned. 3. An updated patch should be submitted, either by the OP against this tracker, or by someone else (Scott, perhaps) under a new tracker item, pointing back to this one. Otherwise, I would recommend rejection on the grounds that the functionality now appears to be available via the acceptance of 1371075 (albeit in a form that this patch claims is inferior). Paul Moore ---------------------------------------------------------------------- Comment By: Scott Dial (geekmug) Date: 2006-06-08 19:15 Message: Logged In: YES user_id=383208 Before I lose track of the updated patches I made.. They can be found here: http://scottdial.com/python-dev/ConfigParser.diff http://scottdial.com/python-dev/test_cfgparser.diff The notes I emailed Tony were: * I have modified the OPTCRE matching to not just throw away the whitespace after a [=:]. Second, I have modified the opt.rstrip(), again so that the whitespace isn't just thrown away. A new variable padded_vi then appears which is a formatting-preserved version of vi. * I have removed at least one erroneous write('\n'), and changed the pattern for adding newlines to missing sections, such that the newlines are added /before/ the section heading (and only if there are lines appearing before). These together solve the growing blank lines phenomena. * I have modified the add_missing section to deal with DEFAULTSECT appropriately. Which solves the appearing/disappearing act that I had mentioned. * I have updated the test's to match the new expected output. --- And in reponse to Jim's comment, such a feature is not in the scope of the patch. The patch is to explicitly leave things the way they are, so any sort of sorting would make no sense. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-21 04:11 Message: Logged In: YES user_id=764593 Wanting to keep the whole thing (except defaultsection) in sorted order will probably be a common use case. It sounds like you can do this by "updating" to an empty file, but it isn't the obvious solution. Could you either add an option to sort the whole thing (so inserts may not be at the end) or an explicit mention in the docstring of how to get this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1410680&group_id=5470 From noreply at sourceforge.net Sun Mar 18 04:57:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 17 Mar 2007 20:57:41 -0700 Subject: [Patches] [ python-Patches-1673759 ] '%G' string formatting doesn't catch same errors as '%g' Message-ID: Patches item #1673759, was opened at 2007-03-04 21:45 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Eric V. Smith (ericvsmith) Assigned to: Nobody/Anonymous (nobody) Summary: '%G' string formatting doesn't catch same errors as '%g' Initial Comment: See http://python.org/sf/1673757 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-17 23:57 Message: Logged In: YES user_id=6380 Originator: NO Changing the category to 2.5; since the bug appears in 2.5 and 2.6, this should be applied to 2.5 and to the trunk (i.e. 2.6) and then it will automatically be merged into 3.0 when the next merge is done. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 16:50 Message: Logged In: YES user_id=1740099 Originator: NO lgtm ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 13:58 Message: Logged In: YES user_id=411198 Originator: YES Improved summary. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-10 13:57 Message: Logged In: YES user_id=411198 Originator: YES Thanks for the catch on the line length. I've updated the patch and attached it. File Added: 1673757-1.diff ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-10 13:01 Message: Logged In: YES user_id=1740099 Originator: NO Your change in Objects/stringobject.c and Objects/unicodeobject.c goes over the 79 character line limit. Otherwise looks ok - compiles, runs, tests look correct and pass. ---------------------------------------------------------------------- Comment By: Eric V. Smith (ericvsmith) Date: 2007-03-06 06:10 Message: Logged In: YES user_id=411198 Originator: YES Updated diff file attached, with correct filenames and with updated tests. File Added: 1673757.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673759&group_id=5470 From noreply at sourceforge.net Sun Mar 18 09:29:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 01:29:42 -0700 Subject: [Patches] [ python-Patches-1682878 ] Python 2.5 "What's New" document contains socket errors Message-ID: Patches item #1682878, was opened at 2007-03-17 22:20 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682878&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 "What's New" document contains socket errors Initial Comment: http://docs.python.org/whatsnew/modules.html talks about two new socket methods, recv_buf(buffer) and recvfrom_buf(buffer). I suppose it means to be talking about recv_into and recvfrom_into. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 08:29 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 54426, 54427 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682878&group_id=5470 From noreply at sourceforge.net Sun Mar 18 16:49:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 08:49:05 -0700 Subject: [Patches] [ python-Patches-1681101 ] PEP 3115 patch Message-ID: Patches item #1681101, was opened at 2007-03-14 20:09 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: PEP 3115 patch Initial Comment: A patch for PEP 3115 (metaclass syntax for Py3k). This enables full [arglist] syntax in the class header, e.g. class C(B1, B2, metaclass=MC, *more_bases, **kwds): pass ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-18 11:49 Message: Logged In: YES user_id=6380 Originator: YES Checked in as revision 54428. The PEP is accepted. (And yes, I realize this has been quite the monologue. :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 19:12 Message: Logged In: YES user_id=6380 Originator: YES Fix syntax error in pickletester.py File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:27 Message: Logged In: YES user_id=6380 Originator: YES Fixed all library and test code I could find that used __metaclass__. The only two remaining tests (without -uall) failing are test_ast and test_compiler. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 16:07 Message: Logged In: YES user_id=6380 Originator: YES Fixed two bugs, with the help of (improved) test_metaclass.py: - bug in symtable handling of keyword args that triggered an assert in debug mode - bug in build_class that mutated the keyword args dict in place I've got the feeling that there are leaks. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 14:50 Message: Logged In: YES user_id=6380 Originator: YES And another. This adds a unittest for the new build_class functionality, and fixes one bug (in the way __prepare__ was called) found this way. BTW doctest rocks for this purpose. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 11:53 Message: Logged In: YES user_id=6380 Originator: YES New patch, gets rid of LOAD_LOCALS and BUILD_CLASS opcodes and adds LOAD_BUILD_CLASS opcode which avoids looking for __build_class__ in the globals; it only searches the builtins (like the IMPORT statement). Though this is debatable. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-16 00:11 Message: Logged In: YES user_id=6380 Originator: YES Here's a new version that implements __build_class__ in C. It's still an ordinary built-in function loaded using LOAD_GLOBAL so you can play games with this; however I'd rather keep that an implementation detail and not a feature (unlike overriding __import__, which *is* a feature). One thing that's missing is support for __metaclass__, either in the module, or in the class. I don't want to support those (maybe the PEP should mention this), but we need a fixer for 2to3 to warn about this, at least (and to convert class C: __metaclass__ = M; ... into class C(metaclass=M): ...). BTW, the test_grp failure mentioned earlier is bogus; that's an artefact of Google's LDAP. Some more tests probably fail, but I'll worry about those later. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:53 Message: Logged In: YES user_id=6380 Originator: YES New version. Fixes problems with bsddb, removes dead declaration from bltinmodule.c, and updates outdated docs for MAKE_FUNCTION and MAKE_CLOSURE in opcode.h while I was at it. File Added: meta.patch ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 17:06 Message: Logged In: YES user_id=6380 Originator: YES Here's a new patch, which generates correct code for all variants of the class header syntax. For now, I've implemented __build_class__ in Python; the built-in function by that name imports the build_class module and calls its build_class function. (I'll later redo this in C.) This is still rough; I didn't even delete the old BUILD_CLASS opcode. But only a few unit tests fail (especially the ast and compiler tests). There are no unit tests for the new functionality. There is no documentation. Failing tests: test_ast test_compiler test_ctypes test_descr test_grp test_pep292 File Added: meta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681101&group_id=5470 From noreply at sourceforge.net Sun Mar 18 18:46:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 10:46:44 -0700 Subject: [Patches] [ python-Patches-1678339 ] Adding a testcase for the bug in find_longest_match Message-ID: Patches item #1678339, was opened at 2007-03-11 15:11 Message generated for change (Comment added) made by paulhankin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Denys Rtveliashvili (rtvd) Assigned to: Nobody/Anonymous (nobody) Summary: Adding a testcase for the bug in find_longest_match Initial Comment: The find_longest_match method in the difflib's SequenceMatcher has a bug. The bug is in turn caused by a problem with creating a b2j mapping which should contain a list of indices for each of the list elements in b. However, when the b2j mapping is being created (this is being done in __chain_b method in the SequenceMatcher) the mapping becomes broken. The cause of this is that for the frequently used elements the list of indices is removed and the element is being enlisted in the populardict mapping. The test case tries to match two strings like: abbbbbb.... and ...bbbbbbc The number of b is equal and the find_longest_match should have returned the proper amount. However, in case the number of "b"s is large enough, the method reports that the length of the longest common substring is 0. It simply can't find it. A bug was raised some time ago on this matter. It's ID is 1528074. I tried to fix this bug but as a result, the performance drops by a factor of 5-10. Perhaps someone more familiar with Python can find a good fix. For the time being I send this test case (which is broken until the bug is fixed) and I'm going to send a fix next (but the fix makes the method run quite slowly). The patch diff attached was made against the trunk version of Python. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-18 17:46 Message: Logged In: YES user_id=1740099 Originator: NO The test correctly fails, and looks right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 From noreply at sourceforge.net Sun Mar 18 19:02:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 11:02:17 -0700 Subject: [Patches] [ python-Patches-1630118 ] Patch to add tempfile.SpooledTemporaryFile (for #415692) Message-ID: Patches item #1630118, was opened at 2007-01-07 14:36 Message generated for change (Comment added) made by djmitche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1630118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dustin J. Mitchell (djmitche) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add tempfile.SpooledTemporaryFile (for #415692) Initial Comment: Attached please find a patch that adds a SpooledTemporaryFile class to tempfile, along with the corresponding documentation (optimistically labeling the feature as added in Python 2.5) and some test cases. ---------------------------------------------------------------------- >Comment By: Dustin J. Mitchell (djmitche) Date: 2007-03-18 13:02 Message: Logged In: YES user_id=7446 Originator: YES Slightly updated version to add STF to __all__ and add a test that bound methods work correctly. File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 19:55 Message: Logged In: YES user_id=1344176 Originator: NO Did you mean to leave SpooledTemporaryFile out of tempfile.py's __all__? Also, would it be possible for you to add some tests for the pathological cases you and Armin discussed related to bound .read() and .write() methods? ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-02-03 11:22 Message: Logged In: YES user_id=7446 Originator: YES Sounds good -- here's a new version. File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-01-11 01:55 Message: Logged In: YES user_id=4771 Originator: NO Reimplementing the whole file interface as a proxy functions might be the safest route, yes. I realized that the __getattr__() magic is also used to serve at least one special method, namely the __iter__() of the file objects. This only works with old-style classes. In the long-term future, when old-style classes disappear and these classes become new-style, this is likely to introduce a subtle bug. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-08 09:53 Message: Logged In: YES user_id=7446 Originator: YES I agree it would break in such a situation, but I'm not clear on which direction your bias leads you (specifically, which do we get right -- don't use bound methods, or don't use the __getattr__ magic?). I could fix this by defining "proxy" functions (and some properties) for the whole file interface, rather than just the methods that potentially trigger rollover. That would lose a little efficiency, but mostly only in reading (calling e.g., f.read() will always result in two function applications; in the current model, after the first call it runs at "native" speed). It would also lose forward compatibility if the file protocol changes, although I'm not sure how likely that is. Would you like me to do that? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-01-08 02:26 Message: Logged In: YES user_id=4771 Originator: NO The __getattr__ magic makes the following kind of code fail with SpooledTemporaryFile: f = SpooledTemporaryFile(max_size=something) rd = f.read wr = f.write for x in y: ...use rd(size) and wr(data)... The problem is that the captured 'f.read' method is the one from the StringIO instance, even after the write() rolled the file over to disk. Given that capturing bound methods is a semi-official speed hack advertised in some respected places, we might have to be careful about it. About such matters I am biased towards first getting it right and then getting it fast... Also, Python 2.5 is already out, so this will probably be a 2.6 addition. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-07 14:37 Message: Logged In: YES user_id=7446 Originator: YES File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1630118&group_id=5470 From noreply at sourceforge.net Sun Mar 18 19:28:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 11:28:48 -0700 Subject: [Patches] [ python-Patches-1678339 ] Adding a testcase for the bug in find_longest_match Message-ID: Patches item #1678339, was opened at 2007-03-11 15:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Denys Rtveliashvili (rtvd) Assigned to: Nobody/Anonymous (nobody) Summary: Adding a testcase for the bug in find_longest_match Initial Comment: The find_longest_match method in the difflib's SequenceMatcher has a bug. The bug is in turn caused by a problem with creating a b2j mapping which should contain a list of indices for each of the list elements in b. However, when the b2j mapping is being created (this is being done in __chain_b method in the SequenceMatcher) the mapping becomes broken. The cause of this is that for the frequently used elements the list of indices is removed and the element is being enlisted in the populardict mapping. The test case tries to match two strings like: abbbbbb.... and ...bbbbbbc The number of b is equal and the find_longest_match should have returned the proper amount. However, in case the number of "b"s is large enough, the method reports that the length of the longest common substring is 0. It simply can't find it. A bug was raised some time ago on this matter. It's ID is 1528074. I tried to fix this bug but as a result, the performance drops by a factor of 5-10. Perhaps someone more familiar with Python can find a good fix. For the time being I send this test case (which is broken until the bug is fixed) and I'm going to send a fix next (but the fix makes the method run quite slowly). The patch diff attached was made against the trunk version of Python. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 18:28 Message: Logged In: YES user_id=849994 Originator: NO Added the testcase to Lib/test/outstanding_bugs.py. It will be moved to test_difflib as soon as the bug is fixed. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-18 17:46 Message: Logged In: YES user_id=1740099 Originator: NO The test correctly fails, and looks right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 From noreply at sourceforge.net Sun Mar 18 22:29:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 14:29:59 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 05:22 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-18 22:29 Message: Logged In: YES user_id=51702 Originator: NO Please no, there is no need to bastardize both the implementation and the specification of splitext just to appease those 0.0001% of its users that has ever splitext:ed a dotfile. For the rest of the functions 99.99% users, the extra flags are just dead and confusing weight. Functions should not be kitchen sinks, they should do one thing only. If there is a need to split Python-2.4.3.tar.bz2 into ("Python-2.4.3", ".tar.bz2") or other unix:y variants, such a function would be much better added to shutil. Please just choose whether splitext(".emacs") returns ("", ".emacs") or (".emacs", "") and update the doc to be more explicit. Keep it simple. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 23:36 Message: Logged In: YES user_id=1720594 Originator: YES I should probably not submit a patch in the *middle* of a conversation, huh? I thought it was at the point where people were just debating things like.. policy... and.. stuff. And not at a point where someone would come up a whole new idea that ties directly in. Someone did! Nick Coghlan came up with a better way to spell the whole issue, and a logical companion feature; so I just implemented the patch that way. splitext(path, ignore_leading_dot=False, all_ext=False) Also added a bunch to the test just to be anal about being sure that no combination of options would screw up the 'default' behavior. File Added: splitext-leading_dot+all_ext.patch ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 17:52 Message: Logged In: YES user_id=1720594 Originator: YES Well, because someone on the -dev list at some point raised an objection to taking an arbitrary positional argument in as a second argument and not throwing an error. Or something like that. splitext('filename.ext', '.') would make '.' head along into preserve_dotfiles If that's not a concern, I could readily just type-check to make sure preserve_keywords is only one of (True, False) and if not raise an error. Its a "keyword-only-argument", before such a thing is in :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 17:48 Message: Logged In: YES user_id=849994 Originator: NO I don't understand why you have to use **kwargs. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 17:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 17:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-16 16:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 09:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Mon Mar 19 02:04:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 18:04:52 -0700 Subject: [Patches] [ python-Patches-1678077 ] improve telnetlib.Telnet so option negotiation becomes easie Message-ID: Patches item #1678077, was opened at 2007-03-10 17:11 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678077&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: improve telnetlib.Telnet so option negotiation becomes easie Initial Comment: This patch is a merger of #664020 (telnetlib option subnegotiation fix) and #1520081 (telnetlib.py change to ease option handling) which are both outdated. The purpose of it is to replace the set_option_negotiation_callback with a handle_option method that subclasses can reimplement. This should make it much easier to implement custom option negotiation handling. The patch also extends the documentation somewhat to make it clearer how to to implement custom option subnegotiation. It breaks compatibility with earlier Pythons because it removes set_option_negotiation_callback. But I think it should be good to apply it for Python 3.0. See the referenced patches for many more details. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 21:04 Message: Logged In: YES user_id=764593 Originator: NO (1) In the example code, why is parms backquoted? My first thought was that it was for repr, which won't work in Py3, particularly since it isn't quoted on the previous line. + parms = self.read_sb_data() + self.msg('IAC SB %d %s IAC SE', ord(opt), `parms`) (2) There are advantages to the old callback way. It is easier to change things per-instance, at runtime, and even mid-connection. It might be worth showing an example that restores the current model. option_callback=None # class default def set_option_negotiation_callback(self, callback): """Provide a callback function called after each receipt of a telnet option.""" self.option_callback = callback def handle_option(self, command, option): if self.option_callback is not None: return self.option_callback(self, command, option) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 17:47 Message: Logged In: YES user_id=849994 Originator: NO Closed the other two patches as "superseded by this one". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678077&group_id=5470 From noreply at sourceforge.net Mon Mar 19 02:14:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 18:14:27 -0700 Subject: [Patches] [ python-Patches-1683328 ] Demo/parser/unparse.py fixes and cleanups Message-ID: Patches item #1683328, was opened at 2007-03-19 03:14 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=1683328&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: Demo/parser/unparse.py fixes and cleanups Initial Comment: Bug fixes: * incorrect parenthesization of yield and conditional expressions * ExtSlice separator should be ",", not ":" (as far as i can tell) Changes: * handle alias nodes in a common method * incorporate an "interleave" helper to simplify the code and improve the output of delimited sequences * minor cleanups ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683328&group_id=5470 From noreply at sourceforge.net Mon Mar 19 02:59:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 18:59:39 -0700 Subject: [Patches] [ python-Patches-1678345 ] A fix for the bug #1528074 [warning: quite slow] Message-ID: Patches item #1678345, was opened at 2007-03-11 11:28 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678345&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Denys Rtveliashvili (rtvd) Assigned to: Nobody/Anonymous (nobody) Summary: A fix for the bug #1528074 [warning: quite slow] Initial Comment: This is a fix for the bug #1528074 in the difflib's SequenceMatcher which makes (among other possible things) find_longest_match return invalid results sometimes. The previously submitted test case for this bug has the #1678339 ID. The find_longest_match and __chain_b methods in the SequenceMatcher are perfectly optimized. The find_longest_match would work both fast and correctly if only the __chain_b did not break it's assumptions. The find_longest_match assumes that the b2j mapping has a mapping of all non-junk elements in b to lists of their indices in the "b" list. However, when __chain_b creates the b2j mapping, it removes popular elements from the list and marking the elements as popular in the "populardict". As a result, the find_longest_match method can't find the indices for the popular elements and they become automatically considered as something like a junk. I tried to fix the bug by both changing the find_longest_match and __chain_b methods. No matter how hard I tried, the change dropped the performance and slowed down the matching by 5-10 times. The impact of find_longest_match method was larger, so I decided to send a patch for the __chain_b. Please, note, that even though the method starts to work properly and the test cases pass on my computer just fine, the ingenious optimizations performed before become broken, so it would be great if a guru in Python code optimization tries to improve the things a bit. One more point: if the indices are not removed, the memory consumption on the large strings can become quite great. If this is a serious concern, a fix in the find_longest_match will need to be done instead. However that fix would probably be far less efficient that this one. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 21:59 Message: Logged In: YES user_id=764593 Originator: NO I think the bug is documentation only. According to the comments (but not the docstring) find_longest_match returns the longest _interesting_ match. A single element appearing too often is likely to cause spurious matches, and is therefore not interesting. I do agree that this should be noted more prominently, so people don't try things like comparing text strings letter-by-letter (where 1% is far too low a threshhold for a 26-character alphabet). And yes, the comments on popular are correct -- it ignores elements which constitute *more* than 1%. I recommend closing this set of tracker items. If you could submit changes to the documentation (docstrings and/or help files; maybe even the comments), I would recommend applying them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678345&group_id=5470 From noreply at sourceforge.net Mon Mar 19 03:01:22 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 19:01:22 -0700 Subject: [Patches] [ python-Patches-1678339 ] Adding a testcase for the bug in find_longest_match Message-ID: Patches item #1678339, was opened at 2007-03-11 11:11 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Denys Rtveliashvili (rtvd) Assigned to: Nobody/Anonymous (nobody) Summary: Adding a testcase for the bug in find_longest_match Initial Comment: The find_longest_match method in the difflib's SequenceMatcher has a bug. The bug is in turn caused by a problem with creating a b2j mapping which should contain a list of indices for each of the list elements in b. However, when the b2j mapping is being created (this is being done in __chain_b method in the SequenceMatcher) the mapping becomes broken. The cause of this is that for the frequently used elements the list of indices is removed and the element is being enlisted in the populardict mapping. The test case tries to match two strings like: abbbbbb.... and ...bbbbbbc The number of b is equal and the find_longest_match should have returned the proper amount. However, in case the number of "b"s is large enough, the method reports that the length of the longest common substring is 0. It simply can't find it. A bug was raised some time ago on this matter. It's ID is 1528074. I tried to fix this bug but as a result, the performance drops by a factor of 5-10. Perhaps someone more familiar with Python can find a good fix. For the time being I send this test case (which is broken until the bug is fixed) and I'm going to send a fix next (but the fix makes the method run quite slowly). The patch diff attached was made against the trunk version of Python. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 22:01 Message: Logged In: YES user_id=764593 Originator: NO I think the bug is documentation only. According to the comments (but not the docstring) find_longest_match returns the longest _interesting_ match. A single element appearing too often is likely to cause spurious matches, and is therefore not interesting. I do agree that this should be noted more prominently, so people don't try things like comparing text strings letter-by-letter (where 1% is far too low a threshhold for a 26-character alphabet). And yes, the comments on popular are correct -- it ignores elements which constitute *more* than 1%. I recommend closing this set of tracker items. If you could submit changes to the documentation (docstrings and/or help files; maybe even the comments), I would recommend applying them. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-18 14:28 Message: Logged In: YES user_id=849994 Originator: NO Added the testcase to Lib/test/outstanding_bugs.py. It will be moved to test_difflib as soon as the bug is fixed. ---------------------------------------------------------------------- Comment By: Paul Hankin (paulhankin) Date: 2007-03-18 13:46 Message: Logged In: YES user_id=1740099 Originator: NO The test correctly fails, and looks right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678339&group_id=5470 From noreply at sourceforge.net Mon Mar 19 03:45:47 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 19:45:47 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 00:22 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 22:45 Message: Logged In: YES user_id=764593 Originator: NO If it has to be a simple decision, we need to keep the current behavior; test/test_ntpath.py has been explicitly verifying the current behavior since 2002. The question is whether the spec is buggy enough to fix, either in 2.x or in 3.0. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-18 17:29 Message: Logged In: YES user_id=51702 Originator: NO Please no, there is no need to bastardize both the implementation and the specification of splitext just to appease those 0.0001% of its users that has ever splitext:ed a dotfile. For the rest of the functions 99.99% users, the extra flags are just dead and confusing weight. Functions should not be kitchen sinks, they should do one thing only. If there is a need to split Python-2.4.3.tar.bz2 into ("Python-2.4.3", ".tar.bz2") or other unix:y variants, such a function would be much better added to shutil. Please just choose whether splitext(".emacs") returns ("", ".emacs") or (".emacs", "") and update the doc to be more explicit. Keep it simple. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 18:36 Message: Logged In: YES user_id=1720594 Originator: YES I should probably not submit a patch in the *middle* of a conversation, huh? I thought it was at the point where people were just debating things like.. policy... and.. stuff. And not at a point where someone would come up a whole new idea that ties directly in. Someone did! Nick Coghlan came up with a better way to spell the whole issue, and a logical companion feature; so I just implemented the patch that way. splitext(path, ignore_leading_dot=False, all_ext=False) Also added a bunch to the test just to be anal about being sure that no combination of options would screw up the 'default' behavior. File Added: splitext-leading_dot+all_ext.patch ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 12:52 Message: Logged In: YES user_id=1720594 Originator: YES Well, because someone on the -dev list at some point raised an objection to taking an arbitrary positional argument in as a second argument and not throwing an error. Or something like that. splitext('filename.ext', '.') would make '.' head along into preserve_dotfiles If that's not a concern, I could readily just type-check to make sure preserve_keywords is only one of (True, False) and if not raise an error. Its a "keyword-only-argument", before such a thing is in :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 12:48 Message: Logged In: YES user_id=849994 Originator: NO I don't understand why you have to use **kwargs. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 12:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 12:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-16 11:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 04:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Mon Mar 19 04:01:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 20:01:04 -0700 Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test coverage improvement Message-ID: Patches item #1675424, was opened at 2007-03-06 22:14 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile tweaks and test coverage improvement Initial Comment: This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests: - appending to an existing zipfile - appending to an existing file that is not a zipfile - check that calling ZipFile.write without arcname specified produces the expected result - check that files within a Zip archive can have different compression options - check that trying to call write() on a readonly ZipFile object raises a RuntimeError - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension - check that bad modes passed to ZipFile constructor are caught - check that bad modes passed to ZipFile.open are caught - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError - check that bad compression methods passed to ZipFile.open are caught - check that a filename containing a null byte is properly terminated These other miscellaneous changes were made to test_zipfile.py: - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142) - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr. - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data. The following changes were made to zipfile.ZipFile: - A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation) - ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError) - checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant) There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-) If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know. I can add such documentation changes if necessary. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 23:01 Message: Logged In: YES user_id=764593 Originator: NO It is possible to define a new Exception class which inherits from both RuntimeError and IOError, and raise that. Then document IOError, with a footnote mentioning that in 2.x it is also a RuntimeError for backwards compatibility. clientcookie does something similar; LoadError is derived from IOError only for backwards compatibility. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 14:43 Message: Logged In: YES user_id=1344176 Originator: NO I'm definitely in favor of the docs and test changes, and the extra error checking seems like a good idea. Both test_zipfile and test_zipfile64 pass for me with the patch applied. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-08 12:32 Message: Logged In: YES user_id=1115903 Originator: YES I've modified ZipFile.getinfo to raise a KeyError instead of a RuntimeError. It would appear that RuntimeError is what stuff in this module raises for IO problems, so I'm assuming this means we're stuck with it (even though I agree that IOError would seem more appropriate for trying to write to closed files). I documented some of the exceptions raised by various methods. However, I focused mainly on the items listed in my original post, so there's probably code that raise exceptions that still aren't properly documented. I also noticed that the existing docs list "error" as the exception that is raised for bad zip files. Since no such exception is raised, I included a change to the docs so that it says BadZipfile instead. I included a change to the NEWS file as well, since it was mentioned in py-dev discussion that such updates can be helpful. :-) File Added: zipfile_coverage2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:18 Message: Logged In: YES user_id=849994 Originator: NO I'd continue raising KeyError in the case the info wasn't found, but set a different message so that backwards compatibility doesn't break. In any case, it would be good to document it. Isn't raising IOError customary for writing to closed files? (If zipfile never raises IOError elsewhere, this is probably not applicable.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 From noreply at sourceforge.net Mon Mar 19 04:02:42 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 20:02:42 -0700 Subject: [Patches] [ python-Patches-1675424 ] Zipfile tweaks and test coverage improvement Message-ID: Patches item #1675424, was opened at 2007-03-06 22:14 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alan McIntyre (alanmcintyre) Assigned to: Nobody/Anonymous (nobody) Summary: Zipfile tweaks and test coverage improvement Initial Comment: This patch adds 12 tests for zipfile behavior that didn't appear to be covered by existing tests: - appending to an existing zipfile - appending to an existing file that is not a zipfile - check that calling ZipFile.write without arcname specified produces the expected result - check that files within a Zip archive can have different compression options - check that trying to call write() on a readonly ZipFile object raises a RuntimeError - check that PyZipFile.writepy won't accept a file that doesn't have a .py extension - check that bad modes passed to ZipFile constructor are caught - check that bad modes passed to ZipFile.open are caught - check that calling read(0) on a ZipExtFile object returns an empty string and doesn't advance file pointer - check that attempting to call open() for an item that doesn't exist in the archive raises a RuntimeError - check that bad compression methods passed to ZipFile.open are caught - check that a filename containing a null byte is properly terminated These other miscellaneous changes were made to test_zipfile.py: - FIXEDTEST_SIZE was changed to 1000 (I mistakenly left it at 10 instead of the original test size of 1000 when I last posted patch 1121142) - An existing test that checks for a RuntimeError when calling testzip on a closed ZipFile also now checks for the same exception on calls to read, open, write, and writestr. - In TestsWithSourceFile, the line_gen attribute was changed from a generator to a list because some of the tests iterate over lines in the test data. The following changes were made to zipfile.ZipFile: - A check was added to ZipFile constructor to check for bogus modes (and a couple of statements before the previously existing argument validation were moved below said validation) - ZipFile.getinfo now raises a RuntimeError when attempting to retrieve information for a file not in the archive (this seems more helpful than getting a cryptic KeyError) - checks were added to ZipFile.write and writestr to raise a RuntimeError when attempting to write to a closed ZipFile (note that this probably makes other checks further down in the code for these methods redundant) There are still some portions of zipfile.py that aren't covered, but if somebody commits this patch before I get around to writing tests for them I won't complain about having to submit a separate patch for them. ;-) If anybody has any thoughts on whether or not things like "calling ZipFile.getinfo for an item not in the archive raises a RuntimeError" should be in the docs, please let me know. I can add such documentation changes if necessary. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 23:02 Message: Logged In: YES user_id=764593 Originator: NO sorry; I meant "cookielib"; clientcookie is the name of the independently distributed package. (Though last I checked, John Lee was using roughly the same code in both.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 23:01 Message: Logged In: YES user_id=764593 Originator: NO It is possible to define a new Exception class which inherits from both RuntimeError and IOError, and raise that. Then document IOError, with a footnote mentioning that in 2.x it is also a RuntimeError for backwards compatibility. clientcookie does something similar; LoadError is derived from IOError only for backwards compatibility. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 14:43 Message: Logged In: YES user_id=1344176 Originator: NO I'm definitely in favor of the docs and test changes, and the extra error checking seems like a good idea. Both test_zipfile and test_zipfile64 pass for me with the patch applied. ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-08 12:32 Message: Logged In: YES user_id=1115903 Originator: YES I've modified ZipFile.getinfo to raise a KeyError instead of a RuntimeError. It would appear that RuntimeError is what stuff in this module raises for IO problems, so I'm assuming this means we're stuck with it (even though I agree that IOError would seem more appropriate for trying to write to closed files). I documented some of the exceptions raised by various methods. However, I focused mainly on the items listed in my original post, so there's probably code that raise exceptions that still aren't properly documented. I also noticed that the existing docs list "error" as the exception that is raised for bad zip files. Since no such exception is raised, I included a change to the docs so that it says BadZipfile instead. I included a change to the NEWS file as well, since it was mentioned in py-dev discussion that such updates can be helpful. :-) File Added: zipfile_coverage2.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-07 03:18 Message: Logged In: YES user_id=849994 Originator: NO I'd continue raising KeyError in the case the info wasn't found, but set a different message so that backwards compatibility doesn't break. In any case, it would be good to document it. Isn't raising IOError customary for writing to closed files? (If zipfile never raises IOError elsewhere, this is probably not applicable.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675424&group_id=5470 From noreply at sourceforge.net Mon Mar 19 04:10:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 20:10:36 -0700 Subject: [Patches] [ python-Patches-1673122 ] Mac OS X: libtool Message-ID: Patches item #1673122, was opened at 2007-03-03 15:33 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.6 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: libtool Initial Comment: When the framewok is built on Mac OS X, the Mac OS X specific libtool is used. However, if the GNU libtool is on the PATH first, python refuses to build. This patch simply specifies the Mac OS X libtool with an absolute path by updating the Makefile.pre.in file. That way, someone can have GNU libtool on the PATH first and still build python. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-18 23:10 Message: Logged In: YES user_id=764593 Originator: NO This fix is probably worth a News entry as well. Jorend: If you want it applied sooner, you can edit the wiki page at http://wiki.python.org/moin/PatchTriage saying that you have reviewed it and recommend that it be applied. ---------------------------------------------------------------------- Comment By: Witten (herrwitten) Date: 2007-03-08 09:25 Message: Logged In: YES user_id=1595909 Originator: YES Great! ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 23:36 Message: Logged In: YES user_id=18139 Originator: NO It works. ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-07 10:38 Message: Logged In: YES user_id=18139 Originator: NO OK, I don't see why not. I'll try this out tonight, just to make sure it works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1673122&group_id=5470 From noreply at sourceforge.net Mon Mar 19 06:05:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 18 Mar 2007 22:05:34 -0700 Subject: [Patches] [ python-Patches-1683397 ] Refactor test_minidom.py to use unittest. Message-ID: Patches item #1683397, was opened at 2007-03-18 23: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=1683397&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_minidom.py to use unittest. Initial Comment: This patch refactors test_minidom.py to use unittest. Since the test gets run by xmltest.py, this will invalidate the expected output in Lib/test/output/xmltest. There are some other files run by xmltest.py that have not yet been refactored, so Lib/test/output/xmltest is not ready for removal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683397&group_id=5470 From noreply at sourceforge.net Mon Mar 19 18:17:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 10:17:50 -0700 Subject: [Patches] [ python-Patches-1677694 ] test_timeout refactoring Message-ID: Patches item #1677694, was opened at 2007-03-09 19:49 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677694&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout refactoring Initial Comment: Please see #728815. https://sourceforge.net/tracker/index.php?func=detail&aid=728815&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-10 09:39 Message: Logged In: YES user_id=51702 Originator: YES But the bugfix is so simple. :) The original author Dmitry Vasiliev claimed that connecting to www.google.com with port 80 did not always work for him because of a transparent proxy. I believe what he meant was that connection was not guaranteed to timeout. So he changed the port to 21 which www.google.com does not respond to. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-09 22:39 Message: Logged In: YES user_id=1344176 Originator: NO In a comment on patch #728815, you (Bjorn) said, "[p]lus, (I think) it fixes a bug which (I think) only happens when you access the internet from behind a web proxy." Could you split any bug fixes into a patch separate from the code cleanup and refactoring? That will make reviewing it/them easier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677694&group_id=5470 From noreply at sourceforge.net Mon Mar 19 19:53:41 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 11:53:41 -0700 Subject: [Patches] [ python-Patches-1630118 ] Patch to add tempfile.SpooledTemporaryFile (for #415692) Message-ID: Patches item #1630118, was opened at 2007-01-07 15:36 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1630118&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Dustin J. Mitchell (djmitche) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add tempfile.SpooledTemporaryFile (for #415692) Initial Comment: Attached please find a patch that adds a SpooledTemporaryFile class to tempfile, along with the corresponding documentation (optimistically labeling the feature as added in Python 2.5) and some test cases. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 14:53 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54439. Thanks for your patch! ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-03-18 14:02 Message: Logged In: YES user_id=7446 Originator: YES Slightly updated version to add STF to __all__ and add a test that bound methods work correctly. File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 20:55 Message: Logged In: YES user_id=1344176 Originator: NO Did you mean to leave SpooledTemporaryFile out of tempfile.py's __all__? Also, would it be possible for you to add some tests for the pathological cases you and Armin discussed related to bound .read() and .write() methods? ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-02-03 12:22 Message: Logged In: YES user_id=7446 Originator: YES Sounds good -- here's a new version. File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-01-11 02:55 Message: Logged In: YES user_id=4771 Originator: NO Reimplementing the whole file interface as a proxy functions might be the safest route, yes. I realized that the __getattr__() magic is also used to serve at least one special method, namely the __iter__() of the file objects. This only works with old-style classes. In the long-term future, when old-style classes disappear and these classes become new-style, this is likely to introduce a subtle bug. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-08 10:53 Message: Logged In: YES user_id=7446 Originator: YES I agree it would break in such a situation, but I'm not clear on which direction your bias leads you (specifically, which do we get right -- don't use bound methods, or don't use the __getattr__ magic?). I could fix this by defining "proxy" functions (and some properties) for the whole file interface, rather than just the methods that potentially trigger rollover. That would lose a little efficiency, but mostly only in reading (calling e.g., f.read() will always result in two function applications; in the current model, after the first call it runs at "native" speed). It would also lose forward compatibility if the file protocol changes, although I'm not sure how likely that is. Would you like me to do that? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-01-08 03:26 Message: Logged In: YES user_id=4771 Originator: NO The __getattr__ magic makes the following kind of code fail with SpooledTemporaryFile: f = SpooledTemporaryFile(max_size=something) rd = f.read wr = f.write for x in y: ...use rd(size) and wr(data)... The problem is that the captured 'f.read' method is the one from the StringIO instance, even after the write() rolled the file over to disk. Given that capturing bound methods is a semi-official speed hack advertised in some respected places, we might have to be careful about it. About such matters I am biased towards first getting it right and then getting it fast... Also, Python 2.5 is already out, so this will probably be a 2.6 addition. ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-07 15:37 Message: Logged In: YES user_id=7446 Originator: YES File Added: SpooledTemporaryFile.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1630118&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:03:16 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:03:16 -0700 Subject: [Patches] [ python-Patches-1683328 ] Demo/parser/unparse.py fixes and cleanups Message-ID: Patches item #1683328, was opened at 2007-03-19 01:14 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683328&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and tools Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: Demo/parser/unparse.py fixes and cleanups Initial Comment: Bug fixes: * incorrect parenthesization of yield and conditional expressions * ExtSlice separator should be ",", not ":" (as far as i can tell) Changes: * handle alias nodes in a common method * incorporate an "interleave" helper to simplify the code and improve the output of delimited sequences * minor cleanups ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 19:03 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed as rev. 54441. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683328&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:10:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:10:03 -0700 Subject: [Patches] [ python-Patches-1665292 ] Datetime enhancements Message-ID: Patches item #1665292, was opened at 2007-02-21 09:55 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Datetime enhancements Initial Comment: I'm proposing some small enhancements to the datetime module: Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method. Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :] The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch. Thx ---------------------------------------------------------------------- Comment By: Johann C. Rocholl (jcrocholl) Date: 2007-03-09 11:33 Message: Logged In: YES user_id=656137 Originator: NO The patch confuses microseconds with milliseconds. The divisor in delta_float should be 1000000.0, not 1000.0. The result of the last test should be 86401.000001, not 86401.001. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-02-21 11:16 Message: Logged In: YES user_id=560817 Originator: YES File Added: timedelta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:11:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:11:56 -0700 Subject: [Patches] [ python-Patches-1665292 ] Datetime enhancements Message-ID: Patches item #1665292, was opened at 2007-02-21 09:55 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Datetime enhancements Initial Comment: I'm proposing some small enhancements to the datetime module: Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method. Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :] The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch. Thx ---------------------------------------------------------------------- Comment By: Johann C. Rocholl (jcrocholl) Date: 2007-03-09 11:33 Message: Logged In: YES user_id=656137 Originator: NO The patch confuses microseconds with milliseconds. The divisor in delta_float should be 1000000.0, not 1000.0. The result of the last test should be 86401.000001, not 86401.001. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-02-21 11:16 Message: Logged In: YES user_id=560817 Originator: YES File Added: timedelta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:13:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:13:13 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 19:51 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 19:13 Message: Logged In: YES user_id=849994 Originator: YES You didn't attach a patch, but if you do these modification, you can check it in directly IMO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-18 01:54 Message: Logged In: YES user_id=1344176 Originator: NO - I think _clear() should keep the underscore; it's probably not something that people should be encouraged to use. - I've fixed bound method support. - I'm going to make Py_PyAtExit non-public. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 16:14 Message: Logged In: YES user_id=849994 Originator: YES Looks good, four points: - should _clear keep its underscore? - unregistering will fail with bound methods, don't know if we should do something about that - you messed up the indentation in pythonrun.c and atexit.c (spaces in the former and tabs in the latter) ;) - do we need docs for Py_PyAtExit? If not, it should be nonpublic and get a leading underscore. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 22:02 Message: Logged In: YES user_id=1344176 Originator: NO Ok, I'm sold on the two-phase atexit structure. I've updated my patch to keep atexit's handlers separate from the call_ll_exitfuncs() handlers. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:28 Message: Logged In: YES user_id=849994 Originator: YES It's not specified that exit handlers can do cleanup only, in theory they could do things like sending an email etc. Please let's not introduce gratuitous breakage here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 21:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 21:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 20:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 18:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 07:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 06:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 22:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 21:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:29:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:29:31 -0700 Subject: [Patches] [ python-Patches-1682205 ] TypeError swallowing in UNPACK_SEQUENCE opcode Message-ID: Patches item #1682205, was opened at 2007-03-16 10:22 Message generated for change (Comment added) made by djmitche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError swallowing in UNPACK_SEQUENCE opcode Initial Comment: When UNPACK_SEQUENCE unpacks an iterable, it replaces any TypeError raised by the iterator with a new, catch-all TypeError('unpack non-sequence') instance (and empty traceback). This message is less useful than the ones it's (presumably) intended to replace (raised by PyObject_GetIter(), via unpack_iterable()), and obviously wrong when the TypeError originates in unrelated user code. The attached patch simply removes the check, which (as far as i can tell) has no ill effects. Examples (without the patch): >>> a, b, c = 7 TypeError: unpack non-sequence >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: unpack non-sequence With the patch applied, these result in: >>> a, b, c = 7 TypeError: 'int' object is not iterable >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: int() argument must be a string or a number, not 'tuple' ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-03-19 14:29 Message: Logged In: YES user_id=7446 Originator: NO Looks good to me. I've never seen software try to catch this error by string comparison, so I doubt it will break existing applications. The worst consequence may be that various HOWTOs will now incorrectly specify the Python output -- not a big deal. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 10:49 Message: Logged In: YES user_id=849994 Originator: NO It's patch, after all :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682205&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:32:15 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:32:15 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-19 13: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=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Mon Mar 19 20:43:08 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 12:43:08 -0700 Subject: [Patches] [ python-Patches-1681842 ] splitext of dotfiles, incl backwards compat and migration Message-ID: Patches item #1681842, was opened at 2007-03-16 04:22 Message generated for change (Comment added) made by aptshansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Hansen (aptshansen) Assigned to: Nobody/Anonymous (nobody) Summary: splitext of dotfiles, incl backwards compat and migration Initial Comment: The attached patch is for the *path.py files, the associated test suits, and the documentation-- the latter part which may need a staring at since I don't really know LaTeX very well. It's made against the HEAD in the trunk. This is in response to issue #1462106, which has earned quite a bit of discussion on python-dev. I am in complete agreement with the *intention* of that patch and its application, that the previous behavior was "wrong"; that splitext('.cshrc') should not return ('', '.cshrc'). However, the patch silently altered the semantics of the function instead of firmly failing, and doesn't allow for the fact that the previous documentation was ambiguous and as such people may (and apparently, sometimes did) actually consider the old behavior correct. The attached patch adds a keyword parameter to splitext, "preserve_dotfiles", which at present defaults to False. It might need a better name :P I suck at that. When False, the behavior is to return ('', '.cshrc'), but also to issue a FutureWarning indicating that this will change in the future. When True, the behavior is to return ('.cshrc', ''). The intention is to fix the 'error', while giving people time to migrate code which may have previousely been faulty to the correct result. Also, for those not of a deeply UNIX mindset, they can consider everything after the last dot-- regardless of how many-- an extension, even if it means there's no root. Viva la Windows Explorer. ---------------------------------------------------------------------- >Comment By: Stephen Hansen (aptshansen) Date: 2007-03-19 19:43 Message: Logged In: YES user_id=1720594 Originator: YES As to Bastardization of Implementations; I think from the endless conversation it became obvious (to me at lest) that just what "extension" means is actually somewhat domain-specific, and splitext doesn't really do it's "one thing" very well. I think "ignore_leading_dot" is nessecary, regardless of which behavior is default and regardless of if it becomes determined warnings are bad. Dotfiles do exist: on the various *Nix's, and on Mac's too-- I have about a dozen on my primary machine which is a mac in my home directory. Taking them into consideration is important, and there doesn't seem to be a clear opinion on how to treat the dot. So let people decide. IMHO. I think "all_ext" is quite useful in many situations; that'd be the one I'd actually have used on more then one occasion in the past. I never used splitext because of its lack. And not on UNIX :) My company develops for Windows and OSX. Either way, I'm curious what the pronouncement will be :) I'll probably update the patch to do whatever is decided is right (assuming that the status-quo of the original modification isn't determined to be right) This doesn't actually affect me at all (due to never using splitext as above noted), I just made the patch because I had time, it was an interesting, and I had an opinion on what was right-- so figured I'd back it up :) It's been more a test-case on getting involved with contributing to python. And an interesting one. :) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-19 02:45 Message: Logged In: YES user_id=764593 Originator: NO If it has to be a simple decision, we need to keep the current behavior; test/test_ntpath.py has been explicitly verifying the current behavior since 2002. The question is whether the spec is buggy enough to fix, either in 2.x or in 3.0. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-18 21:29 Message: Logged In: YES user_id=51702 Originator: NO Please no, there is no need to bastardize both the implementation and the specification of splitext just to appease those 0.0001% of its users that has ever splitext:ed a dotfile. For the rest of the functions 99.99% users, the extra flags are just dead and confusing weight. Functions should not be kitchen sinks, they should do one thing only. If there is a need to split Python-2.4.3.tar.bz2 into ("Python-2.4.3", ".tar.bz2") or other unix:y variants, such a function would be much better added to shutil. Please just choose whether splitext(".emacs") returns ("", ".emacs") or (".emacs", "") and update the doc to be more explicit. Keep it simple. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 22:36 Message: Logged In: YES user_id=1720594 Originator: YES I should probably not submit a patch in the *middle* of a conversation, huh? I thought it was at the point where people were just debating things like.. policy... and.. stuff. And not at a point where someone would come up a whole new idea that ties directly in. Someone did! Nick Coghlan came up with a better way to spell the whole issue, and a logical companion feature; so I just implemented the patch that way. splitext(path, ignore_leading_dot=False, all_ext=False) Also added a bunch to the test just to be anal about being sure that no combination of options would screw up the 'default' behavior. File Added: splitext-leading_dot+all_ext.patch ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:52 Message: Logged In: YES user_id=1720594 Originator: YES Well, because someone on the -dev list at some point raised an objection to taking an arbitrary positional argument in as a second argument and not throwing an error. Or something like that. splitext('filename.ext', '.') would make '.' head along into preserve_dotfiles If that's not a concern, I could readily just type-check to make sure preserve_keywords is only one of (True, False) and if not raise an error. Its a "keyword-only-argument", before such a thing is in :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 16:48 Message: Logged In: YES user_id=849994 Originator: NO I don't understand why you have to use **kwargs. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:36 Message: Logged In: YES user_id=1720594 Originator: YES That's a good point; updated patch to throw an error if other keyword arguments are given. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 16:35 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext3.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-16 15:50 Message: Logged In: YES user_id=21627 Originator: NO [ignoring the question whether this change is acceptable in the first place - I'm apparently not qualified to make a determination here] This implementation makes splitext accept arbitrary many keyword arguments. This is not good, it should only accept those that are documented. It might be helpful if the warning was only issued if the keyword argument wasn't provided at all, assuming that whoever passes False knows what he does. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:00 Message: Logged In: YES user_id=1720594 Originator: YES File Added: splitext2.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681842&group_id=5470 From noreply at sourceforge.net Mon Mar 19 23:23:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 15:23:53 -0700 Subject: [Patches] [ python-Patches-1671298 ] Refactor test_class to use unittest lib Message-ID: Patches item #1671298, was opened at 2007-02-28 15:38 Message generated for change (Comment added) made by jyzude You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mike Verdone (jyzude) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_class to use unittest lib Initial Comment: Refactored Lib/test/test_class.py to use unittest library instead of icky output comparison tests. Also have to delete output/test_class after adding this patch. ---------------------------------------------------------------------- >Comment By: Mike Verdone (jyzude) Date: 2007-03-19 16:23 Message: Logged In: YES user_id=584997 Originator: YES Hi Collin, Sorry for the delay. Your tweaks look very good. I don't see any problems. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-11 11:42 Message: Logged In: YES user_id=1344176 Originator: NO Mike, I've tweaked your refactoring some: strengthened the assertions in testMixIntsAndLongs and testDel; code cleanup in testBadTypeReturned; removed Jython-related code; reduced line lengths to < 80; changed a few print statements to self.fail() calls. Look over the version I've uploaded and tell me what you think. File Added: test_class.py.diff ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-07 14:07 Message: Logged In: YES user_id=584997 Originator: YES Removed unnecessary global statement in trackCall. Anything else? :-) File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 18:03 Message: Logged In: YES user_id=849994 Originator: NO Note that you don't need the global statement for callLst as you aren't rebinding it in the function. ---------------------------------------------------------------------- Comment By: Mike Verdone (jyzude) Date: 2007-03-05 23:38 Message: Logged In: YES user_id=584997 Originator: YES Hi collin, * I improved testMixIntsAndLongs. It now asserts things * assert is banished, replaced by the correct calls * the reason why callLst is global is because I have to track calls to __getitem__ in some cases. Because of this, if I put callLst on the object I end up with horrible recursive loops, or at the very least the last call on the stack will always be __getitem__ when I get the list to inspect. * assertLastCall only checks the last thing on the list because generally the thing called before that is always __getitem__ or associated magic. I don't want my tests to be bound to the internals of __getitem__. All I care about is that ultimately the right function was called. That said, I modified assertLastCallWas to erase the callLst to prevent any possible bleed-over from the previous test. Let me know if you have further suggestions. File Added: test_class.patch ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-05 17:11 Message: Logged In: YES user_id=1344176 Originator: NO Thanks for your effort! This generally looks good. A few minor things: - testMixIntsAndLongs doesn't have any assertions in it. - "assert" statements should probably be changed to use the failUnlessEqual/assertEqual methods. - I'm wary of your assertLastCallWas system; I'd feel more comfortable if you were making assertions about the entire call chain, not just its last item. Also, something like callLst feels strange as a global. Feel free to contact me to discuss this off-list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1671298&group_id=5470 From noreply at sourceforge.net Tue Mar 20 01:19:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 17:19:20 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Tue Mar 20 01:20:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 17:20:13 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Tue Mar 20 07:42:23 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 19 Mar 2007 23:42:23 -0700 Subject: [Patches] [ python-Patches-1490190 ] add os.chflags() and os.lchflags() where available Message-ID: Patches item #1490190, was opened at 2006-05-17 04:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: M. Levinson (levinsm) >Assigned to: Martin v. L?wis (loewis) Summary: add os.chflags() and os.lchflags() where available Initial Comment: The return value from os.stat() includes st_flags on some systems, but currently there's not much that can be done with the value; this patch aims to make st_flags useful by adding some associated constants to stat.py and the corresponding chflags() and lchflags() functions in posixmodule. For completeness, shutil.copystat() is also updated to call os.chflags() where it's available. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-19 23:42 Message: Logged In: YES user_id=33168 Originator: NO It looks like Tru64 does have some version of chflags, however, it is undocumented and apparently causes python to exit. It is at least one of the reasons for the recent buildbot failures: http://python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/1550/step-test/0 That doesn't really tell the whole story, but I logged on to the machine and ran the test, after modifying unittest to flush the stream, sigh :-( and got this: ringneck:/net/cci/nnorwitz/python/trunk.norwitz-tru64/nn-work-build % ./python -E -tt ./Lib/test/regrtest.py -v test_posix test_posix testNoArgFunctions (test.test_posix.PosixTester) ... ok test_access (test.test_posix.PosixTester) ... ok test_chdir (test.test_posix.PosixTester) ... ok test_chflags (test.test_posix.PosixTester) ... Bad system call ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-19 02:56 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r53826. ---------------------------------------------------------------------- Comment By: M. Levinson (levinsm) Date: 2006-05-19 04:47 Message: Logged In: YES user_id=1522893 In addition to MacOS, chflags(2) is available on FreeBSD, OpenBSD, and NetBSD. The flags in Lib/stat.py are the full set of available values although, as you noted, MacOS hasn't (yet) implemented several of them. Thanks for the comments - I've attached an updated version of the patch incorporating your suggestions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-19 00:31 Message: Logged In: YES user_id=33168 What operating systems is this available on? The only one I've found is OS X. The man page says it's from BSD 4.4. I tried on Linux of various flavors (4+), Solaris, and Tru64. None of them had chflags. I also could only find some of the flags in my sys/stat.h that were added to stat.py. stat.h didn't have UF_NOUNLINK, SF_NOUNLINK, SF_SNAPSHOT. As far as the patch itself, it looks good. There are a couple of changes if this should be accepted though: doc needs \versionadded{2.5}, I would prefer flags as the var name rather than i in posixmodule.c (btw you shouldn't need to init path). Also would need to update Misc/NEWS and ACKS if accepted. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 07:24 Message: Logged In: YES user_id=849994 Patch looks good. Do we want to include it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490190&group_id=5470 From noreply at sourceforge.net Tue Mar 20 10:23:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 02:23:25 -0700 Subject: [Patches] [ python-Patches-1555570 ] email parser incorrectly breaks headers with a CRLF at 8192 Message-ID: Patches item #1555570, was opened at 2006-09-10 00:41 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555570&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Meyer (anadelonbrin) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email parser incorrectly breaks headers with a CRLF at 8192 Initial Comment: If a message has a CRLF as part of a header that starts at 8191, the parser will incorrectly consider the headers to finish at 8191 and the body to start at 8193, which leaves headers in the body of the message. This problem occurs because the parser reads 8192 characters at a time. If 8192 is a '\r' and 8193 a '\n', then when the second block is parsed, it will appear to be a blank line (i.e. header separator). The simplest fix for this is to just read an extra character if the last one read is a '\r'. This appears to work fine without breaking anything, although I suppose that an alternative would be to change the FeedParser to check whether the '\n' belonged with the previous data. A patch and test are attached, against SVN of 10/Sept/06. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2007-03-20 09:23 Message: Logged In: YES user_id=113328 Originator: NO The documentation isn't clear, but I would say that the code is written on the basis that the file is opened in text or universal newline mode (so that CRLF will ve translated to \n). On that assumption, the patch is unnecessary, as CRLF will never appear in the data. (Actually, the existence of Utils.fix_eols makes me wonder...) On the other hand, 99% of the time, the code will work fine if a CRLF file is opened in binary mode. This patch fixes one of the obscure corner cases, and (as far as I can see) does no real harm - I can't imagine a *real* mail file containing literal CR bytes which should be preserved! The documentation should be updated to require that the file is in text or universal newline mode, and note that files with CRLF opened in binary mode could be processed incorrectly. I'm probably +0 on applying this patch, on the basis that it makes the code more robust given the current lack of any documentation of the required file mode. If the documentation is patched as above, I'd be -0. If the rest of the email module is known not to robust in the face of files with CRLF opened in binary mode, the documentation should definitely be changed, and that fact made very clear. (This patch becomes irrelevant then). BTW, the test case looks wrong - surely the line 'self.assertNotEqual(data[8193], "\n")' should check for a \r? I assume it's asserting that the line after the break is not the end of the headers - if so, that line will be \r\n as the earlier translation changes LF to CRLF. Summary: CRLF handling is a bit of a can of worms - the module documentation could do with being clearer in any case, but the patch is probably good to apply on the basis that it fixes a small corner case without causing harm elsewhere. The test should be fixed as above. ---------------------------------------------------------------------- Comment By: Jeremy Dunck (jdunck) Date: 2006-12-06 17:54 Message: Logged In: YES user_id=516425 Originator: NO We're hitting this bug as well. It affects Django, which handles media upload over HTTP by parsing multipart with email.message_from_string. pegasusnews.com, FWIW. ---------------------------------------------------------------------- Comment By: Graham King (graham_king) Date: 2006-12-06 11:30 Message: Logged In: YES user_id=1237146 Originator: NO I had exactly the same problem parsing a POST encoded as 'multipart/form-data' with lots of parts. The patch provided fixes it. I'm on ActivePython 2.4.3 so I applied the patch by hand. +1 for integrating this patch into Python. Thanks, Graham King. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1555570&group_id=5470 From noreply at sourceforge.net Tue Mar 20 15:25:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 07:25:59 -0700 Subject: [Patches] [ python-Patches-1658799 ] Handle requests to intern string subtype instances Message-ID: Patches item #1658799, was opened at 2007-02-13 11:34 Message generated for change (Comment added) made by hniksic You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1658799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hrvoje Nik?i? (hniksic) Assigned to: Nobody/Anonymous (nobody) Summary: Handle requests to intern string subtype instances Initial Comment: This patch implements a small modification of PyString_InternInPlace that allows for safe interning of string subtype instances. The change should be fully backward compatible -- for a rationale and discussion, see: http://mail.python.org/pipermail/python-dev/2007-February/070973.html ---------------------------------------------------------------------- >Comment By: Hrvoje Nik?i? (hniksic) Date: 2007-03-20 15:25 Message: Logged In: YES user_id=1718107 Originator: YES Thanks for the detailed analysis. I missed this case and I retract the patch until I think of a way to resolve this problem. The obvious possibility is to always copy subtype instances before attempting to intern them, but right now I don't have the time to investigate if this slows things down. As for using s = intern(str(s)) in Python, it's a start, but it does somewhat more than I'd like -- for example, it "interns" all kinds of objects, which is not desirable. My patch was written with the intention of making PyString_InternInPlace more robust wrt string subtype instances, so that all the code in core and extensions that simply calls PyString_InternInPlace keeps working without modification. In the long run, the interface of PyString_InternInPlace is a bit too undeterministic for my taste. It has no error reporting, so it silently ignores some kinds of errors (not enough memory), throws fatal error on others (non-string being passed), and also completely ignores string subtypes. In my code I use this utility function: int intern_force(PyObject **s) { if (PyString_CheckExact(*s)) /* Most likely case: we're passed an exact string. */ PyString_InternInPlace(s); else if (PyString_Check(*s)) { /* The case we're covering with this function: we got a string subtype. Intern a copy. */ PyObject *copy; copy = PyString_FromStringAndSize(PyString_AS_STRING(*s), PyString_GET_SIZE(*s)); if (!copy) return -1; Py_DECREF(*s); *s = copy; PyString_InternInPlace(s); } else { PyErr_SetString(PyExc_TypeError, "intern_force passed a non-string"); return -1; } if (!PyString_CHECK_INTERNED(s)) { /* PyString_InternInPlace failed and cleared the exception, most likely due to insufficient memory. */ PyErr_Format(PyExc_RuntimeError, "failed to intern string '%s'", PyString_AS_STRING(*s)); return -1; } return 0; } I don't expect a function like this one to become a part of Python, but PyString_InternInPlace could be usefully improved even without breaking compatibility. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-02-14 13:21 Message: Logged In: YES user_id=4771 Originator: NO Btw, any reason why you cannot simply say in your Python program: intern(str(s)) ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-02-14 13:13 Message: Logged In: YES user_id=4771 Originator: NO Ah, the code was the wrong way around. The following causes an Fatal Python error in a debug build: s1 = "hel" s1 = intern(s1 + "lo") class S(str): def __hash__(self): return 0 def __eq__(self, other): return False s = S(s1) s2 = intern(s) del s1 ---------------------------------------------------------------------- Comment By: Hrvoje Nik?i? (hniksic) Date: 2007-02-14 09:31 Message: Logged In: YES user_id=1718107 Originator: YES I don't think an attack is possible. This patch retains the property that only exact strings are interned. If you create a pathological string subtype that hashes like a different string instance (one that has already been interned), all you'll achieve is that "interning" will return the other instance. As far as I can tell, no string is actually removed from the interned dictionary (until it becomes unreachable, that is.) What is the expected result of your test code? I tried it and it ran without error. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2007-02-13 23:36 Message: Logged In: YES user_id=4771 Originator: NO I think that this opens an attack (untested, though): it allows a previously-interned string to be removed from the dictionary. This might lead to a crash because the old string still thinks it is interned. Try something along the lines of: s1 = "hel" s1 = intern(s1 + "lo") class S(str): def __hash__(self): return hash(s1) def __eq__(self, other): return other == s1 s = S("world") intern(s) del s1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1658799&group_id=5470 From noreply at sourceforge.net Tue Mar 20 22:57:12 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 14:57:12 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-19 20:32 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) >Assigned to: Neal Norwitz (nnorwitz) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2007-03-20 22:57 Message: Logged In: YES user_id=34209 Originator: NO The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.) Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Tue Mar 20 23:06:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 15:06:58 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:06 Message: Logged In: YES user_id=51702 Originator: YES File Added: fix-prefix-with-trailing-slash-problem-2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 13:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Tue Mar 20 23:08:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 15:08:05 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:08 Message: Logged In: YES user_id=51702 Originator: YES New patch fixes your concern Georg. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:06 Message: Logged In: YES user_id=51702 Originator: YES File Added: fix-prefix-with-trailing-slash-problem-2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 13:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Tue Mar 20 23:09:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 15:09:21 -0700 Subject: [Patches] [ python-Patches-659809 ] fix Makefile.pre to use config env Message-ID: Patches item #659809, was opened at 2002-12-29 14:41 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=659809&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Daniel Brotsky (brotsky) Assigned to: Nobody/Anonymous (nobody) Summary: fix Makefile.pre to use config env Initial Comment: In Python CVS head (2.3a0 as of 2002/12/29), Makefile.pre does not use the configure-specified values for CPPFLAGS or LDFLAGS (although it does use CFLAGS). This means that non-standard build environments that can be expressed to configure using these flags (such as the fink environment on Mac OS X) are not picked up properly in the Python build process. This, in turn, causes various extension modules that should build properly not to build properly. It can even cause the Python core build to fail if a CFLAGS-specified include directory requires a non-core library in the LDFLAGS directory. Fixing Makefile.pre to use CPPFLAGS and LDFLAGS as specified by configure turned up a related problem: the parser target did not properly use the standard Python linker flags when creating a separate library. The attached patch fixes both of these problems. It was created and tested on the Darwin platform; I have had no chance to test it on Linux or Solaris. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-20 15:09 Message: Logged In: YES user_id=357491 Originator: NO Closing this patch as it was already marked invalid. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-01-15 04:29 Message: Logged In: YES user_id=21627 Daniel, can you please revise this patch? It seems to me that expanding CPPFLAGS might still be ok, but expanding CFLAGS definitely is not, as Python's configure messes with CFLAGS itself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 05:41 Message: Logged In: YES user_id=6380 OK, that's not good. I'll revert the change. Sorry, Daniel. We can sort out the right way to do this after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 04:03 Message: Logged In: YES user_id=33168 I get the same thing on a clean tree: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -g -O2 -g -O? is specified twice. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 00:06 Message: Logged In: YES user_id=6380 Let me know the outcome ASAP, Skip. Unless you find this was your own mistake, I'll revert this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-12-30 21:12 Message: Logged In: YES user_id=44345 This seems to mess up straightforward builds for me on MacOSX. A simple mkdir build.trial cd build.trial ../configure generates a Makefile with these definitions: OPT= -DNDEBUG -g -O3 -Wall -Wstrict-prototypes BASECFLAGS= -Wno-long-double -no-cpp-precomp CFLAGS= $(BASECFLAGS) $(OPT) -g -O2 The "-g -O2" part is the @CFLAGS@ expansion. I don't yet know where it's coming from. I'm not 100% confident it's not related to the OPT/BASECFLAGS changes I haven't yet checked in, so I'm reopening and assigning to myself. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 13:04 Message: Logged In: YES user_id=6380 Thanks -- accepted and checked in as Makefile.pre.in 1.105. ---------------------------------------------------------------------- Comment By: Daniel Brotsky (brotsky) Date: 2002-12-29 19:40 Message: Logged In: YES user_id=337571 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=659809&group_id=5470 From noreply at sourceforge.net Tue Mar 20 23:32:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 15:32:01 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-19 13:32 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Neal Norwitz (nnorwitz) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- >Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-20 16:32 Message: Logged In: YES user_id=12364 Originator: YES I originally had the `` warning emitted during the parse stage, but this prevents it from showing when the .pyc file already exists. Which is more important? And is it an actual DeprecationWarning or a PendingDeprecationWarning? I didn't notice a way to produce a warning at both definition time and use time, without emitting it twice. I agree that both is better, so I'll figure it out. Linking to a wiki page would be far better than trying to squeeze a full explanation into one sentence. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-20 15:57 Message: Logged In: YES user_id=34209 Originator: NO The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.) Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Wed Mar 21 01:52:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 17:52:32 -0700 Subject: [Patches] [ python-Patches-1684834 ] Documentation for C-API string functions Message-ID: Patches item #1684834, was opened at 2007-03-21 01:52 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=1684834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for C-API string functions Initial Comment: This patch adds documentation for five string functions to the Python/C API reference manual. PyOS_snprintf, PyOS_vsnprintf, PyOS_ascii_strtod, PyOS_ascii_formatd and PyOS_ascii_atof. See http://www.python.org/doc/2.2.3/whatsnew/node11.html and http://www.python.org/doc/2.4.4/whatsnew/node11.html. I hope the structure is decent, I had to add a new section in the manual to fit them in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1684834&group_id=5470 From noreply at sourceforge.net Wed Mar 21 03:20:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 19:20:14 -0700 Subject: [Patches] [ python-Patches-700858 ] Replacing and deleting files in a zipfile archive. Message-ID: <200703210220.l2L2KEnJ030041@sc8-sf-db2-new-b.sourceforge.net> Patches item #700858, was opened at 2003-03-10 07:08 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=700858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.2.x >Status: Closed Resolution: Out of Date Priority: 5 Private: No Submitted By: Nev Delap (nevdelap) Assigned to: Nobody/Anonymous (nobody) Summary: Replacing and deleting files in a zipfile archive. Initial Comment: Addition of replace, replacestr and delete methods into zipfile.py. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-20 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-06 19:09 Message: Logged In: YES user_id=1115903 Originator: NO Since it seems I'm poking around in the zipfile module quite a bit lately, I'll see if I can update this patch, and add some tests and documentation updates. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-06 16:45 Message: Logged In: YES user_id=849994 Originator: NO This patch doesn't apply anymore to current SVN, so it's going to be closed unless someone updates it. ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-05-11 07:57 Message: Logged In: YES user_id=221678 Note that there is a problem with using StringIO files as zipfiles with this as they fail to truncate properly - see bug 951915 ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2004-05-11 03:24 Message: Logged In: YES user_id=221678 This patch works fine on Python 2.3, if you just add the line del self.NameToInfo[name] before the return in delete (and the first HUNK with author info isn't applied) Unfortunately I can't add a file for some reason... nevdelap, could you update the bug for Python 2.3? ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 07:19 Message: Logged In: YES user_id=730416 OK, so after refreshing it finally decided to show the files I'd added. ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 07:16 Message: Logged In: YES user_id=730416 . ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 07:15 Message: Logged In: YES user_id=730416 The file upload say "Successful" but the file isn't listed!? I've tried it several times and yes I've checked the checkbox. ---------------------------------------------------------------------- Comment By: Nev Delap (nevdelap) Date: 2003-03-10 07:14 Message: Logged In: YES user_id=730416 The file upload say "Successful" but the file isn't listed!? I've tried it several times and yes I've checked the checkbox. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=700858&group_id=5470 From noreply at sourceforge.net Wed Mar 21 03:20:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 19:20:10 -0700 Subject: [Patches] [ python-Patches-1159139 ] cgi.py invalid REQUEST_METHOD set Message-ID: <200703210220.l2L2KAm1029512@sc8-sf-db2-new-b.sourceforge.net> Patches item #1159139, was opened at 2005-03-08 08:04 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159139&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Rejected Priority: 5 Private: No Submitted By: Joe (joesalmeri) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py invalid REQUEST_METHOD set Initial Comment: Python Version 2.4 OS Windows XP SP 2 + WindowsUpdates Patch for lastest CVS Tree When the environment does not have a correctly set REQUEST_METHOD cgi.py prompts for key=value pairs by reading from sys.stdin. After the values are read from sys.stdin they are never stored in the FieldStorage.list attribute like they are when the FieldStorage.read_urlencoded or FieldStorage.read_multi methods are called. This causes a problem when FieldStorage.keys() is called because although the values were read from sys.stdin they were never stored in FieldStorage.list. Although you could argue that REQUEST_METHOD should have been set correctly in the first place, it still seems like if cgi.py is going to handle that situation by actually reading the values from sys.stdin it should store them too. This fix stores the values read. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-20 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-06 05:23 Message: Logged In: YES user_id=21627 Originator: NO I must be completely missing the point of this patch. Where in the code does it currently prompt for key=value pairs if REQUEST_METHOD is not correctly set? By "not correctly set", do you mean "not set" or "set incorrectly"? If the latter, to what value? You seem to be modifying the read_single function. This is meant to read a single body of the CGI request (as sent by the HTTP client), not the key-value-pairs. I've tried to come up with a demo application of this new functionality, but failed: I couldn't make this new code do anything useful. What Python script should I use, how should I invoke it, what environment variables should I give, and what standard input? Tentatively rejecting the patch. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-03-14 14:54 Message: Logged In: YES user_id=764593 +1 on supporting use without a REQUEST_METHOD, if only to match Perl on "what happens if my .cgi was called straight from the command line"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1159139&group_id=5470 From noreply at sourceforge.net Wed Mar 21 03:58:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 19:58:10 -0700 Subject: [Patches] [ python-Patches-1680961 ] remove sys.exitfunc, rewrite atexit in C Message-ID: Patches item #1680961, was opened at 2007-03-14 15:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: remove sys.exitfunc, rewrite atexit in C Initial Comment: This removes sys.exitfunc. atexit is rewritten in C and uses as much of the existing sys.exitfunc-infrastructure (which is renamed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-20 22:58 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54472. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 15:13 Message: Logged In: YES user_id=849994 Originator: YES You didn't attach a patch, but if you do these modification, you can check it in directly IMO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-17 21:54 Message: Logged In: YES user_id=1344176 Originator: NO - I think _clear() should keep the underscore; it's probably not something that people should be encouraged to use. - I've fixed bound method support. - I'm going to make Py_PyAtExit non-public. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 12:14 Message: Logged In: YES user_id=849994 Originator: YES Looks good, four points: - should _clear keep its underscore? - unregistering will fail with bound methods, don't know if we should do something about that - you messed up the indentation in pythonrun.c and atexit.c (spaces in the former and tabs in the latter) ;) - do we need docs for Py_PyAtExit? If not, it should be nonpublic and get a leading underscore. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 18:02 Message: Logged In: YES user_id=1344176 Originator: NO Ok, I'm sold on the two-phase atexit structure. I've updated my patch to keep atexit's handlers separate from the call_ll_exitfuncs() handlers. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 04:28 Message: Logged In: YES user_id=849994 Originator: YES It's not specified that exit handlers can do cleanup only, in theory they could do things like sending an email etc. Please let's not introduce gratuitous breakage here. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:45 Message: Logged In: YES user_id=1344176 Originator: NO It is LIFO; I was going off memory, sorry. Is your assumption that atexit.py handlers will be more likely to use functionality outside their domain than would Py_AtExit handlers? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:35 Message: Logged In: YES user_id=849994 Originator: YES Current AtExit handlers are not likely to use functionality not in their domain, though. The socket one just cleans up the socket API, the Tkinter one (which is disabled though) cleans up Tcl, etc. I thought call_ll_exitfuncs() is already LIFO. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 17:27 Message: Logged In: YES user_id=1344176 Originator: NO Doesn't that problem already exist, though, for C extensions that need sockets (or other resources) in their Py_AtExit handlers? Would changing call_ll_exitfuncs() from FIFO to LIFO (like atexit is) help this? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 17:14 Message: Logged In: YES user_id=849994 Originator: YES For example, Modules/socketmodule.c's Py_AtExit handler, for Windows, calls WSACleanup(), after which, if I understand the docs correctly, one can't use sockets anymore. That would mean that if atexit is imported before socket, all atexit-registered exitfuncs cannot use sockets. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 16:38 Message: Logged In: YES user_id=1344176 Originator: NO Isn't that (unavailable resources) a problem with atexit handlers in general, regardless of where they occur in Py_Finalize()? All existing low-level exitfuncs are already guaranteed not to mess with interpreter/thread state, simply because they can't (as things stand). If exitfuncs written against 3.0+ start messing around with Python's internal state, that's a bug in the exitfunc. We're all adults, etc. I'm attaching the new version of my patch, which includes atexit.unregister(). File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 14:01 Message: Logged In: YES user_id=849994 Originator: YES Yes, that would work for me. The issue I see with moving the low-level exitfuncs that is that the functions registered there may make resources unavailable that are necessary for Python code to run (and of course, atexit handlers can run arbitrary Python code...) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Googling turns up that the main use of atexit._exithandlers is to a) unregister a callback or b) clear all callbacks. I've already provided a _clear() function to handle (b), and an unregister() to deal with (a) shouldn't be hard. Thoughts? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 13:00 Message: Logged In: YES user_id=849994 Originator: YES What about a function to get a *copy* of the exitfuncs? (Okay, I can't see a use case right now, but maybe it helps transitioning code that inspected atexit._exithandlers before) ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 12:49 Message: Logged In: YES user_id=1344176 Originator: NO Another difference: mine uses Py_AtExit(), yours adds extra C functions like Py_SetPythonExitfunc() and call_python_exitfunc(). I'd vote against exposing the handler list to Python code. I see that leading to "run my handler first! No, mine! *scuffle*" games. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-15 03:28 Message: Logged In: YES user_id=849994 Originator: YES To summarize the differences: your code uses a C array to store the exit handlers, mine uses a Python list. Which to choose obviously depends on whether you want to make the list available to Python code... ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 02:11 Message: Logged In: YES user_id=1344176 Originator: NO Ack, I didn't know you were working on this, too! I'm attaching my own atexit implementation; the patch includes changes to Modules/Setup, test_atexit and test___all__ so that the test suite passes. One thing I'm not sure about is that I've moved call_ll_exitfuncs() up in the order of Py_Finalize(). This was necessary to make PyThreadState_GET() stop complaining about "no current thread" when calling the atexit functions at interpreter-shutdown, but I don't know enough to be sure that this change doesn't alter some assumption about finalization order. It looks alright to me, and "make test" passes, but I'd appreciate it if someone could look over that part. File Added: atexit.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-14 18:30 Message: Logged In: YES user_id=849994 Originator: YES Note that the patch is against the p3yk branch. Note also that, without changing Modules/Setup, the new module won't be built and used. In fact, the test suite doesn't pass with it since I haven't updated the tests that depend on atexit._exithandlers. But thanks for reviewing nonetheless! ---------------------------------------------------------------------- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-03-14 17:30 Message: Logged In: YES user_id=1115903 Originator: NO The attached patch didn't apply cleanly for me; the hunk that removes call_sys_exitfunc (pythonrun.c) failed, but everything else applied just fine. I removed call_sys_exitfunc manually and then everything compiled and passes regrtest.py (with -r -u all) with no unexpected skips (Linux). The docs also build just fine and I don't see any grammatical/formatting errors or anything that jumps out as a technical error (but I'm not all that familiar with atexit/exitfunc, so take my endorsement with a grain of salt ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1680961&group_id=5470 From noreply at sourceforge.net Wed Mar 21 04:48:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 20:48:59 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-19 12:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) >Assigned to: Thomas Wouters (twouters) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 20:48 Message: Logged In: YES user_id=33168 Originator: NO Thomas, should there be a 3k warning category that's a subclass of DeprecationWarning? Should this patch impl the -3k flag or whatever it's called? Damn, I really gotta get that warnings patch done. First I gotta get the buildbots in decent shape, get 2.5.1 out, then xrange patch, then warnings. That list sucks. It doesn't even include crap like get inbox less than 200 unread msgs or do taxes. :-( ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-20 15:32 Message: Logged In: YES user_id=12364 Originator: YES I originally had the `` warning emitted during the parse stage, but this prevents it from showing when the .pyc file already exists. Which is more important? And is it an actual DeprecationWarning or a PendingDeprecationWarning? I didn't notice a way to produce a warning at both definition time and use time, without emitting it twice. I agree that both is better, so I'll figure it out. Linking to a wiki page would be far better than trying to squeeze a full explanation into one sentence. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-20 14:57 Message: Logged In: YES user_id=34209 Originator: NO The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.) Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Wed Mar 21 04:53:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 20:53:52 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-19 12:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Thomas Wouters (twouters) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 20:53 Message: Logged In: YES user_id=33168 Originator: NO Oooh, Anthony pointed me to his patch: http://python.org/sf/1631035 So no need to impl anything that's in there. I don't think there's much overlap so far, but I didn't look that closely. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 20:48 Message: Logged In: YES user_id=33168 Originator: NO Thomas, should there be a 3k warning category that's a subclass of DeprecationWarning? Should this patch impl the -3k flag or whatever it's called? Damn, I really gotta get that warnings patch done. First I gotta get the buildbots in decent shape, get 2.5.1 out, then xrange patch, then warnings. That list sucks. It doesn't even include crap like get inbox less than 200 unread msgs or do taxes. :-( ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-20 15:32 Message: Logged In: YES user_id=12364 Originator: YES I originally had the `` warning emitted during the parse stage, but this prevents it from showing when the .pyc file already exists. Which is more important? And is it an actual DeprecationWarning or a PendingDeprecationWarning? I didn't notice a way to produce a warning at both definition time and use time, without emitting it twice. I agree that both is better, so I'll figure it out. Linking to a wiki page would be far better than trying to squeeze a full explanation into one sentence. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-20 14:57 Message: Logged In: YES user_id=34209 Originator: NO The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.) Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Wed Mar 21 04:54:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 20:54:36 -0700 Subject: [Patches] [ python-Patches-1631035 ] SyntaxWarning for backquotes Message-ID: Patches item #1631035, was opened at 2007-01-08 17:26 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1631035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Thomas Wouters (twouters) Summary: SyntaxWarning for backquotes Initial Comment: The following patch (for 2.6) issues a SyntaxWarning for backquotes/backticks in source code. I had to add the filename to struct compiling in Python/ast.c - this seems like the neatest way to get the filename passed around. (see also the XXX before ast_error) Assigned to twouters, since it was his idea in the first place. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 20:54 Message: Logged In: YES user_id=33168 Originator: NO Also see http://python.org/sf/1683908 that has some other warnings impl. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2007-01-08 22:55 Message: Logged In: YES user_id=29957 Originator: YES And here's another one (on top of the last one) that also emits SyntaxWarnings for <> Not sure I like 'NOTEQUALSOLD' as a token name, but I couldn't think of anything better. This one should probably be only enabled when the Py3K warnings flag is on. File Added: notequals.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1631035&group_id=5470 From noreply at sourceforge.net Wed Mar 21 05:02:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 20 Mar 2007 21:02:38 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-20 06:32 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Thomas Wouters (twouters) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2007-03-21 15:02 Message: Logged In: YES user_id=29957 Originator: NO Here's a -W py3k patch I did. Think it went to the list, not the trackers. File Added: warn3.patch ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-21 14:53 Message: Logged In: YES user_id=33168 Originator: NO Oooh, Anthony pointed me to his patch: http://python.org/sf/1631035 So no need to impl anything that's in there. I don't think there's much overlap so far, but I didn't look that closely. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-21 14:48 Message: Logged In: YES user_id=33168 Originator: NO Thomas, should there be a 3k warning category that's a subclass of DeprecationWarning? Should this patch impl the -3k flag or whatever it's called? Damn, I really gotta get that warnings patch done. First I gotta get the buildbots in decent shape, get 2.5.1 out, then xrange patch, then warnings. That list sucks. It doesn't even include crap like get inbox less than 200 unread msgs or do taxes. :-( ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-21 09:32 Message: Logged In: YES user_id=12364 Originator: YES I originally had the `` warning emitted during the parse stage, but this prevents it from showing when the .pyc file already exists. Which is more important? And is it an actual DeprecationWarning or a PendingDeprecationWarning? I didn't notice a way to produce a warning at both definition time and use time, without emitting it twice. I agree that both is better, so I'll figure it out. Linking to a wiki page would be far better than trying to squeeze a full explanation into one sentence. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-21 08:57 Message: Logged In: YES user_id=34209 Originator: NO The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.) Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Wed Mar 21 09:56:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 01:56:18 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 22:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) >Assigned to: Martin v. L??wis (loewis) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 08:56 Message: Logged In: YES user_id=849994 Originator: NO Okay, thanks. Martin, you know how to do the configure magic properly, do you want to commit this? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 22:08 Message: Logged In: YES user_id=51702 Originator: YES New patch fixes your concern Georg. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 22:06 Message: Logged In: YES user_id=51702 Originator: YES File Added: fix-prefix-with-trailing-slash-problem-2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 12:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 08:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 02:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-13 23:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 17:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 20:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 08:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Wed Mar 21 10:01:10 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 02:01:10 -0700 Subject: [Patches] [ python-Patches-1682205 ] TypeError swallowing in UNPACK_SEQUENCE opcode Message-ID: Patches item #1682205, was opened at 2007-03-16 15:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682205&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Piet Delport (pjdelport) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError swallowing in UNPACK_SEQUENCE opcode Initial Comment: When UNPACK_SEQUENCE unpacks an iterable, it replaces any TypeError raised by the iterator with a new, catch-all TypeError('unpack non-sequence') instance (and empty traceback). This message is less useful than the ones it's (presumably) intended to replace (raised by PyObject_GetIter(), via unpack_iterable()), and obviously wrong when the TypeError originates in unrelated user code. The attached patch simply removes the check, which (as far as i can tell) has no ill effects. Examples (without the patch): >>> a, b, c = 7 TypeError: unpack non-sequence >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: unpack non-sequence With the patch applied, these result in: >>> a, b, c = 7 TypeError: 'int' object is not iterable >>> a, b = ( int(x) for x in ['5', ()] ) TypeError: int() argument must be a string or a number, not 'tuple' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 09:01 Message: Logged In: YES user_id=849994 Originator: NO Committed as rev. 54480, 54481 (2.5). ---------------------------------------------------------------------- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-03-19 19:29 Message: Logged In: YES user_id=7446 Originator: NO Looks good to me. I've never seen software try to catch this error by string comparison, so I doubt it will break existing applications. The worst consequence may be that various HOWTOs will now incorrectly specify the Python output -- not a big deal. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-17 15:49 Message: Logged In: YES user_id=849994 Originator: NO It's patch, after all :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1682205&group_id=5470 From noreply at sourceforge.net Wed Mar 21 10:18:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 02:18:06 -0700 Subject: [Patches] [ python-Patches-1684834 ] Documentation for C-API string functions Message-ID: Patches item #1684834, was opened at 2007-03-21 00:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1684834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for C-API string functions Initial Comment: This patch adds documentation for five string functions to the Python/C API reference manual. PyOS_snprintf, PyOS_vsnprintf, PyOS_ascii_strtod, PyOS_ascii_formatd and PyOS_ascii_atof. See http://www.python.org/doc/2.2.3/whatsnew/node11.html and http://www.python.org/doc/2.4.4/whatsnew/node11.html. I hope the structure is decent, I had to add a new section in the manual to fit them in. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 09:18 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed in rev. 54483, 54484 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1684834&group_id=5470 From noreply at sourceforge.net Wed Mar 21 11:12:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 03:12:53 -0700 Subject: [Patches] [ python-Patches-672656 ] securing pydoc server Message-ID: Patches item #672656, was opened at 2003-01-22 20:45 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Altis (kasplat) Assigned to: Ka-Ping Yee (ping) Summary: securing pydoc server Initial Comment: It would be very simple to secure the pydoc server so that it doesn't accept connections from external boxes as well as provide for a way of extending connections to trusted hosts by keeping a list of valid IP addresses. This would make pydoc suitable for running on boxes that aren't behind firewalls, which currently it is not; most home machines don't have a firewall and are regularly port scanned by script kiddies... Since pydoc does not log connections, you can't tell who is connecting to your machine or what they are trying to reach. My solution is to simply make the default pydoc server only accept connections from the host it was started on. The change is for the DocServer class. a validIPList keeps track of the IP addresses that can legally connect to the server. The verify_request method is overridden to enforce this rule. import socket self.validIPList = ['127.0.0.1'] self.validIPList.append(socket.gethostbyname (socket.gethostname())) def verify_request(self, request, client_address): if client_address[0] in self.validIPList: return 1 else: return 0 This patch does not provide a UI change to allow the user to easily add additional IP addresses. If that is desired because of the assumption that people typically run the pydoc server not for personal use, but for a group of machines to reach, then the simplest change would be to have a checkbox for "Allow any host to connect" and then have a self.allowAny member variable to reflect that checkbox state, so the verify_request becomes def verify_request(self, request, client_address): if self.allowAny or client_address[0] in self.validIPList: return 1 else: return 0 ka ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-21 11:12 Message: Logged In: YES user_id=226443 Originator: NO Wouldn't it be easier to just bind the server to localhost? That way, the server should only listen on the loopback interface and not any of the external network interfaces. At around line 1974 of pydoc.py (Python 2.4.3)... host = (sys.platform == 'mac') and '127.0.0.1' or 'localhost' self.address = ('', port) self.url = 'http://%s:%d/' % (host, port) Replace the '' with host in self.address by default, perhaps. Then, add a host parameter to the serve function and let this be used to override the above. Expose the parameter as a command line argument. I'll come up with a patch for this at some point, I suppose. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-17 05:13 Message: Logged In: YES user_id=1720594 Originator: NO I think this is actually a good idea; but I don't think the implementation is really sufficient as it stands. Particularly, it's going to require that someone hand edit a file in Lib to adjust the behavior from the "default" of only allowing connections from localhost. A user interface is not required, but an easy to reach configuration file is, I think. Instead, I think it should read a pydoc.cfg ConfigParser file-- and just apply the defaults if said file doesn't exist. (Where to put it? I don't know. ~/pydoc.cfg?) Also, having to list specific IP addresses is going to greatly limit utility for those people who do want it more open. Some people might want to allow everyone in their subnet to access it, instead of just 'everyone' or 'specific people' as this patch implies. I don't think there's an easy way to do CIDR math in the Python library, but a simple regex in said configuration file would be plenty I imagine. Or even a list of strings you check to see if the ip address startswith. In the current form, I'd recommend rejection. I don't know if the submitter is interested in any major updates after a few years, but if they are.. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=672656&group_id=5470 From noreply at sourceforge.net Wed Mar 21 11:25:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 03:25:59 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-23 23:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 10:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 00:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 00:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 22:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 14:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 20:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 17:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 17:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 22:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 23:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 23:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 00:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 00:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 15:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Wed Mar 21 11:49:33 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 03:49:33 -0700 Subject: [Patches] [ python-Patches-1675951 ] [gzip] Performance for small reads and fix seek problem Message-ID: Patches item #1675951, was opened at 2007-03-07 18:57 Message generated for change (Comment added) made by florianfesti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Florian Festi (florianfesti) Assigned to: Nobody/Anonymous (nobody) Summary: [gzip] Performance for small reads and fix seek problem Initial Comment: This patch improves read performance of the gzip module. We have seen improvments from 20% from reading big blocks up to factor 50 for reading 4 byte blocks. Additionally this patch removes the need of seeking within the file with allows using streams like stdin as input. Details: The whole read(),readline() stack got rewritten. Core part is a new input buffer. It consists of a list of strings (self.buffer), an offset of what has already be consumed from the first string (self.pos) and the length of the (still consumable) buffer (self.bufferlen). This makes adding to and removing from the buffer cheap. It turned out that removing from the old buffer was breaking performance as for reading one byte the whole buffer had to be copied. For reading a 2k buffer in single bytes 2MB had to be copied. readline no longer uses read() but directly works on the buffer. This removes a whole layer of copying strings together. For removing the need of seeking a new readonly filelike class is used (PaddedFile). It just prepends a string to a file and uses the file's read method when the string got used up. There is probably still some space for tweaking when it comes to buffere sizes as we kept this simple. But the great performance improvments show that we can't be off that much. Performance test program and results are attached. ---------------------------------------------------------------------- >Comment By: Florian Festi (florianfesti) Date: 2007-03-21 11:49 Message: Logged In: YES user_id=1736372 Originator: YES There is a simple solution for that problem: DON'T! If you pass a file descriptor to the GzipFile class it is your responsibility that the file is a gzip file and that the file pointer is at the right position. After having a short look into original code I don't think it can cope with the use case you brought up. I'd even argue that seeking to the beginning of the file is broken behaviour. What if the gzip content doesn't start at the beginning of the file? In fact prepending some header before compressed data is quite common. If the file you where reading really had a header your example had just worked. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-16 10:06 Message: Logged In: YES user_id=1403274 Originator: NO Indeed the problem is seek() is not implementes for urllib objects. It's not a bug of your patch, sorry if I explained it bad. ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-16 09:27 Message: Logged In: YES user_id=1736372 Originator: YES There is a simple solution for that problem: DON'T! If you pass a file descriptor to the GzipFile class it is your responsibility that the file is a gzip file and that the file pointer is at the right position. After having a short look into original code I don't think it can cope with the use case you brought up. I'd even argue that seeking to the beginning of the file is broken behaviour. What if the gzip content doesn't start at the beginning of the file? In fact prepending some header before compressed data is quite common. If the file you where reading really had a header your example had just worked. ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 19:30 Message: Logged In: YES user_id=1403274 Originator: NO I applied the patch by hand, I think the problem is simply it's for python 2.6 (I have the stable 2.5 version) Anyway like I wrote for an old similar patch of another user, the patch starts to read the header at the current position, and not at the start of the file. You can see it trying this piece of code: --------------------------------------- import urllib2 import array import gzip urlfile = urllib2.urlopen(someurl) header = array.array("B") header.fromstring(urlfile.read(1)) gzfile = gzip.GzipFile(fileobj=urlfile) print gzfile.read() ----------------------------------------- Error: ------------------------------------------------------------------------------ File "c:\My Programs\Python\lib\gzip.py", line 285, in read self._read_gzip_header(self.fileobj) File "c:\My Programs\Python\lib\gzip.py", line 177, in _read_gzip_header raise IOError, 'Not a gzipped file' IOError: Not a gzipped file >Exit code: 1 ------------------------------------------------------------------------------ I don't know how you can solve this without seek() Anyway if you are interested I created the diff for Python 2.5 : http://digilander.libero.it/LucasMalor/gzip_2.5.py.diff.gz ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-15 18:43 Message: Logged In: YES user_id=1736372 Originator: YES Hm, works one Linux. Try this one File Added: gzip.py.diff ---------------------------------------------------------------------- Comment By: Lucas Malor (lucas_malor) Date: 2007-03-15 17:42 Message: Logged In: YES user_id=1403274 Originator: NO Excuse me, but I can't apply the patch. I have Windows XP without any SP and I tried to do the command patch -u gzip.py gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-09 10:24 Message: Logged In: YES user_id=1736372 Originator: YES I added checks to test_readline() and test_append(). I left the other read test untouched to keep some filename=filename coverage. BTW: I really forgot special thanks for Phil Knirsch who wrote the initial read() implementation and the performance test cases and did a lot of weaking and testing and without whom this patch would never have existed. File Added: test_gzip.py-noseek.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 21:58 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good, and the tests pass. Can you add a test that ensures that a seek() method is not necessary any more for the underlying stream? (closed #914340 which provided a similar patch as duplicate) ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:24 Message: Logged In: YES user_id=1736372 Originator: YES Added minor improvement of the unittest: Check for newlines in the readline() test code. File Added: test_gzip.py.diff ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 19:01 Message: Logged In: YES user_id=1736372 Originator: YES File Added: results.txt ---------------------------------------------------------------------- Comment By: Florian Festi (florianfesti) Date: 2007-03-07 18:58 Message: Logged In: YES user_id=1736372 Originator: YES File Added: test_gzip2.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1675951&group_id=5470 From noreply at sourceforge.net Wed Mar 21 11:14:44 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 03:14:44 -0700 Subject: [Patches] [ python-Patches-1301512 ] desktop module (providing startfile as open, all platforms) Message-ID: Patches item #1301512, was opened at 2005-09-23 18:30 Message generated for change (Settings changed) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Nobody/Anonymous (nobody) Summary: desktop module (providing startfile as open, all platforms) Initial Comment: Currently, in Python's standard library, there is apparently no coherent, cross-platform way of getting the user's environment to "open" files or resources (ie. show such files in browsers, editors) when requested by a Python program. There is an os.startfile function which works for Windows, but no equivalent function for other desktop environments - the webbrowser module seems to employ alternative mechanisms in choosing and running external programs and presumably does not seek to provide general support for non-URL resources anyway. Since desktop environments like KDE and GNOME provide mechanisms for running browsers and editors according to the identified type of a file or resource, just as Windows "runs" files or resources, it is appropriate to have a module which accesses these mechanisms. Attached is a simple module which seeks to support KDE, GNOME and Windows - the latter using the existing os.startfile support - and which could be extended to support other desktop environments such as Mac OS X, XFCE, CDE (along with others deemed important and feasible enough to support). Note that this approach is arguably better than that employed by the webbrowser module since most desktop environments already provide mechanisms for configuring and choosing the user's preferred programs for various activities, whereas the webbrowser module makes relatively uninformed guesses (eg. opening Firefox on a KDE desktop configured to use Konqueror as the default browser). Note also that the startfile function is arguably misplaced in the os module; thus, this functionality is supplied as a new module rather than as a patch to the os module, and the name of the function is "open" (like in the webbrowser module) rather than "startfile" which is a fairly Windows specific term. One could also envisage the desktop module residing within the os package to avoid top-level namespace pollution. Recent discussion in the comp.lang.python thread "Open PDF" covering this issue can be found here: http://groups.google.no/group/comp.lang.python/browse_frm/thread/8e00f7c1ccfae166/6168b6728cf64cb7 ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2006-08-03 00:42 Message: Logged In: YES user_id=226443 I've relicensed the module and hereby withdraw it from consideration. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=226443 Another reference to DESKTOP_LAUNCH: http://www.openoffice.org/issues/show_bug.cgi?id=37708 ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-10-01 01:54 Message: Logged In: YES user_id=226443 I've removed the attachments from this item and uploaded a proper package to PyPI: http://www.python.org/pypi/desktop I still think it's worth keeping this item open, even though it was never really a patch as such, because I still believe the need is there for the standard library. Moreover, I've licensed the code according to the PSF criteria in order to satisfy that eventual objective. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 12:50 Message: Logged In: YES user_id=261020 Mike: I'm unpersuaded, but I've nothing to add to what I've already said, so I'll shut up now :-) ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-27 12:07 Message: Logged In: YES user_id=226443 Well, the latest attachment (the first in the list) goes some way towards providing user override support. I've since posted to the xdg mailing list asking for clarification about environment variables. As for the code, I've now changed the way the environment variable is used - it must be a shell-quoted command plus optional arguments. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-27 03:14 Message: Logged In: YES user_id=93910 I purposely avoided dealing with the "better off using os.system" before, because I didn't think it was relevant. Since you seem to think it's right, let's deal with it. First of all, the code isn't that simple. You want a convention for your environment variable that's flexible enough to deal with the three cases (kde, gnome and OS X) we already have. Just tossing a string to Popen won't cut it. The split() done by the current implementation is problematical - OS X at the very least comes with standard directories with spaces in their names. I'm not proposing a solution to that here - just pointing out the problem. You're advocating that, instead of putting this functionality in desktop, we leave it up to every application writer to write it. That means - at the very least - that every application writer now has to write if os.environ.has_key("DESKTOP_LAUNCH"): else: desktop.open(filename) rather than simply doing: desktop.open(filename) It also means that every application writer has to decide how they're going to deal with possible spaces in the file name in the environment variable, or if they are at all. And they also get to decide which of the various proposed environment variable names they want to use. If the user is lucky, they won't have two applications that use the same name with different conventions. If not, well, that would just suck. Second, if another a standard does emerge, you can fix all the applications by fixing *one* file in stdlib. Better yet, ithe fix can be transitioned in smoothly for all applications by working with that one file. Basically, *not* providing this hook is simply poor software engineering - it makes things harder on the developers, harder on the users, and harder on the maintainers in the future. While not wanting to push forward standards may be a good thing, it's certainly not a reason for doing a wrong thing. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-27 02:20 Message: Logged In: YES user_id=261020 Quite correct about desktop meaning (roughly) what it says, rather than "opener": my mistake. And I see we are all in agreement about what environment variables are for. But, as Paul says, """the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point.""" The correct way of dealing with things like these proposed opener environment vars in the Python stdlib at this point in time (in the absence of anything very close to an accepted wider standard) is for applications to do this: if os.environ.has_key("USER_KNOWS_BETTER"): obey_user(fn) else: desktop.open(fn) where one would expect obey_user() to be a one-liner: def obey_user(fn): subprocess.Popen(os.environ["DESKTOP_OPENER"]) So what is to be gained by baking some random new "standard" into the Python stdlib? Clearly, any individual application obeying some such environment var gains little without others following suit with the *same* env var, but that is no reason to include code knowing about eg. OPENER in the stdlib; in fact, that's precisely the reason such code shouldn't be included right now: we don't know what env var (or other mechanism) other apps will end up using. I don't think de facto semi-standardisation across "applications using Python 2.5 and the desktop module" is likely to gain much momentum or prove very useful to the vast majority of end users, but it does make life that extra little bit more complicated for future users and maintainers of Python, and for users and maintainers of applications wishing to "start" files. I suppose you could try and argue that OPENER is simply an implementation detail of open() that should be changed when and if some standard env var name or other mechanism becomes popular, but that doesn't make sense to me: first, we would be exposing this detail to "end-users" (or else what use is it), and second, the presence of code such as the if os.environ.has_key("OPENER") in the last version of desktop.py I looked at makes life slightly *harder* for applications who know about newer, more widespread conventions than some old version of desktop.py knows about. Finally, I don't know what to make of your (Mike) comment that "neither of those carries as much weight with me as running code". Writing code is simply not the problem here: the (obey_user()) code is almost as simple as it gets. The problem here is almost entirely about getting agreement with other people, which, yes, means sometimes-tiresome discussions. Sometimes it means trying to generate de-facto standards and leave those tiresome discussions in the dust, agreed: I guess I'm stating my opinion here that the Python stdlib is not the place to do that, for the reasons I enumerated above and in my ealier post (2005-09-26 00:34). Foolishly trusting in the sanity of humankind, I think that KDE and GNOME will *eventually* get their act together. Am I just totally wrongheaded about this? OK, I must stop this nonsense, perhaps this is just one of those bikesheds... ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 15:08 Message: Logged In: YES user_id=226443 I've now attached another version of the module which observes DESKTOP_LAUNCH, does a bit more verification, and exposes the desktop detection. I'll probably do a bit more reading of the fd.o mailing lists and possibly try and get some answers from the interested parties. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 04:25 Message: Logged In: YES user_id=93910 Actually, the guess that the module makes is which desktop the user is on - and that's overridable by the "desktop" argument. The pre-OPENER version of desktop.py had no way to override it's choice of opener - the best you can do is tell it to use the default opener for some desktop it knows about. Further, the "desktop" argument is really only applicable to the application developer. The end-user - the person who actually chooses the launcher to use - can't use it without editing the source to the application. While you may consider this an acceptable configuration mechanism, I don't. The standard Unix mechanism for setting things like this - dating back to the 70s - is an environment variable that names the command to use. If you want to suggest a better mechanism, feel free to do so. Until then the question is what the name should be. Based on what the freedesktop talk, maybe it shold be DESKTOP_OPEN or DESKTOP_LAUNCH. On the other hand, the freedesktop folks seem much better at generating discussion than specifications - and neither of those carries as much weight with me as running code. Part of this does depend on the point of the desktop module. I thought it was to make os.startfile functionality available in a platform-independent manner. If so, it needs to deal with things other than the tools provided by a couple of common desktops. If instead it's supposed to provide access to the knowledge built into the most popular desktops, then ignoring user preferences is reasonable. But that makes it much less usefull. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:55 Message: Logged In: YES user_id=226443 Oh, and after the DESKTOP specification, there was the DESKTOP_LAUNCH specification: http://lists.freedesktop.org/archives/xdg/2004-August/004489.html Things happen slowly in desktop standardisation land. Searching for usage of DESKTOP_LAUNCH revealed this interesting script: http://www.mail-archive.com/dashboard-hackers%40gnome.org/msg00762/desktop-launch ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:45 Message: Logged In: YES user_id=226443 On environment variables, here's a thread discussing them: http://lists.freedesktop.org/archives/xdg/2004-December/005553.html The discussion ranges from environment variables referring to the desktop (DESKTOP) and a launcher (DESKTOP_LAUNCH) or some kind of information program (DESKTOP_CTL), all the way to such variables referencing .so files which are then dlopened. The abstraction elevator/escalator is thankfully stopped before things get any more complicated. A previous thread (mentioned in the above thread) proposes the DESKTOP variable and the alternative DESKTOP_OPEN variable: http://lists.freedesktop.org/archives/xdg/2004-May/003942.html The above thread continues here, proposing DESKTOP again along with a desktop-open script, later shifting to some people favouring DESKTOP_LAUNCH and some favouring a desktop-launch script: http://lists.freedesktop.org/archives/xdg/2004-May/003995.html A standards document mentioned in the last thread: http://primates.ximian.com/~michael/desktop.txt ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-26 02:14 Message: Logged In: YES user_id=226443 Actually, "desktop" just provides a way of saying "I'm on KDE not GNOME!" or something similar; the decisions then made by the function aren't themselves configurable, but then a developer would arguably be better off using os.system at that point. The module is really supposed to encapsulate knowledge about how to start programs in various desktop environments, along with a means to detect those environments in the first place. If you as a programmer disagree with the detection, override it; if you as a programmer know better, don't use the function... but do send a patch! As for user overrides, something like OPENER might be needed to get around the decisions taken in the module, although something "lighter" like DESKTOP might also be useful to override just the detection. It astounds me that such simple things haven't been agreed on by the freedesktop people, or at least not in any obvious way. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-26 01:34 Message: Logged In: YES user_id=261020 Why does the desktop module need something more than Paul's "desktop" argument? (Though perhaps "desktop" is not a sufficiently general name, as I think you said.) I don't think it's desirable for Python to start introducing half-baked and nonstandard environment variable conventions, especially in this area. 1. Why should other people start following *Python*'s convention here? 2. Any such convention may be overtaken by efforts with more backing (such as freedesktop), leaving us with cruft in the stdlib, perhaps even cruft that's in conflict with the new standards (what if somebody with actual clout mandates START instead? something will break). 3. Any program that wants to can follow this supposed OPENER convention, without needing to bake it into the stdlib. Having said all that, if you can get agreement from people at freedesktop to agree on OPENER (which might well be possible), and I guess set a useful default at desktop startup, I will worship at your feet ;-) I'm not sure what you mean by "the guesses that the module makes". It makes exactly one guess: which opener to use, and that guess is overridable with the "desktop" argument to open(). ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-26 00:01 Message: Logged In: YES user_id=93910 I suggested OPENER because I saw it in use somewhere while looking for things for open. I couldn't find it when I went looking for it to reply to this. Clearly, the desktop module needs some way for the user to say "I don't care what you think the system looks like - use *this*." If there's a standard for that, we should use it. If there isn't a standard, we get to establish one. Putting it in the beta version so people can play with it is a good idea. Until the module is accepted, nothing is wired down, and testers should know that. Open has been announced in a number of places. It doesn't have it's own web page yet. You can find a link to the tarball at http://www.mired.org/downloads/. It's also listed in PyPI. Other than it's existence showing that desktop needs a way for user to override the guesses the module makes (which the OSS launch tool does for OS X as well), this isn't really the place to discuss open. I've addressed the issues raised here about open in the README file that was posted in the 0.3 version. Further discussion should go to me directly, or to the Python list/newsgroup. If you think it belongs in another forum, please let me know. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2005-09-25 17:57 Message: Logged In: YES user_id=261020 If OPENER is not standard in any way (ad hoc or otherwise), why add it? Moght not doing that without talking to other people about it (presumably on freedesktop, including GNOME, KDE. etc. people) be positively harmful? Mike: is this Python version of Apple's "open" actually published on the web somewhere? I can't find it. I also notice that "open" is already in use as a shell wrapper around open (2) the system call. "start" seems unused, FWTW here. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2005-09-25 16:26 Message: Logged In: YES user_id=226443 I've uploaded a version which supports OPENER, although I can't find any references to that variable anywhere. By the way, I wonder if the open program's preferences couldn't somehow work with the various freedesktop.org standards if they don't already. ---------------------------------------------------------------------- Comment By: Mike Meyer (mwm) Date: 2005-09-25 03:01 Message: Logged In: YES user_id=93910 open is a desktop-independent variation on gnome-open and kfmclient. So it's something that desktop could be set up to run, using cmd = ["open", url]. On the other hand, it also exposes an API to Python progams, so you could (in theory) replace Unix-specific parts of desktop with (using the development version): from open import run run(filename, have = ['open']) except that it'd use the users "open" preferences instead of their desktop preferences. This is why I proposed the OPENER environment variable. I don't run a desktop, so the proposed version would default to trying os.startfile. I'd rather it use open. KDE Components->File Associations to do that. All of those editors are installed on my machine. Then I attempted to open this text file: $ file /home/john/test.txt /home/john/test.txt: ASCII text $ cat /home/john/test.txt hello, world $ When I open it by clicking on it from a Konqueror directory listing, GNU emacs running in an X11 window starts up, with the specified file opened. When I use your module: $ python2.4 Python 2.4 (#1, Feb 19 2005, 23:54:54) [GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import desktop >>> desktop.open("/home/john/blocking.txt") >>> ...it opens in Konqueror with some embedded editor (KEdit or KWrite, I assume), not directly in any of the editors I specified, and certainly not in emacs. Same applies if I use a URL: >>> desktop.open("file:///home/john/test.txt") This doesn't seem to be the intended behaviour of your module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1301512&group_id=5470 From noreply at sourceforge.net Wed Mar 21 15:20:36 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 07:20:36 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Martin v. L??wis (loewis) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2007-03-21 15:20 Message: Logged In: YES user_id=21627 Originator: NO I think the problem with this patch is that % substitution is not widely available in /bin/sh. For example, on Solaris 9, /bin/sh gives 'bad substitution'. Even /usr/xpg4/bin/sh rejects it. So I think this should be redone using, say, sed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 09:56 Message: Logged In: YES user_id=849994 Originator: NO Okay, thanks. Martin, you know how to do the configure magic properly, do you want to commit this? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:08 Message: Logged In: YES user_id=51702 Originator: YES New patch fixes your concern Georg. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:06 Message: Logged In: YES user_id=51702 Originator: YES File Added: fix-prefix-with-trailing-slash-problem-2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 13:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Wed Mar 21 16:36:56 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 08:36:56 -0700 Subject: [Patches] [ python-Patches-1577756 ] whitespace in `svnversion .` Message-ID: Patches item #1577756, was opened at 2006-10-15 19:33 Message generated for change (Comment added) made by ascotan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 2 Private: No Submitted By: Daniel Str?nger (schmaller) Assigned to: Georg Brandl (gbrandl) Summary: whitespace in `svnversion .` Initial Comment: gcc (version 3.4.4) fails to compile Modules/getbuildinfo.c, since it works as documented and cuts the definition of SVNVERSION at the first newline and so there is an unbalanced double quote. citation of the gcc manpage: -D name=definition Predefine name as a macro, with definition definition. The contents of definition are tokenized and processed as if they appeared during translation phase three in a #define directive. In particular, the definition will be truncated by embedded newline characters. ---------------------------------------------------------------------- Comment By: ascotan (ascotan) Date: 2007-03-21 15:36 Message: Logged In: YES user_id=1749372 Originator: NO This problem popped up in the python2.5 tarball that is publicly available through python.org when I was building on a 64-bit linux machine. The quotations are unbalanced still in the Makefile producing a compiler error. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-08 20:47 Message: Logged In: YES user_id=849994 Originator: NO German output shouldn't have happened. It turns out that LANG=C isn't the correct env var to force English output, now using LC_ALL=C in rev. 52970, 52971 (2.5). ---------------------------------------------------------------------- Comment By: Daniel Str?nger (schmaller) Date: 2006-12-07 23:59 Message: Logged In: YES user_id=922469 Originator: YES Now I've found the error (and the solution). The culprit is the german version of svnversion: it returns the string "exportiert ". Notice the trailing space character. This leads to the following expansion for #> gcc -DSVNVERSION=\"`svnversion -n .`\" ... gcc -DSVNVERSION=\"exportiert \" ... and so SVNVERSION gets the value: <"exportiert>. To solve this problem, the value of the macro SVNVERSION must again be enclosed by double-quotes, as you can see in the patch file. Best regards, Daniel File Added: svnversion_whitespace.patch ---------------------------------------------------------------------- Comment By: Daniel Str?nger (schmaller) Date: 2006-10-15 21:12 Message: Logged In: YES user_id=922469 The patch don't fix it and i think it's not a problem of Python. I apologize for spamming the patch system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 From noreply at sourceforge.net Wed Mar 21 17:12:27 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 09:12:27 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-21 17:12 Message: Logged In: YES user_id=21627 Originator: NO The test fails on Windows. In particular, this test: self.assertEqual(posixpath.relpath(os.path.abspath("a")), "a") fails. os.path.abspath("a") gives something like r"c:\python26\a". posixpath.relpath is then not able to cope with it. As a result, it returns r"c:\python26\a" as the relative path. Using posixpath.abspath doesn't help, either, since that will give r"c:\python26/a" which relpath then still cannot process correctly. One solution would be to use pass a POSIX path and start path to relpath; the other would be to use os.path in both cases. os.path.relpath(os.path.abspath("a")) does indeed give "a" on Windows. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 23:16 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54419. Thanks for the patch, Richard! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:24 Message: Logged In: YES user_id=849994 Originator: NO Since there is an "Availability" remark, I wouldn't be concerned. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 04:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 22:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 15:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 19:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 12:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 18:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Wed Mar 21 17:24:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 09:24:01 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 18:32 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 13:24 Message: Logged In: YES user_id=752496 Originator: YES I updated the patch, reflecting discussion on python-dev: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it update sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 15:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 15:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 13:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 18:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Wed Mar 21 17:46:38 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 09:46:38 -0700 Subject: [Patches] [ python-Patches-1490190 ] add os.chflags() and os.lchflags() where available Message-ID: Patches item #1490190, was opened at 2006-05-17 13:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: M. Levinson (levinsm) Assigned to: Martin v. L?wis (loewis) Summary: add os.chflags() and os.lchflags() where available Initial Comment: The return value from os.stat() includes st_flags on some systems, but currently there's not much that can be done with the value; this patch aims to make st_flags useful by adding some associated constants to stat.py and the corresponding chflags() and lchflags() functions in posixmodule. For completeness, shutil.copystat() is also updated to call os.chflags() where it's available. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-21 17:46 Message: Logged In: YES user_id=21627 Originator: NO nnorwitz, can you please report whether the attached patch fixes it? File Added: chflags.diff ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 07:42 Message: Logged In: YES user_id=33168 Originator: NO It looks like Tru64 does have some version of chflags, however, it is undocumented and apparently causes python to exit. It is at least one of the reasons for the recent buildbot failures: http://python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/1550/step-test/0 That doesn't really tell the whole story, but I logged on to the machine and ran the test, after modifying unittest to flush the stream, sigh :-( and got this: ringneck:/net/cci/nnorwitz/python/trunk.norwitz-tru64/nn-work-build % ./python -E -tt ./Lib/test/regrtest.py -v test_posix test_posix testNoArgFunctions (test.test_posix.PosixTester) ... ok test_access (test.test_posix.PosixTester) ... ok test_chdir (test.test_posix.PosixTester) ... ok test_chflags (test.test_posix.PosixTester) ... Bad system call ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-02-19 11:56 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r53826. ---------------------------------------------------------------------- Comment By: M. Levinson (levinsm) Date: 2006-05-19 13:47 Message: Logged In: YES user_id=1522893 In addition to MacOS, chflags(2) is available on FreeBSD, OpenBSD, and NetBSD. The flags in Lib/stat.py are the full set of available values although, as you noted, MacOS hasn't (yet) implemented several of them. Thanks for the comments - I've attached an updated version of the patch incorporating your suggestions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-05-19 09:31 Message: Logged In: YES user_id=33168 What operating systems is this available on? The only one I've found is OS X. The man page says it's from BSD 4.4. I tried on Linux of various flavors (4+), Solaris, and Tru64. None of them had chflags. I also could only find some of the flags in my sys/stat.h that were added to stat.py. stat.h didn't have UF_NOUNLINK, SF_NOUNLINK, SF_SNAPSHOT. As far as the patch itself, it looks good. There are a couple of changes if this should be accepted though: doc needs \versionadded{2.5}, I would prefer flags as the var name rather than i in posixmodule.c (btw you shouldn't need to init path). Also would need to update Misc/NEWS and ACKS if accepted. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 16:24 Message: Logged In: YES user_id=849994 Patch looks good. Do we want to include it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490190&group_id=5470 From noreply at sourceforge.net Wed Mar 21 18:12:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 10:12:32 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 16:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 13:12 Message: Logged In: YES user_id=6380 Originator: NO I may have missed some of the discussion, but I don't understand why it is so important to differentiate between explicit timeout=None and omitting timeout altogether. I would favor a version where the timeout defaults to None, is a simple positional argument to _create_connection(), and the settimeout() call is skipped when timeout is None. I also favor making create_connection() public again since it may be useful for user code or 3rd party libraries that implements some protocol. After all the reality is probably that people have copied the exact loop that's found in httplib and 5 other places into their code anyway, if they care at all about IPv6 support. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 12:24 Message: Logged In: YES user_id=752496 Originator: YES I updated the patch, reflecting discussion on python-dev: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it update sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 14:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 14:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 12:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 17:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Wed Mar 21 19:02:50 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 11:02:50 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 14:23 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 14:02 Message: Logged In: YES user_id=1344176 Originator: NO Since the trouble is os.getcwd() returns a non-posix path on Windows, I've taken the approach of mocking os.getcwd() so that it returns something posix-y. Martin, could you verify that the attached patch works on Windows? File Added: test_posixpath.py.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-21 12:12 Message: Logged In: YES user_id=21627 Originator: NO The test fails on Windows. In particular, this test: self.assertEqual(posixpath.relpath(os.path.abspath("a")), "a") fails. os.path.abspath("a") gives something like r"c:\python26\a". posixpath.relpath is then not able to cope with it. As a result, it returns r"c:\python26\a" as the relative path. Using posixpath.abspath doesn't help, either, since that will give r"c:\python26/a" which relpath then still cannot process correctly. One solution would be to use pass a POSIX path and start path to relpath; the other would be to use os.path in both cases. os.path.relpath(os.path.abspath("a")) does indeed give "a" on Windows. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 18:16 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54419. Thanks for the patch, Richard! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 04:24 Message: Logged In: YES user_id=849994 Originator: NO Since there is an "Availability" remark, I wouldn't be concerned. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 23:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 16:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 09:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 13:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 06:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 12:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 07:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 02:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Wed Mar 21 19:16:58 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 11:16:58 -0700 Subject: [Patches] [ python-Patches-675698 ] New block cipher API Message-ID: Patches item #675698, was opened at 2003-01-27 15:05 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: New block cipher API Initial Comment: This is a preliminary, pure-Python implementation of a new block cipher API, superseding PEP 272 (I've been in contact with Andrew about it and he says it's ok). It's loosely patterned after the Java cipher classes, but less fancy and maybe more Pythonic. The API is divided into two layers, a "codebook" layer which implements a raw block cipher (like DES or AES), and a "modes of operation" layer which implements the standard FIPS modes (ECB, CTR, CBC, CFB, OFB) by calling the codebook layer. There's just one "modes of operation" module, which can call any codebook interchangeably. This makes more sense to me than PEP 272, which required each codebook module to implement all the FIPS modes itself. I'm hoping to finalize the API and submit a C implementation, along with C implementations of DES/3DES and AES in time for 2.3a2. I'm submitting this Python version as a patch per Andrew's suggestion, to get it onto the radar for upcoming releases. The Python version includes 64- and 128-bit block ciphers based on the Luby-Rackoff construction with SHA1 as the round function. This is mainly for reference and testing purposes--while these ciphers should be secure, they're pretty slow and won't interoperate with anything else out there. There is a test harness included, "test.py", which works under Linux and Cygwin. It won't work under Windows because it depends on a random number module (included) that uses a Linux system device. I have a separate effort (i.e. search for volunteers with Windows dev tools) to provide a Windows RNG that calls the Windows CAPI to get random numbers. Note: I haven't tested the Python implementation extensively, since it's intended as a throwaway. Don't use it for anything serious. Before submitting a C module, I'll make sure that all the FIPS test vectors work for all the modes. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 14:16 Message: Logged In: YES user_id=1344176 Originator: NO The referenced tarball's fips.py fails to import ("No module named aes"), and the four year-old c.l.p thread I found about this (http://mail.python.org/pipermail/python-list/2003-January/183331.html) didn't seem to go anywhere. If you're still interested in this, write up a formal proposal to amend or supersede PEP 272 and submit it to python-dev, targeting either Python 2.6 or 3000. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2003-01-27 15:09 Message: Logged In: YES user_id=72053 Somehow the file attachment didn't work. Oh well. The reference implementation is at: http://www.nightsong.com/phr/crypto/blockcipher.tgz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470 From noreply at sourceforge.net Wed Mar 21 19:43:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 11:43:01 -0700 Subject: [Patches] [ python-Patches-675698 ] New block cipher API Message-ID: Patches item #675698, was opened at 2003-01-27 20:05 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: New block cipher API Initial Comment: This is a preliminary, pure-Python implementation of a new block cipher API, superseding PEP 272 (I've been in contact with Andrew about it and he says it's ok). It's loosely patterned after the Java cipher classes, but less fancy and maybe more Pythonic. The API is divided into two layers, a "codebook" layer which implements a raw block cipher (like DES or AES), and a "modes of operation" layer which implements the standard FIPS modes (ECB, CTR, CBC, CFB, OFB) by calling the codebook layer. There's just one "modes of operation" module, which can call any codebook interchangeably. This makes more sense to me than PEP 272, which required each codebook module to implement all the FIPS modes itself. I'm hoping to finalize the API and submit a C implementation, along with C implementations of DES/3DES and AES in time for 2.3a2. I'm submitting this Python version as a patch per Andrew's suggestion, to get it onto the radar for upcoming releases. The Python version includes 64- and 128-bit block ciphers based on the Luby-Rackoff construction with SHA1 as the round function. This is mainly for reference and testing purposes--while these ciphers should be secure, they're pretty slow and won't interoperate with anything else out there. There is a test harness included, "test.py", which works under Linux and Cygwin. It won't work under Windows because it depends on a random number module (included) that uses a Linux system device. I have a separate effort (i.e. search for volunteers with Windows dev tools) to provide a Windows RNG that calls the Windows CAPI to get random numbers. Note: I haven't tested the Python implementation extensively, since it's intended as a throwaway. Don't use it for anything serious. Before submitting a C module, I'll make sure that all the FIPS test vectors work for all the modes. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2007-03-21 18:43 Message: Logged In: YES user_id=72053 Originator: YES >From the clpy discussion it became apparent that the maintainers weren't likely to accept a module like this for the distribution, because of concerns that distributing the crypto functions might cause legal problems in some countries. If that has changed then I'm willing to do more work on the module. I do vaguely remember something about aes.py going missing. If someone cares I can maybe figure out what happened. However, it should be possible to test the module with just the sha1-based ciphers. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 18:16 Message: Logged In: YES user_id=1344176 Originator: NO The referenced tarball's fips.py fails to import ("No module named aes"), and the four year-old c.l.p thread I found about this (http://mail.python.org/pipermail/python-list/2003-January/183331.html) didn't seem to go anywhere. If you're still interested in this, write up a formal proposal to amend or supersede PEP 272 and submit it to python-dev, targeting either Python 2.6 or 3000. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2003-01-27 20:09 Message: Logged In: YES user_id=72053 Somehow the file attachment didn't work. Oh well. The reference implementation is at: http://www.nightsong.com/phr/crypto/blockcipher.tgz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=675698&group_id=5470 From noreply at sourceforge.net Wed Mar 21 20:52:26 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 12:52:26 -0700 Subject: [Patches] [ python-Patches-1489771 ] Updates to syntax rules in reference manual Message-ID: Patches item #1489771, was opened at 2006-05-16 21:09 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: Updates to syntax rules in reference manual Initial Comment: I tried to update the reference manual to the current Python syntax. Some things are still missing, most notably the yield expression. Detailed description of changes below. I can also attach the generated webpages, if someone is interested. Expressions =========== List Displays ------------- Reordered the rules so that the style is consistent with the rest of the manual. Separated listmaker into expression_list and list_comprehension, for better readability. Replaced "expression_list" between "for" and "in" with "target_list". See this thread for details: http://mail.python.org/pipermail/python-dev/2006-April/064264.html The only thing missing is old_lambdadef. Generator Expressions --------------------- Simmilar as above. Calls ----- Fixed the latex syntax (somebody forgot to remove a line when generators were introduced). Replaced test with expression. Fixed allowed positions for commas (func(*args,) is not allowed). Boolean operations ------------------ Restructured the new conditional expression so that it is more readable. Simple Statements ================= Augmented assignment statements ------------------------------- Removed comments from "productionlist" macro, since they broke the generated grammar.txt file. Removed empty groups that are not needed anymore, since automatic conversion to guillemets was disabled. Unfortunately the escaped operator characters would still need manual fixing in the grammar.txt file. The print statement ------------------- Removed all uses of the "optional" macro and replaced them with sqare brackets, since it broke the generated grammar.txt file. The import statement -------------------- Replaced all invalid uses of name with identifier. Added relative import notation to the grammar section. Description of relative imports is still needed. The exec statement ------------------ Corrected a minor mistake, since exec "a = 1" or "a = 2" is not valid Python syntax. Added a (commented out) section about a strange feature (you can already treat exec as a function) that should IMHO be included in documentation and its use encouraged over the current notation. Compound statements =================== The with statement ------------------ Added missing macro. Function definition ------------------- Cleaned up "parameter_list" so that it is correct and expresses all the restrictions, but is still easier to understand (I hope). Still needed ------------ Yield became an expression in version 2.5, but this is not documented. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-21 20:52 Message: Logged In: YES user_id=1326842 Originator: YES Ok, here is the final version. There was a whole section missing (generator expressions), so it took some time to complete. I also removed the function call and function definition changes, because I couldn't understand them anymore :). Those changes were more or less cosmetical anyway. I'll leave the patch open until tomorrow, and then check it in if there won't be any objections. File Added: reference_manual_final.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:23 Message: Logged In: YES user_id=849994 Originator: NO You can probably look at this/complete it and apply it yourself now ;) ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 15:33 Message: Logged In: YES user_id=1326842 Yes, the only thing missing was old lambda. The new patch ('reference_manual_old_lambda') includes it. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 13:01 Message: Logged In: YES user_id=849994 The testlist in list comprehensions ("testlist_safe" in Grammar/Grammar) is different from the normal testlist. Does your patch address this? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 01:56 Message: Logged In: YES user_id=1326842 Attaching a patch updated to the current trunk with two minor fixes: - I reverted the changes to the __future__ statement because they broke the output; - fixed a mistake in the function definition section; I didn't know that ``def f(a, (b, c)=(1, 2)): pass`` is valid syntax. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-18 05:46 Message: Logged In: YES user_id=1326842 I created another patch and updated the previous two with the following fixes: - Disabled an example of the EBNF notation in introduction to prevent name clashes and inclusion into the generated grammar file. - yield can be a bare statement in 2.5. - Reintroduced "name" in import statements, so that explanation can stay the same. - Reformated __future__ import statement, but left the latex syntax broken so that it still won't be included into grammar.txt. - Fixed a paragraph about valid __future__ features. The new patch is more of an example how hard it would be to synchronise the names. It is more or less consistent with the Grammar file, but as a consequence is completely out of sync with the surrounding text. While I would like to see less differences betwen Grammar and Reference manual, I don't think it is that easy, since someone would also have to check the rest of the text and fix all incorrect references. I would guess that the same holds for changing the Grammar file; you would simply have to change too much code. I think that the simplest solution is to add the table from my previous comment to the PEP 306. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:55 Message: Logged In: YES user_id=764593 I agree that it would be better if they were consistent. But does the manual have better names? If so, alpha is a good time to fix the grammar file. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-17 18:54 Message: Logged In: YES user_id=1326842 Token names in reference manual already differ from those in Grammar file. I only added new tokens where it helps readability: - I've split listmaker into expression_list (already present in reference manual and often used) and list_comprehension. - I added conditional_expression, because I thought it helps readability. - Differences in function definiton and call syntax can't be avoided since Grammar file doesn't express all the limitations. - Same goes for target_list; Grammar uses testlist, but that was one of the problems raised in the thread mentioned above. The biggest problem is that what is known as "test" in Grammar/Grammar, is "expression" in the reference manual, and I think I fixed all parts that didn't take this in cosideration. I'm attaching two new patches. reference_manual_updated.diff contains another fix (removed unneeded markup and comments), but is otherwise the same as the previous patch. reference_manual_conservative.diff also contains this fix, but removes tokens list_comprehension and conditional_expression. This means that there are still large differences between Grammar file and reference manual, most notably: Grammar manual --------------------------------------------- NAME identifier expr or_expr test expression old_test test testlist expression_list | target_list testlist_safe testlist All of these differences were already present before my changes. Let me know if you want them fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 17:01 Message: Logged In: YES user_id=849994 I think the token names in the reference should not be different from those in python/Grammar/Grammar. Aside from this, the patch is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 From noreply at sourceforge.net Wed Mar 21 23:05:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 15:05:30 -0700 Subject: [Patches] [ python-Patches-1685563 ] MSVCCompiler creates redundant and long PATH strings Message-ID: Patches item #1685563, was opened at 2007-03-21 18: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=1685563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Scott Dial (geekmug) Assigned to: Nobody/Anonymous (nobody) Summary: MSVCCompiler creates redundant and long PATH strings Initial Comment: The current code in MSVCCompiler.initialiaze will throw an OSError on the assignment to os.environ['path'] after repeated usages of MSVCCompilers because the string produced may exceeed 4096 characters (usually after several compilations). In the call to initialize, the needed paths for compiling via the compiler selected are added on to the front of the path regardless of what the current path is set to be. This is bad because we could be adding redundant paths (and thus exceeding the 4096 character limit needlessly) Furthmore, this happens regularly whenever anyone uses the VCToolkit2003 compiler because you end up in the "if self.__version >= 7:" control path of get_msvc_paths which merely returns the current path back to the callee. This results in initialize /duplicating the entire path/. The proposed patch adds a pass through the new path that removes duplicates while maintaining the ordering. Unfortunately it is difficult for me to provide a real test case for this as it arises out of trying to run the translate code with PyPy. However, I hope that the change is obviously fixing a bug that I've made clear exists. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685563&group_id=5470 From noreply at sourceforge.net Wed Mar 21 23:34:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 15:34:39 -0700 Subject: [Patches] [ python-Patches-1681002 ] binary and new-style octal literals Message-ID: Patches item #1681002, was opened at 2007-03-14 16:55 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681002&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Thomas Wouters (twouters) Assigned to: Guido van Rossum (gvanrossum) Summary: binary and new-style octal literals Initial Comment: Incomplete patch that adds '0t777' and '0b101010' style literals. It lacks a NEWS item, documentation and compiler-package changes (although it may not need any.) 2to3 recipe also not included. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-21 18:34 Message: Logged In: YES user_id=1344176 Originator: NO Georg has worked up a 2to3 fixer that implements the 0777 -> 0o777 and assorted other numeric literal fix-ups, called fix_numliterals. 2to3 will support 0b101010 literals just as soon as I type up a commit message. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-14 17:06 Message: Logged In: YES user_id=34209 Originator: YES The compiler package does indeed not need any changes, as it still uses Python's own tokenizer. And in case there's any doubt, I'm still -1 on this change :) (But unfortunately the easy implementation of it didn't exactly give me new ammo.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1681002&group_id=5470 From noreply at sourceforge.net Thu Mar 22 01:25:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 21 Mar 2007 17:25:24 -0700 Subject: [Patches] [ python-Patches-1685642 ] Add IllegalStateError Message-ID: Patches item #1685642, was opened at 2007-03-22 01: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=1685642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add IllegalStateError Initial Comment: Java has an exception called IllegalStateException. It is very useful for signaling "what you did would have been OK, but right now I can't do it." Python does not have a counterpart, but I think it should. For example, if you have a Python RDBMS-binding and you call db.select() before calling db.connect() it could raise a IllegalStateError (or maybe a subclass of it) that says 'IllegalStateError: "Must be connected to perform queries"'. Or for another example, take the Thread.start() function. Currently, if you call myThread.start() twice it will raise an AssertionError. That's no good because the result is undefined if you run python with -O. See Bug #904498 and Patch #1676820 (Martin v. L??wis comment). IllegalStateError should fit perfectly here: >>> t = threading.Thread() >>> t.start() >>> t.start() Traceback (most recent call last): ... IllegalStateError: thread already started ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685642&group_id=5470 From noreply at sourceforge.net Thu Mar 22 13:47:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 05:47:46 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 16:34 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 08:47 Message: Logged In: YES user_id=764593 Originator: NO Not sure if any of these are really problems, and it looks like Tony already looked them over before submitting, but still worth mentioning... (1) This does more than take out tuples, though the other changes do also look like things that ought to change for py3k. (2) I was amused by the name "stuff", but I couldn't think of a better name for that particular grouping. (suffix, mode, type) (3) There are some signature changes, where the unpacking is now done by the caller, such as class LeftShift(Node): - def __init__(self, (left, right), lineno=None): + def __init__(self, left, right, lineno=None): (4) The pdb change marks could be shortened a bit. That shouldn't matter for patching, but I'll post it here since it helped me. - def user_exception(self, frame, (exc_type, exc_value, exc_traceback)): + def user_exception(self, frame, exc_info): """This function is called if an exception occurs, but only if we are to stop at or just below this level.""" + (exc_type, exc_value, exc_traceback) = exc_info frame.f_locals['__exception__'] = exc_type, exc_value - if type(exc_type) == type(''): - exc_type_name = exc_type - else: exc_type_name = exc_type.__name__ + exc_type_name = exc_type.__name__ print(exc_type_name + ':', _saferepr(exc_value), file=self.stdout) self.interaction(frame, exc_traceback) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 11:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 18:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Thu Mar 22 13:57:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 05:57:20 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 16:34 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 08:57 Message: Logged In: YES user_id=764593 Originator: NO On the reprs, is there a reason to call repr instead of using %r? For example, the Floordiv repr changed to: "FloorDiv(%s, %s)" % (repr(self.left), repr(self.right)) Why not "FloorDiv(%r, %r)" % (self.left, self.right) or even, (assuming PEP 3101 with locals,) "FloorDiv({self.left:r}, {self.right:r})".format() ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 08:47 Message: Logged In: YES user_id=764593 Originator: NO Not sure if any of these are really problems, and it looks like Tony already looked them over before submitting, but still worth mentioning... (1) This does more than take out tuples, though the other changes do also look like things that ought to change for py3k. (2) I was amused by the name "stuff", but I couldn't think of a better name for that particular grouping. (suffix, mode, type) (3) There are some signature changes, where the unpacking is now done by the caller, such as class LeftShift(Node): - def __init__(self, (left, right), lineno=None): + def __init__(self, left, right, lineno=None): (4) The pdb change marks could be shortened a bit. That shouldn't matter for patching, but I'll post it here since it helped me. - def user_exception(self, frame, (exc_type, exc_value, exc_traceback)): + def user_exception(self, frame, exc_info): """This function is called if an exception occurs, but only if we are to stop at or just below this level.""" + (exc_type, exc_value, exc_traceback) = exc_info frame.f_locals['__exception__'] = exc_type, exc_value - if type(exc_type) == type(''): - exc_type_name = exc_type - else: exc_type_name = exc_type.__name__ + exc_type_name = exc_type.__name__ print(exc_type_name + ':', _saferepr(exc_value), file=self.stdout) self.interaction(frame, exc_traceback) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 11:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 18:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Thu Mar 22 14:47:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 06:47:53 -0700 Subject: [Patches] [ python-Patches-1685986 ] Method cache Message-ID: Patches item #1685986, was opened at 2007-03-22 13:47 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=1685986&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Method cache Initial Comment: This is a port of PyPy's method cache optimization. It gives a very good speed-up to PyPy, and it is simple enough to be attempted on CPython. The patch is against Python 2.4, which is the version I still use; I've applied the patch on the system-wide Pythons of a couple of machines a few days ago and haven't had any problem since. It gives a consistent 20+% of speed-up on all applications and benchmarks I tried, and up to 36% in extreme OO examples like the "richards" benchmark. The patch needs to be ported to the HEAD, and it needs some extra careful review. I'm a bit too busy right now to do any of these but I'll eventually come back to it if nobody else does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685986&group_id=5470 From noreply at sourceforge.net Thu Mar 22 16:28:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 08:28:43 -0700 Subject: [Patches] [ python-Patches-1685986 ] Method cache Message-ID: Patches item #1685986, was opened at 2007-03-22 13:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685986&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Armin Rigo (arigo) >Assigned to: Raymond Hettinger (rhettinger) Summary: Method cache Initial Comment: This is a port of PyPy's method cache optimization. It gives a very good speed-up to PyPy, and it is simple enough to be attempted on CPython. The patch is against Python 2.4, which is the version I still use; I've applied the patch on the system-wide Pythons of a couple of machines a few days ago and haven't had any problem since. It gives a consistent 20+% of speed-up on all applications and benchmarks I tried, and up to 36% in extreme OO examples like the "richards" benchmark. The patch needs to be ported to the HEAD, and it needs some extra careful review. I'm a bit too busy right now to do any of these but I'll eventually come back to it if nobody else does. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-22 15:28 Message: Logged In: YES user_id=849994 Originator: NO Perhaps Raymond, as one of the optimization specialists, can have a look in the meantime? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685986&group_id=5470 From noreply at sourceforge.net Thu Mar 22 19:18:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 11:18:25 -0700 Subject: [Patches] [ python-Patches-1686273 ] More PEP 3116 classes Message-ID: Patches item #1686273, was opened at 2007-03-22 18:18 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=1686273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: More PEP 3116 classes Initial Comment: More PEP 3116 implementation: - docstrings for RawIOBase methods - Simple implementations of StringIO, TextIOBase and TextIOWrapper - Simplify while condition in BufferedReader.read() - Add unit tests for StringIO (modified copy of the ByteIO tests) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686273&group_id=5470 From noreply at sourceforge.net Thu Mar 22 20:57:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 12:57:18 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 13:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-22 12:57 Message: Logged In: YES user_id=357491 Originator: NO Chances are I will take Tony's patch for its removal of the feature and use 2to3 to handle the conversion as much as possible. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 05:57 Message: Logged In: YES user_id=764593 Originator: NO On the reprs, is there a reason to call repr instead of using %r? For example, the Floordiv repr changed to: "FloorDiv(%s, %s)" % (repr(self.left), repr(self.right)) Why not "FloorDiv(%r, %r)" % (self.left, self.right) or even, (assuming PEP 3101 with locals,) "FloorDiv({self.left:r}, {self.right:r})".format() ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 05:47 Message: Logged In: YES user_id=764593 Originator: NO Not sure if any of these are really problems, and it looks like Tony already looked them over before submitting, but still worth mentioning... (1) This does more than take out tuples, though the other changes do also look like things that ought to change for py3k. (2) I was amused by the name "stuff", but I couldn't think of a better name for that particular grouping. (suffix, mode, type) (3) There are some signature changes, where the unpacking is now done by the caller, such as class LeftShift(Node): - def __init__(self, (left, right), lineno=None): + def __init__(self, left, right, lineno=None): (4) The pdb change marks could be shortened a bit. That shouldn't matter for patching, but I'll post it here since it helped me. - def user_exception(self, frame, (exc_type, exc_value, exc_traceback)): + def user_exception(self, frame, exc_info): """This function is called if an exception occurs, but only if we are to stop at or just below this level.""" + (exc_type, exc_value, exc_traceback) = exc_info frame.f_locals['__exception__'] = exc_type, exc_value - if type(exc_type) == type(''): - exc_type_name = exc_type - else: exc_type_name = exc_type.__name__ + exc_type_name = exc_type.__name__ print(exc_type_name + ':', _saferepr(exc_value), file=self.stdout) self.interaction(frame, exc_traceback) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 08:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 15:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Thu Mar 22 22:53:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 14:53:11 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 21:34 Message generated for change (Comment added) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- >Comment By: Tony Lownds (tonylownds) Date: 2007-03-22 21:53 Message: Logged In: YES user_id=24100 Originator: YES Thanks for the comments. Re: "stuff", if you look at other parts of the code, that is how the triple is referred to -- fyi on how the name "stuff" came to be :) I was also at a loss for a better name, and went with the contextual references. Re: using 2to3 -- Brett, in many cases I actually tried to come up with a consistent name. IIRC 2to3 will put in XXX_fixme_123 or something like that. Or it did when I last tried. Anyway, if you end up using 2to3, I would really appreciate it if you also picked up the inspect.py docstring change. Re: signature changes (eg LeftShift) and repr (FloorDiv) -- that is generated code, and that is why "repr" is used. I chose to change the generation source rather than the generation machinery as I was changing the source anyway, to account for the changes to parameter syntax. That is why there are API changes. Given that other API changes were made and those class constructors are more or less an internal API (created through compiler.parse), I believe this is the best way of dealing with the changes. Brett, If you need me to remove the 2to3 doc toolchain patches, I can do that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-22 19:57 Message: Logged In: YES user_id=357491 Originator: NO Chances are I will take Tony's patch for its removal of the feature and use 2to3 to handle the conversion as much as possible. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 12:57 Message: Logged In: YES user_id=764593 Originator: NO On the reprs, is there a reason to call repr instead of using %r? For example, the Floordiv repr changed to: "FloorDiv(%s, %s)" % (repr(self.left), repr(self.right)) Why not "FloorDiv(%r, %r)" % (self.left, self.right) or even, (assuming PEP 3101 with locals,) "FloorDiv({self.left:r}, {self.right:r})".format() ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 12:47 Message: Logged In: YES user_id=764593 Originator: NO Not sure if any of these are really problems, and it looks like Tony already looked them over before submitting, but still worth mentioning... (1) This does more than take out tuples, though the other changes do also look like things that ought to change for py3k. (2) I was amused by the name "stuff", but I couldn't think of a better name for that particular grouping. (suffix, mode, type) (3) There are some signature changes, where the unpacking is now done by the caller, such as class LeftShift(Node): - def __init__(self, (left, right), lineno=None): + def __init__(self, left, right, lineno=None): (4) The pdb change marks could be shortened a bit. That shouldn't matter for patching, but I'll post it here since it helped me. - def user_exception(self, frame, (exc_type, exc_value, exc_traceback)): + def user_exception(self, frame, exc_info): """This function is called if an exception occurs, but only if we are to stop at or just below this level.""" + (exc_type, exc_value, exc_traceback) = exc_info frame.f_locals['__exception__'] = exc_type, exc_value - if type(exc_type) == type(''): - exc_type_name = exc_type - else: exc_type_name = exc_type.__name__ + exc_type_name = exc_type.__name__ print(exc_type_name + ':', _saferepr(exc_value), file=self.stdout) self.interaction(frame, exc_traceback) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 15:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 22:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Fri Mar 23 00:59:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 16:59:46 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 13:34 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2007-03-22 16:59 Message: Logged In: YES user_id=357491 Originator: NO The reason I mention using 2to3 is Collin has done a bunch of work on it in order to make it also work with lambda. I believe he also cleaned up the generated names. And as for cleaning up the patches, Tony, I can easily edit the diff file manually, but thanks for the offer. But if I need you to I will let you know. ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-22 14:53 Message: Logged In: YES user_id=24100 Originator: YES Thanks for the comments. Re: "stuff", if you look at other parts of the code, that is how the triple is referred to -- fyi on how the name "stuff" came to be :) I was also at a loss for a better name, and went with the contextual references. Re: using 2to3 -- Brett, in many cases I actually tried to come up with a consistent name. IIRC 2to3 will put in XXX_fixme_123 or something like that. Or it did when I last tried. Anyway, if you end up using 2to3, I would really appreciate it if you also picked up the inspect.py docstring change. Re: signature changes (eg LeftShift) and repr (FloorDiv) -- that is generated code, and that is why "repr" is used. I chose to change the generation source rather than the generation machinery as I was changing the source anyway, to account for the changes to parameter syntax. That is why there are API changes. Given that other API changes were made and those class constructors are more or less an internal API (created through compiler.parse), I believe this is the best way of dealing with the changes. Brett, If you need me to remove the 2to3 doc toolchain patches, I can do that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-22 12:57 Message: Logged In: YES user_id=357491 Originator: NO Chances are I will take Tony's patch for its removal of the feature and use 2to3 to handle the conversion as much as possible. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 05:57 Message: Logged In: YES user_id=764593 Originator: NO On the reprs, is there a reason to call repr instead of using %r? For example, the Floordiv repr changed to: "FloorDiv(%s, %s)" % (repr(self.left), repr(self.right)) Why not "FloorDiv(%r, %r)" % (self.left, self.right) or even, (assuming PEP 3101 with locals,) "FloorDiv({self.left:r}, {self.right:r})".format() ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 05:47 Message: Logged In: YES user_id=764593 Originator: NO Not sure if any of these are really problems, and it looks like Tony already looked them over before submitting, but still worth mentioning... (1) This does more than take out tuples, though the other changes do also look like things that ought to change for py3k. (2) I was amused by the name "stuff", but I couldn't think of a better name for that particular grouping. (suffix, mode, type) (3) There are some signature changes, where the unpacking is now done by the caller, such as class LeftShift(Node): - def __init__(self, (left, right), lineno=None): + def __init__(self, left, right, lineno=None): (4) The pdb change marks could be shortened a bit. That shouldn't matter for patching, but I'll post it here since it helped me. - def user_exception(self, frame, (exc_type, exc_value, exc_traceback)): + def user_exception(self, frame, exc_info): """This function is called if an exception occurs, but only if we are to stop at or just below this level.""" + (exc_type, exc_value, exc_traceback) = exc_info frame.f_locals['__exception__'] = exc_type, exc_value - if type(exc_type) == type(''): - exc_type_name = exc_type - else: exc_type_name = exc_type.__name__ + exc_type_name = exc_type.__name__ print(exc_type_name + ':', _saferepr(exc_value), file=self.stdout) self.interaction(frame, exc_traceback) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 08:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 15:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Fri Mar 23 01:21:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 17:21:32 -0700 Subject: [Patches] [ python-Patches-1667546 ] Time zone-capable variant of time.localtime Message-ID: Patches item #1667546, was opened at 2007-02-24 00:25 Message generated for change (Comment added) made by pboddie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Boddie (pboddie) Assigned to: Georg Brandl (gbrandl) Summary: Time zone-capable variant of time.localtime Initial Comment: Patch related to #1493676: "time.strftime() %z error" This provides a localtime_tz function whose return value is the usual localtime time tuple with an additional field reflecting the underlying tm_gmtoff data. Various internal function signatures are modified to support the flow of time zone information, with the gettmarg most noticably changed (probably quite inelegantly - I don't do Python core development). This patch is against the Python 2.4.4 release sources. ---------------------------------------------------------------------- >Comment By: Paul Boddie (pboddie) Date: 2007-03-23 01:21 Message: Logged In: YES user_id=226443 Originator: YES I've enhanced your version of the patch to work with the following defines: #define HAVE_TZNAME 1 #undef HAVE_TM_ZONE #undef HAVE_STRUCT_TM_TM_ZONE #undef HAVE_ALTZONE It now uses struct_time in such an environment to provide the extra offset information used in the unixtime function rather than accessing tm_gmtoff. I suppose one could do that for all cases, in fact, since this is done independently of any mktime invocation. The above defines probably represent the next most "sane" of environments after those which have tm_gmtoff. If one starts to remove other things, other more established tests seem to fail, too. File Added: time-1-improved.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 11:25 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a patch with some corrections of mine. It looks very good now. However, your tests fail if HAVE_STRUCT_TM_TM_ZONE is not defined. Can that be repaired? If not, the tests must be skipped in this case. File Added: time-1.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:20 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_mktimetz_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-20 01:19 Message: Logged In: YES user_id=226443 Originator: YES Yet another round. Fixed timegm, hopefully. Added mktimetz which uses time zone information to convert local and UMT times to UNIX times. Added tests and updated the docs. The usual caveats apply: I'm new to all this, so some things may need sanity checking. File Added: tm_gmtoff_zone_timegm_mktimetz.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-14 23:43 Message: Logged In: YES user_id=226443 Originator: YES Looking at this a bit more, it seems like timegm (which is a pretty desirable function to have) really is as simple as the calendar.timegm function, as far as I can tell: it just throws time zone information away. So the timegm implementation in the patches so far is actually wrong (and broken in the way it attempts to use tm_gmtoff, anyway). However, it might be nice to have a function which actually interprets times properly in order to produce a UNIX time. In other words, something which returns zero for both time.localtime(0) and time.gmtime(0), along with other times which happen to refer to the epoch but in other time zones. I'll upload a fixed patch in the next day or so, hopefully. Sorry for the noise! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-12 15:13 Message: Logged In: YES user_id=849994 Originator: NO The patch looks good so far -- but I'd be comfortable with a few more tests, for example for strptime and strftime. Also, the documentation must be updated for every user-visible change (the addition of timegm(), the additional timetuple fields, the now-working (?) %z and %Z in str[fp]time and behavior changes). ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 22:02 Message: Logged In: YES user_id=226443 Originator: YES SourceForge "replay" added new attachment - now deleted. ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 21:15 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_timegm_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-11 18:00 Message: Logged In: YES user_id=226443 Originator: YES New patches against 2.4.4 and the trunk, providing tm_gmtoff, tm_zone, strptime enhancements, a timegm function, plus tests. Where a platform supports the timezone and altzone module attributes but not tm_gmtoff and tm_zone struct tm fields, the code attempts to populate the struct_time fields appropriately, setting None values only if no timezone information exists whatsoever. Limitations include the inability to parse/obtain timezone information beyond that provided by system calls, which is an existing limitation that affects the strptime implementation amongst other things. Again, testing for "deficient" platforms with limited struct tm definitions has been limited. File Added: tm_gmtoff_zone_timegm.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-10 23:59 Message: Logged In: YES user_id=226443 Originator: YES After some thought, perhaps the population of timezone fields is more difficult than described below. Will need to look at other parts of the module code to see what the complications are. What a headache! ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES File Added: tm_gmtoff_zone_26.diff ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-09 00:57 Message: Logged In: YES user_id=226443 Originator: YES Attached are two patches (for 2.4.4 and against the trunk). Apart from the addition of tm_zone, there's one big change: if no timezone fields/members exist on struct tm, the code attempts to read that data from the module's timezone and tzname attributes in order to populate tm_gmtoff and tm_zone; if that fails then both tm_gmtoff and tm_zone are set to None. The logic for all this is tested in test_time.py, but it really needs checking for suitability and testing on something like HP-UX. Details for the logic here: http://devrsrc1.external.hp.com/STKT/impacts/i117.html File Added: tm_gmtoff_zone.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-08 01:52 Message: Logged In: YES user_id=6380 Originator: NO No immediate time for review, but this sounds encouraging. Would you mind adding tm_zone (a string) as well? And how about working relative to the 2.6 trunk (since that's the earliest version where this new feature can be introduced)? ---------------------------------------------------------------------- Comment By: Paul Boddie (pboddie) Date: 2007-03-08 01:28 Message: Logged In: YES user_id=226443 Originator: YES One learns new things about time and stat tuples every day! Made a much cleaner patch which provides an extra named attribute (tm_gmtoff) whilst preserving the 9-tuple layout. Where no time zone support exists, tm_gmtoff is None; otherwise it's the GMT/UTC offset. I had weird test issues with range(7) giving "TypeError: an integer is required" in the code employed (deep down) in test_strptime at some point during development, probably due to memory issues, so it might be worth checking that I've dealt properly with such things. File Added: tm_gmtoff.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-02 16:52 Message: Logged In: YES user_id=6380 Originator: NO Without even looking at the patch, IMO it would be much better to add tm_gmtoff and tm_zone (and any other fields) to the record returned by localtime(), but in such a way that when accessed as a tuple it still has only 9 fields. There is infrastructure for doing so somewhere for the stat structure that I'm sure could be borrowed or generalized (if it isn't already general). That's much better than adding a new function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1667546&group_id=5470 From noreply at sourceforge.net Fri Mar 23 01:30:52 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 17:30:52 -0700 Subject: [Patches] [ python-Patches-1686451 ] int to Py_ssize_t changes Message-ID: Patches item #1686451, was opened at 2007-03-22 20: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=1686451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: int to Py_ssize_t changes Initial Comment: Two functions and a macro that return Py_ssize_t are still documented as returning an int. Updated PySequence_Count, PySequence_Index and PySequence_Fast_GET_SIZE return type. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686451&group_id=5470 From noreply at sourceforge.net Fri Mar 23 03:38:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 19:38:01 -0700 Subject: [Patches] [ python-Patches-1665292 ] Datetime enhancements Message-ID: Patches item #1665292, was opened at 2007-02-21 15:55 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Datetime enhancements Initial Comment: I'm proposing some small enhancements to the datetime module: Add a totimestamp() method to datetime.datetime that returns the seconds since 1/1/1970 00:00:00. The datetime class has already a fromtimestamp() factory but is missing a totimestamp() method. Add a __int__() and __float__() method to datetime.timedelta which return the seconds (seconds + 86400 * days) as int and seconds + miliseconds as float. It would save some typing if somebody needs an integer representation of a timedelta object :] The datetime module is implemented in C. I've never written a Python C extension so I can't help with a patch. Thx ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-03-23 03:38 Message: Logged In: YES user_id=560817 Originator: YES Here is a new patch. I've updated the documentation and enhanced the compare function to compare with ints, longs and floats. This part of the patch should be complete. I'm going to submit a different patch for the other features later. Shall I start a new tracker entry? File Added: timedelta_intfloat.diff ---------------------------------------------------------------------- Comment By: Johann C. Rocholl (jcrocholl) Date: 2007-03-09 17:33 Message: Logged In: YES user_id=656137 Originator: NO The patch confuses microseconds with milliseconds. The divisor in delta_float should be 1000000.0, not 1000.0. The result of the last test should be 86401.000001, not 86401.001. ---------------------------------------------------------------------- Comment By: Christian Heimes (tiran) Date: 2007-02-21 17:16 Message: Logged In: YES user_id=560817 Originator: YES File Added: timedelta.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1665292&group_id=5470 From noreply at sourceforge.net Fri Mar 23 04:27:51 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 22 Mar 2007 20:27:51 -0700 Subject: [Patches] [ python-Patches-1686487 ] Allow any mapping after ** in calls Message-ID: Patches item #1686487, was opened at 2007-03-22 23: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=1686487&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any mapping after ** in calls Initial Comment: Python allows arbitrary sequences after * in calls, but an expression following ** must be a (subclass of) dict. The attached patch makes Python accept arbitrary mappings after **. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470 From noreply at sourceforge.net Fri Mar 23 11:36:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 03:36:32 -0700 Subject: [Patches] [ python-Patches-1686451 ] int to Py_ssize_t changes Message-ID: Patches item #1686451, was opened at 2007-03-23 01:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686451&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: int to Py_ssize_t changes Initial Comment: Two functions and a macro that return Py_ssize_t are still documented as returning an int. Updated PySequence_Count, PySequence_Index and PySequence_Fast_GET_SIZE return type. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 11:36 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the patch. Committed as r54541 and r54542 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686451&group_id=5470 From noreply at sourceforge.net Fri Mar 23 12:07:31 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 04:07:31 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 20:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 12:07 Message: Logged In: YES user_id=21627 Originator: NO The patch works fine, please apply. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 19:02 Message: Logged In: YES user_id=1344176 Originator: NO Since the trouble is os.getcwd() returns a non-posix path on Windows, I've taken the approach of mocking os.getcwd() so that it returns something posix-y. Martin, could you verify that the attached patch works on Windows? File Added: test_posixpath.py.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-21 17:12 Message: Logged In: YES user_id=21627 Originator: NO The test fails on Windows. In particular, this test: self.assertEqual(posixpath.relpath(os.path.abspath("a")), "a") fails. os.path.abspath("a") gives something like r"c:\python26\a". posixpath.relpath is then not able to cope with it. As a result, it returns r"c:\python26\a" as the relative path. Using posixpath.abspath doesn't help, either, since that will give r"c:\python26/a" which relpath then still cannot process correctly. One solution would be to use pass a POSIX path and start path to relpath; the other would be to use os.path in both cases. os.path.relpath(os.path.abspath("a")) does indeed give "a" on Windows. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 23:16 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54419. Thanks for the patch, Richard! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:24 Message: Logged In: YES user_id=849994 Originator: NO Since there is an "Availability" remark, I wouldn't be concerned. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 04:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 22:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 15:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 19:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 12:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 18:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 13:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 08:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Fri Mar 23 14:45:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 06:45:11 -0700 Subject: [Patches] [ python-Patches-1479255 ] Fix building with SWIG's -c++ option set in setup.py Message-ID: Patches item #1479255, was opened at 2006-04-30 10:24 Message generated for change (Comment added) made by fremen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: dOb (d0b) Assigned to: Nobody/Anonymous (nobody) Summary: Fix building with SWIG's -c++ option set in setup.py Initial Comment: When the '--swig-opts -c++' command line option is used, the target extension is changed from .c to .cpp but when the '-c++' option is passed to an Extension with the swig_opts keyword argument, the target extension is not changed. This causes the compiler to treat the C++ source as C and fail. With the patch distutils uses the Extension's swig_opts argument in addition to the command line options to determine if the target extension should be .c or .cpp. Here are examples of what arguments get used with the executables in different situations: Without -c++ swig.exe -python -Iinclude -o interface/interface_wrap.c interface/interface.i cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude -IC:\Python24\include -IC:\Python24\PC /Tcinterface/interface_wrap.c /Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj With -c++ (as command line option) swig.exe -python -Iinclude -c++ -o interface/interface_wrap.cpp interface/interface.i cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude -IC:\Python24\include -IC:\Python24\PC /Tpinterface/interface_wrap.cpp /Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj With -c++ (in swig_opts in setup.py) swig.exe -python -Iinclude -c++ -o interface/interface_wrap.c interface/interface.i cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude -IC:\Python24\include -IC:\Python24\PC /Tcinterface/interface_wrap.c /Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj With -c++ (in swig_opts in setup.py with patch applied) swig.exe -python -Iinclude -c++ -o interface/interface_wrap.cpp interface/interface.i cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -Iinclude -IC:\Python24\include -IC:\Python24\PC /Tpinterface/interface_wrap.cpp /Fobuild\temp.win32-2.4\Release\interface/interface_wrap.obj ---------------------------------------------------------------------- Comment By: Mark Howson (fremen) Date: 2007-03-23 13:45 Message: Logged In: YES user_id=35093 Originator: NO Problem still exists as of 23/03/07 in Python 2.5, patch appears to be correct solution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479255&group_id=5470 From noreply at sourceforge.net Fri Mar 23 16:31:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 08:31:14 -0700 Subject: [Patches] [ python-Patches-1273829 ] extending os.walk to support following symlinks Message-ID: Patches item #1273829, was opened at 2005-08-26 09:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1273829&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Erick Tryzelaar (idadesub) Assigned to: Nobody/Anonymous (nobody) Summary: extending os.walk to support following symlinks Initial Comment: this is a very simple extension to os.walk to optionally walk down into symlink directories, when it is supported by the operating system. This patch keeps a compatible interface by having this option disabled. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 16:31 Message: Logged In: YES user_id=21627 Originator: NO The test suite patch (54482) broke the windows build. The assertion self.assertEqual(len(all), 4) fails because it finds 5 directories (link is a directory), then the rest of the code is not executed. In turn, the tear-down code is not run, leaving the directories behind. This causes subsequent tests to fail. When fixing the code, I recommend to move the tear-down code into the tearDown method of the test, to make sure it is always run. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:22 Message: Logged In: YES user_id=849994 Originator: NO Added docs and tests and committed in rev. 54407. ---------------------------------------------------------------------- Comment By: Stephen Hansen (aptshansen) Date: 2007-03-16 08:34 Message: Logged In: YES user_id=1720594 Originator: NO I'm not sure if this is a good idea; although I am certain it would be useful at times. Dangerous! But if its documented, ... and there's our problem :) Patch applies cleanly to the HEAD, but needs documentation. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-26 10:23 Message: Logged In: YES user_id=1188172 The docs to os.walk say: """ Note: On systems that support symbolic links, links to subdirectories appear in dirnames lists, but walk() will not visit them (infinite loops are hard to avoid when following symbolic links). To visit linked directories, you can identify them with os.path.islink(path), and invoke walk(path) on each directly. """ Nevertheless, we could offer this option with a caution message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1273829&group_id=5470 From noreply at sourceforge.net Fri Mar 23 17:30:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 09:30:54 -0700 Subject: [Patches] [ python-Patches-1678060 ] Removal of Tuple Parameter Unpacking [PEP3113] Message-ID: Patches item #1678060, was opened at 2007-03-10 16:34 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Brett Cannon (bcannon) Summary: Removal of Tuple Parameter Unpacking [PEP3113] Initial Comment: Remove tuple parameter unpacking. The Grammar is now: typedargslist: ((tfpdef ['=' test] ',')* ('*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | tfpdef ['=' test] (',' tfpdef ['=' test])* [',']) tfpdef: NAME [':' test] varargslist: ((vfpdef ['=' test] ',')* ('*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef) | vfpdef ['=' test] (',' vfpdef ['=' test])* [',']) vfpdef: NAME Tuple parameters are removed from Lib/. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-23 12:30 Message: Logged In: YES user_id=764593 Originator: NO Brett, 2to3 is an important tool, but probably won't ever match good hand-work. (1) There are several places where he improved the code. replacing map + an unpacking nested function with a generator: """ def classify_class_attrs(object): """Wrap inspect.classify_class_attrs, with fixup for data descriptors.""" - def fixup((name, kind, cls, value)): + for (name, kind, cls, value) in inspect.classify_class_attrs(object): if inspect.isdatadescriptor(value): kind = 'data descriptor' - return name, kind, cls, value - return map(fixup, inspect.classify_class_attrs(object)) + yield name, kind, cls, value """ Replacing a paren-laden lambda with named function: """ - items = sorted(items, key=lambda (k, v): (str(type(k)), k, v)) + def sortkey(item): + key, value = item + return str(type(key)), key, value + items = sorted(items, key=sortkey) """ Replacing filter + lambda + unpack with list comprehension: """ - attrs = filter(lambda (name, kind, cls, value): visiblename(name), - classify_class_attrs(object)) + attrs = [(name, kind, cls, value) + for name, kind, cls, value in classify_class_attrs(object) + if visiblename(name)] """ (2) His names are better. I prefer his (name, result, expected)) over the current (name, (v1,v2), (e1,e2))), let alone (name, _v1_v2_, _e1_e2_)) Even looking just at code with good existing names, he uses components instead of _scheme_netloc_url_query_fragment_ So we get (what looks like human-readable source) -def urlunsplit((scheme, netloc, url, query, fragment)): +def urlunsplit(components): + (scheme, netloc, url, query, fragment) = components instead of (what looks like the output of a computer translation step) +def urlunsplit(_scheme_netloc_url_query_fragment_): + (scheme, netloc, url, query, fragment) = _scheme_netloc_url_query_fragment_ ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-22 19:59 Message: Logged In: YES user_id=357491 Originator: NO The reason I mention using 2to3 is Collin has done a bunch of work on it in order to make it also work with lambda. I believe he also cleaned up the generated names. And as for cleaning up the patches, Tony, I can easily edit the diff file manually, but thanks for the offer. But if I need you to I will let you know. ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-22 17:53 Message: Logged In: YES user_id=24100 Originator: YES Thanks for the comments. Re: "stuff", if you look at other parts of the code, that is how the triple is referred to -- fyi on how the name "stuff" came to be :) I was also at a loss for a better name, and went with the contextual references. Re: using 2to3 -- Brett, in many cases I actually tried to come up with a consistent name. IIRC 2to3 will put in XXX_fixme_123 or something like that. Or it did when I last tried. Anyway, if you end up using 2to3, I would really appreciate it if you also picked up the inspect.py docstring change. Re: signature changes (eg LeftShift) and repr (FloorDiv) -- that is generated code, and that is why "repr" is used. I chose to change the generation source rather than the generation machinery as I was changing the source anyway, to account for the changes to parameter syntax. That is why there are API changes. Given that other API changes were made and those class constructors are more or less an internal API (created through compiler.parse), I believe this is the best way of dealing with the changes. Brett, If you need me to remove the 2to3 doc toolchain patches, I can do that. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-03-22 15:57 Message: Logged In: YES user_id=357491 Originator: NO Chances are I will take Tony's patch for its removal of the feature and use 2to3 to handle the conversion as much as possible. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 08:57 Message: Logged In: YES user_id=764593 Originator: NO On the reprs, is there a reason to call repr instead of using %r? For example, the Floordiv repr changed to: "FloorDiv(%s, %s)" % (repr(self.left), repr(self.right)) Why not "FloorDiv(%r, %r)" % (self.left, self.right) or even, (assuming PEP 3101 with locals,) "FloorDiv({self.left:r}, {self.right:r})".format() ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-03-22 08:47 Message: Logged In: YES user_id=764593 Originator: NO Not sure if any of these are really problems, and it looks like Tony already looked them over before submitting, but still worth mentioning... (1) This does more than take out tuples, though the other changes do also look like things that ought to change for py3k. (2) I was amused by the name "stuff", but I couldn't think of a better name for that particular grouping. (suffix, mode, type) (3) There are some signature changes, where the unpacking is now done by the caller, such as class LeftShift(Node): - def __init__(self, (left, right), lineno=None): + def __init__(self, left, right, lineno=None): (4) The pdb change marks could be shortened a bit. That shouldn't matter for patching, but I'll post it here since it helped me. - def user_exception(self, frame, (exc_type, exc_value, exc_traceback)): + def user_exception(self, frame, exc_info): """This function is called if an exception occurs, but only if we are to stop at or just below this level.""" + (exc_type, exc_value, exc_traceback) = exc_info frame.f_locals['__exception__'] = exc_type, exc_value - if type(exc_type) == type(''): - exc_type_name = exc_type - else: exc_type_name = exc_type.__name__ + exc_type_name = exc_type.__name__ print(exc_type_name + ':', _saferepr(exc_value), file=self.stdout) self.interaction(frame, exc_traceback) ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-12 11:07 Message: Logged In: YES user_id=24100 Originator: YES I found some more code to be removed + a docstring fix in inspect.py. getfullargspec's docstring lists the wrong order for return values. This patch combined the refmanual patch, previous simplified args patch, and 2to3 changes on some doc building tools. File Added: simplified-args.patch ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2007-03-11 18:34 Message: Logged In: YES user_id=24100 Originator: YES File Added: refmanual.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1678060&group_id=5470 From noreply at sourceforge.net Fri Mar 23 18:51:24 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 10:51:24 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 18:32 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-23 14:51 Message: Logged In: YES user_id=752496 Originator: YES The patch is updated, reflecting discussion in python-dev and last comment here. - Just put a timeout default to None. If None, skip settimeout() call. - Copy the exceptions behaviour that we have actually in the higher level libraries, to be sure we aren't breaking anything. - The function is now public, named "create_connection". Tests and docs are updated too. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 14:12 Message: Logged In: YES user_id=6380 Originator: NO I may have missed some of the discussion, but I don't understand why it is so important to differentiate between explicit timeout=None and omitting timeout altogether. I would favor a version where the timeout defaults to None, is a simple positional argument to _create_connection(), and the settimeout() call is skipped when timeout is None. I also favor making create_connection() public again since it may be useful for user code or 3rd party libraries that implements some protocol. After all the reality is probably that people have copied the exact loop that's found in httplib and 5 other places into their code anyway, if they care at all about IPv6 support. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 13:24 Message: Logged In: YES user_id=752496 Originator: YES I updated the patch, reflecting discussion on python-dev: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it update sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 15:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 15:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 13:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 18:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Fri Mar 23 19:00:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 11:00:32 -0700 Subject: [Patches] [ python-Patches-1577756 ] whitespace in `svnversion .` Message-ID: Patches item #1577756, was opened at 2006-10-15 19:33 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 2 Private: No Submitted By: Daniel Str?nger (schmaller) Assigned to: Georg Brandl (gbrandl) Summary: whitespace in `svnversion .` Initial Comment: gcc (version 3.4.4) fails to compile Modules/getbuildinfo.c, since it works as documented and cuts the definition of SVNVERSION at the first newline and so there is an unbalanced double quote. citation of the gcc manpage: -D name=definition Predefine name as a macro, with definition definition. The contents of definition are tokenized and processed as if they appeared during translation phase three in a #define directive. In particular, the definition will be truncated by embedded newline characters. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 18:00 Message: Logged In: YES user_id=849994 Originator: NO The fix wasn't in 2.5, but it will be in 2.5.1. ---------------------------------------------------------------------- Comment By: ascotan (ascotan) Date: 2007-03-21 15:36 Message: Logged In: YES user_id=1749372 Originator: NO This problem popped up in the python2.5 tarball that is publicly available through python.org when I was building on a 64-bit linux machine. The quotations are unbalanced still in the Makefile producing a compiler error. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-12-08 20:47 Message: Logged In: YES user_id=849994 Originator: NO German output shouldn't have happened. It turns out that LANG=C isn't the correct env var to force English output, now using LC_ALL=C in rev. 52970, 52971 (2.5). ---------------------------------------------------------------------- Comment By: Daniel Str?nger (schmaller) Date: 2006-12-07 23:59 Message: Logged In: YES user_id=922469 Originator: YES Now I've found the error (and the solution). The culprit is the german version of svnversion: it returns the string "exportiert ". Notice the trailing space character. This leads to the following expansion for #> gcc -DSVNVERSION=\"`svnversion -n .`\" ... gcc -DSVNVERSION=\"exportiert \" ... and so SVNVERSION gets the value: <"exportiert>. To solve this problem, the value of the macro SVNVERSION must again be enclosed by double-quotes, as you can see in the patch file. Best regards, Daniel File Added: svnversion_whitespace.patch ---------------------------------------------------------------------- Comment By: Daniel Str?nger (schmaller) Date: 2006-10-15 21:12 Message: Logged In: YES user_id=922469 The patch don't fix it and i think it's not a problem of Python. I apologize for spamming the patch system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1577756&group_id=5470 From noreply at sourceforge.net Fri Mar 23 19:21:46 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 11:21:46 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 16:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-23 14:21 Message: Logged In: YES user_id=6380 Originator: NO Can you check this in yourself? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-23 13:51 Message: Logged In: YES user_id=752496 Originator: YES The patch is updated, reflecting discussion in python-dev and last comment here. - Just put a timeout default to None. If None, skip settimeout() call. - Copy the exceptions behaviour that we have actually in the higher level libraries, to be sure we aren't breaking anything. - The function is now public, named "create_connection". Tests and docs are updated too. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 13:12 Message: Logged In: YES user_id=6380 Originator: NO I may have missed some of the discussion, but I don't understand why it is so important to differentiate between explicit timeout=None and omitting timeout altogether. I would favor a version where the timeout defaults to None, is a simple positional argument to _create_connection(), and the settimeout() call is skipped when timeout is None. I also favor making create_connection() public again since it may be useful for user code or 3rd party libraries that implements some protocol. After all the reality is probably that people have copied the exact loop that's found in httplib and 5 other places into their code anyway, if they care at all about IPv6 support. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 12:24 Message: Logged In: YES user_id=752496 Originator: YES I updated the patch, reflecting discussion on python-dev: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it update sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 14:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 14:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 12:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 17:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Fri Mar 23 19:33:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 11:33:18 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 21:32 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 18:33 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a reviewed version. Basically only nits and one added XXX comment about IPv6. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-23 18:21 Message: Logged In: YES user_id=6380 Originator: NO Can you check this in yourself? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-23 17:51 Message: Logged In: YES user_id=752496 Originator: YES The patch is updated, reflecting discussion in python-dev and last comment here. - Just put a timeout default to None. If None, skip settimeout() call. - Copy the exceptions behaviour that we have actually in the higher level libraries, to be sure we aren't breaking anything. - The function is now public, named "create_connection". Tests and docs are updated too. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 17:12 Message: Logged In: YES user_id=6380 Originator: NO I may have missed some of the discussion, but I don't understand why it is so important to differentiate between explicit timeout=None and omitting timeout altogether. I would favor a version where the timeout defaults to None, is a simple positional argument to _create_connection(), and the settimeout() call is skipped when timeout is None. I also favor making create_connection() public again since it may be useful for user code or 3rd party libraries that implements some protocol. After all the reality is probably that people have copied the exact loop that's found in httplib and 5 other places into their code anyway, if they care at all about IPv6 support. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 16:24 Message: Logged In: YES user_id=752496 Originator: YES I updated the patch, reflecting discussion on python-dev: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it update sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 18:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 18:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 16:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 21:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Fri Mar 23 19:41:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 11:41:25 -0700 Subject: [Patches] [ python-Patches-1685642 ] Add IllegalStateError Message-ID: Patches item #1685642, was opened at 2007-03-22 00:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add IllegalStateError Initial Comment: Java has an exception called IllegalStateException. It is very useful for signaling "what you did would have been OK, but right now I can't do it." Python does not have a counterpart, but I think it should. For example, if you have a Python RDBMS-binding and you call db.select() before calling db.connect() it could raise a IllegalStateError (or maybe a subclass of it) that says 'IllegalStateError: "Must be connected to perform queries"'. Or for another example, take the Thread.start() function. Currently, if you call myThread.start() twice it will raise an AssertionError. That's no good because the result is undefined if you run python with -O. See Bug #904498 and Patch #1676820 (Martin v. L??wis comment). IllegalStateError should fit perfectly here: >>> t = threading.Thread() >>> t.start() >>> t.start() Traceback (most recent call last): ... IllegalStateError: thread already started ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 18:41 Message: Logged In: YES user_id=849994 Originator: NO In principle this is a good idea -- currently there's no guideline what to raise in such a situation. Some libraries raise RuntimeError (probably a new exception should be made subclass thereof), some do assertions, some raise custom exceptions. However, for this to be a complete patch, you'd have to find all those places where IllegalStateError would be appropriate. Also, switching to it would be a Py3k thing, provided that this breakage is suffered by python-dev. In any case, I think you should bring it up on the python-3000 mailing list -- otherwise this will never be decided upon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685642&group_id=5470 From noreply at sourceforge.net Fri Mar 23 19:45:00 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 11:45:00 -0700 Subject: [Patches] [ python-Patches-1686487 ] Allow any mapping after ** in calls Message-ID: Patches item #1686487, was opened at 2007-03-23 03:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any mapping after ** in calls Initial Comment: Python allows arbitrary sequences after * in calls, but an expression following ** must be a (subclass of) dict. The attached patch makes Python accept arbitrary mappings after **. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 18:45 Message: Logged In: YES user_id=849994 Originator: NO Two flaws: - what if kwdict is NULL? Shouldn't happen, but the old version raises an error in this case. - if PyDict_Update fails, tmpdict is leaked. Please ask on python-dev whether to include this feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470 From noreply at sourceforge.net Fri Mar 23 20:33:21 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 12:33:21 -0700 Subject: [Patches] [ python-Patches-1676823 ] Adding timeout to socket.py and httplib.py Message-ID: Patches item #1676823, was opened at 2007-03-08 18:32 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Facundo Batista (facundobatista) Assigned to: Georg Brandl (gbrandl) Summary: Adding timeout to socket.py and httplib.py Initial Comment: This is a subset of patch #723312. Like it, adds a NetworkConnection object to socket.py, and then use it from other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). In this patch I only use this new NetworkConnection from httplib, whose HTTPConnection class now optionally accepts a timeout. Beyond the changes in socket.py and httplib.py, this patch also includes changes in the docs and new test cases. ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-23 16:33 Message: Logged In: YES user_id=752496 Originator: YES I already commited the previous version, :s. I'm closing this patch, feel free to reopen it if you want me to add the XXX comment. Regards, ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 15:33 Message: Logged In: YES user_id=849994 Originator: NO I'm attaching a reviewed version. Basically only nits and one added XXX comment about IPv6. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-23 15:21 Message: Logged In: YES user_id=6380 Originator: NO Can you check this in yourself? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-23 14:51 Message: Logged In: YES user_id=752496 Originator: YES The patch is updated, reflecting discussion in python-dev and last comment here. - Just put a timeout default to None. If None, skip settimeout() call. - Copy the exceptions behaviour that we have actually in the higher level libraries, to be sure we aren't breaking anything. - The function is now public, named "create_connection". Tests and docs are updated too. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-21 14:12 Message: Logged In: YES user_id=6380 Originator: NO I may have missed some of the discussion, but I don't understand why it is so important to differentiate between explicit timeout=None and omitting timeout altogether. I would favor a version where the timeout defaults to None, is a simple positional argument to _create_connection(), and the settimeout() call is skipped when timeout is None. I also favor making create_connection() public again since it may be useful for user code or 3rd party libraries that implements some protocol. After all the reality is probably that people have copied the exact loop that's found in httplib and 5 other places into their code anyway, if they care at all about IPv6 support. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-21 13:24 Message: Logged In: YES user_id=752496 Originator: YES I updated the patch, reflecting discussion on python-dev: - The function name changed, now it's _create_connection(). Its signature also changed: now, timeout is mandatorily named. - HTTPConnection has the posibility to call timeout with a number, and also with None. In both cases, it update sock.timeout (changing effectively the default timeout). Docs and tests cases are also updated (note: now there's no doc in libsocket.tex, as this function is now private). File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-15 15:53 Message: Logged In: YES user_id=6380 Originator: NO Georg, can you review this? ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-15 15:31 Message: Logged In: YES user_id=752496 Originator: YES I refactored the patch, now it uses function connect() in socket.py as specified in my last comment here. Of course, tests and docs are also updated in the patch. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2007-03-13 13:11 Message: Logged In: YES user_id=752496 Originator: YES In all the other libraries we can store the timeout, and then make a single call to socket.py. There's no "refactored connect_with_timeout" in socket.py. The functionality that will be present is one that is repeated several times in the higher level modules. So, there's no need of a "..._with_timeout" name. I'll work in a function, in socket.py, called "connect", with this functionality, and the following signature: def connect(address, timeout=None): # being address == (host, port) ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-12 18:36 Message: Logged In: YES user_id=6380 Originator: NO I like the idea of refactoring refactoring of the connect() loop, however, I wonder if a class isn't overkill. The constructor could just store the timeout parameter instead of the networkconnection object, and the connect() method could just call the refactored connect_with_timeout function passing it the host/port pair and the timeout. But perhaps there's a use case I have missed that appears in one of the classes you haven't patched yet but looked at? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676823&group_id=5470 From noreply at sourceforge.net Fri Mar 23 20:44:43 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 12:44:43 -0700 Subject: [Patches] [ python-Patches-1686487 ] Allow any mapping after ** in calls Message-ID: Patches item #1686487, was opened at 2007-03-22 23:27 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Allow any mapping after ** in calls Initial Comment: Python allows arbitrary sequences after * in calls, but an expression following ** must be a (subclass of) dict. The attached patch makes Python accept arbitrary mappings after **. ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-23 15:44 Message: Logged In: YES user_id=835142 Originator: YES I've fixed the flaws in star-star-mapping-1.patch . I will ask on python-dev about the feature. If the proposal is accepted, I will probably refactor the code to avoid using the second goto label. File Added: star-star-mapping-1.patch ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 14:45 Message: Logged In: YES user_id=849994 Originator: NO Two flaws: - what if kwdict is NULL? Shouldn't happen, but the old version raises an error in this case. - if PyDict_Update fails, tmpdict is leaked. Please ask on python-dev whether to include this feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686487&group_id=5470 From noreply at sourceforge.net Fri Mar 23 23:26:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 15:26:55 -0700 Subject: [Patches] [ python-Patches-1339796 ] new function: os.path.relpath Message-ID: Patches item #1339796, was opened at 2005-10-27 14:23 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Richard Barran (rbarran) Assigned to: Collin Winter (collinwinter) Summary: new function: os.path.relpath Initial Comment: Hello, This patch adds a 'relpath' function to module os.path as per RFE #1309676 and also this thread: http://mail.python.org/pipermail/python-dev/2005-September/056709.html Here's a description of this function: "relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from a specified 'start' point." This patch includes Windows and *nix versions. It has been tested on Windows XP and OS/X 10.4. Note: there is no 'classic mac' version as I don't know that platform :-( Changed files are: lib/ntpath.py lib/test/test_ntpath.py lib/posixpath.py lib/test/test_posixpath.py I'll send a second patch for the documentation shortly. As this is my first submission please be gentle with me if there are any basic errors :-) ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-23 18:26 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54556. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-23 07:07 Message: Logged In: YES user_id=21627 Originator: NO The patch works fine, please apply. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-21 14:02 Message: Logged In: YES user_id=1344176 Originator: NO Since the trouble is os.getcwd() returns a non-posix path on Windows, I've taken the approach of mocking os.getcwd() so that it returns something posix-y. Martin, could you verify that the attached patch works on Windows? File Added: test_posixpath.py.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-21 12:12 Message: Logged In: YES user_id=21627 Originator: NO The test fails on Windows. In particular, this test: self.assertEqual(posixpath.relpath(os.path.abspath("a")), "a") fails. os.path.abspath("a") gives something like r"c:\python26\a". posixpath.relpath is then not able to cope with it. As a result, it returns r"c:\python26\a" as the relative path. Using posixpath.abspath doesn't help, either, since that will give r"c:\python26/a" which relpath then still cannot process correctly. One solution would be to use pass a POSIX path and start path to relpath; the other would be to use os.path in both cases. os.path.relpath(os.path.abspath("a")) does indeed give "a" on Windows. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 18:16 Message: Logged In: YES user_id=1344176 Originator: NO Checked in as r54419. Thanks for the patch, Richard! ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 04:24 Message: Logged In: YES user_id=849994 Originator: NO Since there is an "Availability" remark, I wouldn't be concerned. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-15 23:04 Message: Logged In: YES user_id=1344176 Originator: NO I've attaching a tweaked/updated version of this patch. Is anyone bothered that there's no OS/2 or classic Mac implementation for this? If not, I can go ahead and commit it. File Added: relpath.patch ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2006-01-30 16:54 Message: Logged In: YES user_id=1207189 Here is a second version of the 'relpath' function. I've modified it as per Neal Norwitz's comments, with two exceptions: - I've left in a check for a path supplied on input, as otherwise an unclear exception is raised. - I haven't written any test cases for exceptions in ntpath.py, as the "tester" function doesn't seem to handle them. This function (if accepted) will also require the following addition to the documentation: relpath(path, start=os.curdir) Return a relative filepath to 'path' either from the current directory or from an optional 'start' point. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-21 09:05 Message: Logged In: YES user_id=1207189 Hi all, Going on vacation for a few days, will try to finish this patch for the new year. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-19 13:00 Message: Logged In: YES user_id=33168 Sorry Richard. It's still in my inbox. I'll try to get to it soon. Feel free to post any info/questions here so others can answer too. ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-12-19 06:14 Message: Logged In: YES user_id=1207189 Most of the patch is completed as per Neal's suggestions for improvement. I had a few questions outstanding for Neal and depending on his advice I was going to modify the input checks and/or the unit tests. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-12-17 12:04 Message: Logged In: YES user_id=1188172 To the OP: have you completed the patch? To the others: is this okay to get into 2.5? ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-31 07:54 Message: Logged In: YES user_id=1207189 Hi, Thanks for all your comments; I'll amend my code & re-submit a patch. I've got a few questions for you: " I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. " By adding this check on the input I wanted to avoid this error message: >>> os.path.relpath('') Traceback (most recent call last): File "", line 1, in File "/usr/local/cvsrep/python/dist/src/Lib/posixpath.py", line 473, in relpath return os.path.join(*rel_list) TypeError: join() takes at least 1 argument (0 given) Which to me is obscure and forces you to dive into the stdlib code to understand the real cause of the problem. I'd noticed that the other functions in os.path don't seem to check input, but usually a sensible default value can be assumed (example, with abspath: if no argument is given it's sensible to use the current dir instead). So I'd like to keep the check on the input. However if you feel that it's not needed I'll remove it. " I'd like to see test cases for the exceptions raised in ntpath " When writing this I tried to maintain a consistent style with the other tests in the test_ntpath.py script which all use the "tester" function. As far as I can tell, this function doesn't allow testing of exceptions. I was tempted to use Unittest instead (as per the tests I wrote for posixpath.py) as it would allow testing of exceptions, but decided to try and maintain consistency. Do you think I should switch to using UnitTest instead? Regards, Richard ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-28 02:21 Message: Logged In: YES user_id=33168 Thanks for the patch, it's not in bad shape. Please attach the doc patch file here. It's easier to have a single patch than multiple. A couple of things about the patch. Some of these should be in PEP 8. * <> is deprecated in favor of != (didn't see this doc'd in PEP 8 though, maybe it's in another PEP) * don't add extra parentheses, e.g., (abspath(start)).split(sep) should be abspath(start).split(sep) * I'm not sure it's worth checking that there's a path. I noticed that abspath() didn't have a similar check. I didn't look for other places, but doubt there is much error checking since a reasonable exception should be raised. * The for loop is a lot to swallow. It would be easier to read if you used a local variable for the min_len IMO. * I'd like to see a test case for: relpath("a", "a") * I'd like to see test cases in ntpath for paths with a drive letter * I'd like to see test cases for the exceptions raised in ntpath Another note that isn't a big deal. It's good that you made a single patch file. I think most other developers prefer the patch to start one level up. ie, don't start in Lib/, include it in the patch. I certainly prefer it this way so I don't have to cd much. It just makes development a little easier. You can attach new versions to this tracker item, but try to remember to add a description that says version # so no one reviews an older version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1339796&group_id=5470 From noreply at sourceforge.net Sat Mar 24 00:01:05 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 23 Mar 2007 16:01:05 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) >Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-21 15:20 Message: Logged In: YES user_id=21627 Originator: NO I think the problem with this patch is that % substitution is not widely available in /bin/sh. For example, on Solaris 9, /bin/sh gives 'bad substitution'. Even /usr/xpg4/bin/sh rejects it. So I think this should be redone using, say, sed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 09:56 Message: Logged In: YES user_id=849994 Originator: NO Okay, thanks. Martin, you know how to do the configure magic properly, do you want to commit this? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:08 Message: Logged In: YES user_id=51702 Originator: YES New patch fixes your concern Georg. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:06 Message: Logged In: YES user_id=51702 Originator: YES File Added: fix-prefix-with-trailing-slash-problem-2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 13:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Sat Mar 24 15:31:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 07:31:11 -0700 Subject: [Patches] [ python-Patches-1489771 ] Updates to syntax rules in reference manual Message-ID: Patches item #1489771, was opened at 2006-05-16 21:09 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: ?iga Seilnacht (zseil) Assigned to: ?iga Seilnacht (zseil) Summary: Updates to syntax rules in reference manual Initial Comment: I tried to update the reference manual to the current Python syntax. Some things are still missing, most notably the yield expression. Detailed description of changes below. I can also attach the generated webpages, if someone is interested. Expressions =========== List Displays ------------- Reordered the rules so that the style is consistent with the rest of the manual. Separated listmaker into expression_list and list_comprehension, for better readability. Replaced "expression_list" between "for" and "in" with "target_list". See this thread for details: http://mail.python.org/pipermail/python-dev/2006-April/064264.html The only thing missing is old_lambdadef. Generator Expressions --------------------- Simmilar as above. Calls ----- Fixed the latex syntax (somebody forgot to remove a line when generators were introduced). Replaced test with expression. Fixed allowed positions for commas (func(*args,) is not allowed). Boolean operations ------------------ Restructured the new conditional expression so that it is more readable. Simple Statements ================= Augmented assignment statements ------------------------------- Removed comments from "productionlist" macro, since they broke the generated grammar.txt file. Removed empty groups that are not needed anymore, since automatic conversion to guillemets was disabled. Unfortunately the escaped operator characters would still need manual fixing in the grammar.txt file. The print statement ------------------- Removed all uses of the "optional" macro and replaced them with sqare brackets, since it broke the generated grammar.txt file. The import statement -------------------- Replaced all invalid uses of name with identifier. Added relative import notation to the grammar section. Description of relative imports is still needed. The exec statement ------------------ Corrected a minor mistake, since exec "a = 1" or "a = 2" is not valid Python syntax. Added a (commented out) section about a strange feature (you can already treat exec as a function) that should IMHO be included in documentation and its use encouraged over the current notation. Compound statements =================== The with statement ------------------ Added missing macro. Function definition ------------------- Cleaned up "parameter_list" so that it is correct and expresses all the restrictions, but is still easier to understand (I hope). Still needed ------------ Yield became an expression in version 2.5, but this is not documented. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2007-03-24 15:31 Message: Logged In: YES user_id=1326842 Originator: YES Commited as revision 54559, 54560 (2.5). ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2007-03-21 20:52 Message: Logged In: YES user_id=1326842 Originator: YES Ok, here is the final version. There was a whole section missing (generator expressions), so it took some time to complete. I also removed the function call and function definition changes, because I couldn't understand them anymore :). Those changes were more or less cosmetical anyway. I'll leave the patch open until tomorrow, and then check it in if there won't be any objections. File Added: reference_manual_final.diff ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-13 21:23 Message: Logged In: YES user_id=849994 Originator: NO You can probably look at this/complete it and apply it yourself now ;) ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 15:33 Message: Logged In: YES user_id=1326842 Yes, the only thing missing was old lambda. The new patch ('reference_manual_old_lambda') includes it. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 13:01 Message: Logged In: YES user_id=849994 The testlist in list comprehensions ("testlist_safe" in Grammar/Grammar) is different from the normal testlist. Does your patch address this? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 01:56 Message: Logged In: YES user_id=1326842 Attaching a patch updated to the current trunk with two minor fixes: - I reverted the changes to the __future__ statement because they broke the output; - fixed a mistake in the function definition section; I didn't know that ``def f(a, (b, c)=(1, 2)): pass`` is valid syntax. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-18 05:46 Message: Logged In: YES user_id=1326842 I created another patch and updated the previous two with the following fixes: - Disabled an example of the EBNF notation in introduction to prevent name clashes and inclusion into the generated grammar file. - yield can be a bare statement in 2.5. - Reintroduced "name" in import statements, so that explanation can stay the same. - Reformated __future__ import statement, but left the latex syntax broken so that it still won't be included into grammar.txt. - Fixed a paragraph about valid __future__ features. The new patch is more of an example how hard it would be to synchronise the names. It is more or less consistent with the Grammar file, but as a consequence is completely out of sync with the surrounding text. While I would like to see less differences betwen Grammar and Reference manual, I don't think it is that easy, since someone would also have to check the rest of the text and fix all incorrect references. I would guess that the same holds for changing the Grammar file; you would simply have to change too much code. I think that the simplest solution is to add the table from my previous comment to the PEP 306. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:55 Message: Logged In: YES user_id=764593 I agree that it would be better if they were consistent. But does the manual have better names? If so, alpha is a good time to fix the grammar file. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-17 18:54 Message: Logged In: YES user_id=1326842 Token names in reference manual already differ from those in Grammar file. I only added new tokens where it helps readability: - I've split listmaker into expression_list (already present in reference manual and often used) and list_comprehension. - I added conditional_expression, because I thought it helps readability. - Differences in function definiton and call syntax can't be avoided since Grammar file doesn't express all the limitations. - Same goes for target_list; Grammar uses testlist, but that was one of the problems raised in the thread mentioned above. The biggest problem is that what is known as "test" in Grammar/Grammar, is "expression" in the reference manual, and I think I fixed all parts that didn't take this in cosideration. I'm attaching two new patches. reference_manual_updated.diff contains another fix (removed unneeded markup and comments), but is otherwise the same as the previous patch. reference_manual_conservative.diff also contains this fix, but removes tokens list_comprehension and conditional_expression. This means that there are still large differences between Grammar file and reference manual, most notably: Grammar manual --------------------------------------------- NAME identifier expr or_expr test expression old_test test testlist expression_list | target_list testlist_safe testlist All of these differences were already present before my changes. Let me know if you want them fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 17:01 Message: Logged In: YES user_id=849994 I think the token names in the reference should not be different from those in python/Grammar/Grammar. Aside from this, the patch is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 From noreply at sourceforge.net Sat Mar 24 20:13:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 12:13:29 -0700 Subject: [Patches] [ python-Patches-1638033 ] Add httponly to Cookie module Message-ID: Patches item #1638033, was opened at 2007-01-17 21:07 Message generated for change (Comment added) made by arvins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1638033&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arvin Schnell (arvins) Assigned to: Nobody/Anonymous (nobody) Summary: Add httponly to Cookie module Initial Comment: Add the Microsoft extension httponly to the Cookie module. ---------------------------------------------------------------------- >Comment By: Arvin Schnell (arvins) Date: 2007-03-24 20:13 Message: Logged In: YES user_id=698939 Originator: YES Maybe you are right about the cookie module. I'm not so much into that. But I just read that Firefox 3.0 Alpha 3 finally has support for the httponly attribute (see http://www.mozilla.org/projects/firefox/3.0a3/releasenotes/) so I think it's time that Python will also have the support. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-01 00:17 Message: Logged In: YES user_id=261020 Originator: NO I see. That sounds reasonable, but I won't comment on whether it should be applied since this part of module Cookie didn't really make sense to me in the first place (I explain why in my comment of 2006-12-03 16:49 in http://python.org/sf/1372650). ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-01-30 19:45 Message: Logged In: YES user_id=698939 Originator: YES Anybody who sets a cookie with key="httponly" is likely in trouble. I don't know and can't check how the IE behaves in that case. But disallowing this use shouldn't hurt. Use case: I would like to use the httponly attribute in Django. I think it's also useful for other web-frameworks. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-01-30 01:52 Message: Logged In: YES user_id=261020 Originator: NO This is backwards-incompatible, no? The behaviour of Morsel.set() changes (disallowing key="httponly") hence the behaviour of BaseCookie.__setitem__ changes. Do you have a use case? ---------------------------------------------------------------------- Comment By: Arvin Schnell (arvins) Date: 2007-01-19 18:01 Message: Logged In: YES user_id=698939 Originator: YES Sure, I have added some documentation to the patch. File Added: python.diff ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2007-01-19 16:06 Message: Logged In: YES user_id=764593 Originator: NO The documentation change should say what the attribute does. (It requests the the cookie be hidden from javascript, and available only to http requests.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1638033&group_id=5470 From noreply at sourceforge.net Sat Mar 24 23:34:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 15:34:13 -0700 Subject: [Patches] [ python-Patches-1686273 ] More PEP 3116 classes Message-ID: Patches item #1686273, was opened at 2007-03-22 18:18 Message generated for change (Comment added) made by mark_t_russell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: More PEP 3116 classes Initial Comment: More PEP 3116 implementation: - docstrings for RawIOBase methods - Simple implementations of StringIO, TextIOBase and TextIOWrapper - Simplify while condition in BufferedReader.read() - Add unit tests for StringIO (modified copy of the ByteIO tests) ---------------------------------------------------------------------- >Comment By: Mark Russell (mark_t_russell) Date: 2007-03-24 22:34 Message: Logged In: YES user_id=1017234 Originator: YES More changes: - Make TextIOWrapper.readline() reasonably efficient - Fix TextIOWrapper.read() - Unit tests for TextIOWrapper .readline() and .read() (more needed) - Readahead support for BufferedReader (i.e. so it reads in buffer size chunks) - Fix codecs.BufferedIncrementalDecoder buffer type (bytes not str) - Unit test to check the raw reads that BufferedReader is doing - Fix BufferedRandom positioning bug when switching from reading to writing File Added: pep-3116-textio.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686273&group_id=5470 From noreply at sourceforge.net Sat Mar 24 23:46:30 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 15:46:30 -0700 Subject: [Patches] [ python-Patches-1686273 ] More PEP 3116 classes Message-ID: Patches item #1686273, was opened at 2007-03-22 18:18 Message generated for change (Comment added) made by mark_t_russell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Russell (mark_t_russell) Assigned to: Nobody/Anonymous (nobody) Summary: More PEP 3116 classes Initial Comment: More PEP 3116 implementation: - docstrings for RawIOBase methods - Simple implementations of StringIO, TextIOBase and TextIOWrapper - Simplify while condition in BufferedReader.read() - Add unit tests for StringIO (modified copy of the ByteIO tests) ---------------------------------------------------------------------- >Comment By: Mark Russell (mark_t_russell) Date: 2007-03-24 22:46 Message: Logged In: YES user_id=1017234 Originator: YES File Added: pep-3116-pep.diff ---------------------------------------------------------------------- Comment By: Mark Russell (mark_t_russell) Date: 2007-03-24 22:34 Message: Logged In: YES user_id=1017234 Originator: YES More changes: - Make TextIOWrapper.readline() reasonably efficient - Fix TextIOWrapper.read() - Unit tests for TextIOWrapper .readline() and .read() (more needed) - Readahead support for BufferedReader (i.e. so it reads in buffer size chunks) - Fix codecs.BufferedIncrementalDecoder buffer type (bytes not str) - Unit test to check the raw reads that BufferedReader is doing - Fix BufferedRandom positioning bug when switching from reading to writing File Added: pep-3116-textio.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1686273&group_id=5470 From noreply at sourceforge.net Sun Mar 25 04:20:18 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 24 Mar 2007 19:20:18 -0700 Subject: [Patches] [ python-Patches-1677688 ] Support CREATE_SUSPENDED flag in subprocess.py for Win32 Message-ID: <200703250220.l2P2KIhq024469@sc8-sf-db2-new-b.sourceforge.net> Patches item #1677688, was opened at 2007-03-09 16:33 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Chris Heller (chrisheller) Assigned to: Nobody/Anonymous (nobody) Summary: Support CREATE_SUSPENDED flag in subprocess.py for Win32 Initial Comment: The CreateProcess() function that subprocess uses on Windows allows for creation of processes in a suspended state. To then start the process running though you need to call ResumeThread on the primary thread of the process. Currently this thread handle gets closed, then discarded by the subprocess module. In order to continue making use of subprocess, but also use the CREATE_SUSPENDED flag, I modified my local copy of subprocess to retain the thread when the CREATE_SUSPENDED flag was supplied. If the CREATE_SUSPENDED flag is not requested, then the code behaves exactly the same as it currently does. The attached patch is against Subversion trunk, revision 53646. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-03-24 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Jason Orendorff (jorend) Date: 2007-03-09 19:50 Message: Logged In: YES user_id=18139 Originator: NO This patch doesn't work. Three bugs: (1) bad syntax, && should be & (2) global name CREATE_SUSPENDED isn't defined; and (3) after the if statement, ht.Close() happens anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1677688&group_id=5470 From noreply at sourceforge.net Mon Mar 26 05:23:48 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 25 Mar 2007 20:23:48 -0700 Subject: [Patches] [ python-Patches-1683908 ] PEP 361 Warnings Message-ID: Patches item #1683908, was opened at 2007-03-19 13:32 Message generated for change (Comment added) made by rhamphoryncus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Thomas Wouters (twouters) Summary: PEP 361 Warnings Initial Comment: Attached is a patch that adds some of the warnings mentioned in PEP 361, specifically: * `repr` * cmp() and __cmp__ * apply() * coerce() and __coerce__ * reduce() * {}.has_key() I'm unsure what conclusions were reaches wrt py3k-specific command line options or warning categories, so I've used DeprecationWarning as a placeholder. Not surprisingly, this causes large amounts of noise in the test suite (but no failures). Thus far I've focused on warnings that (in my opinion) should be fixed in 2.x code. Many of the other warnings (such as using {}.iteritems()) are better handled using the 2to3 translator. Again though, I'm unsure if they will ultimately be given a distinct warning category, so I await input on that. ---------------------------------------------------------------------- >Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-25 21:23 Message: Logged In: YES user_id=12364 Originator: YES Version 2 of my patch: * Drops the warning for ``. Anthony Baxter's patch (#1631035) handles this better. * __cmp__ and __coerce__ are checked for at class creation time as well as when called. Currently will emit two warnings. * A private function (_warnpy3k()) in warnings.py was added to take care of extracting warning location from the passed in function, but I've been unable to get that working properly. At the moment it only serves as a single location (or two locations, if you include the C wrapper) to modify the warning message. * The warning message was modified to be more informative, including a URL. The URL currently points nowhere. * A global flag (_Py_Py3kWarningFlag) was added to skip the warning code when not enabled. I have located it with the other C interfaces to the warnings module on the assumption that it will be integrated as part of Neal's rewrite of warnings.py in C. It defaults to on and I have not included a command line option to control it. * Some warnings are omitted before warnings.py gets loaded, causing them to always be printed. Presumably this will be fixed when warnings.py is rewritten in C. * test_subprocess fails. This is due warnings in the output and will be fixed when the warnings default to silent. * test_descr fails. This is due to a test (line 1298, SF bug 572567) that defines a class with __cmp__ and counts objects using gc.get_objects(). Although easily fixed by switching to __eq__, I've noticed that the p3yk branch uses __cmp__ as well. It may be failing silently? * One of the tests fail if I merge together the two loops it contains, but it shouldn't. I'm guessing this is due to not registering the warnings in the right location, which is what _warnpy3k() should fix. * Running regrtest on test_py3kwarnings.py fails. I'm guessing this is due to the above. * Running regrtest on everything shows many leaks (and a few more failures). I'm hoping this is due to the above as well. File Added: python2.6-warnings2.diff ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2007-03-20 22:02 Message: Logged In: YES user_id=29957 Originator: NO Here's a -W py3k patch I did. Think it went to the list, not the trackers. File Added: warn3.patch ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 21:53 Message: Logged In: YES user_id=33168 Originator: NO Oooh, Anthony pointed me to his patch: http://python.org/sf/1631035 So no need to impl anything that's in there. I don't think there's much overlap so far, but I didn't look that closely. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-20 21:48 Message: Logged In: YES user_id=33168 Originator: NO Thomas, should there be a 3k warning category that's a subclass of DeprecationWarning? Should this patch impl the -3k flag or whatever it's called? Damn, I really gotta get that warnings patch done. First I gotta get the buildbots in decent shape, get 2.5.1 out, then xrange patch, then warnings. That list sucks. It doesn't even include crap like get inbox less than 200 unread msgs or do taxes. :-( ---------------------------------------------------------------------- Comment By: Adam Olsen (rhamphoryncus) Date: 2007-03-20 16:32 Message: Logged In: YES user_id=12364 Originator: YES I originally had the `` warning emitted during the parse stage, but this prevents it from showing when the .pyc file already exists. Which is more important? And is it an actual DeprecationWarning or a PendingDeprecationWarning? I didn't notice a way to produce a warning at both definition time and use time, without emitting it twice. I agree that both is better, so I'll figure it out. Linking to a wiki page would be far better than trying to squeeze a full explanation into one sentence. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2007-03-20 15:57 Message: Logged In: YES user_id=34209 Originator: NO The ``-warning should be emitted by the parser, not when the UNARY_CONVERT opcode is executed. I'm still not entirely sure __cmp__/cmp() should be deprecated (cmp() is terribly convenient, and I haven't heard Guido say they really should be. Maybe just __cmp__ should go.) I wonder if we shouldn't do the warning for __coerce__ and __cmp__ at class creation time as well as at call time. (Class creation is earlier and oftner, but doesn't catch all cases. The warnings registry would make sure the warning is only emitted once, by default.) Some of the messages could maybe be more informative; perhaps we can link to a wiki page with py3k-deprecation info. On the other hand, people will only see most of these if they do the -Wpy3k thing. (The ``-warning should be a real deprecation warning in the parser, not related to -Wpy3k.) Other than those minor points, looks good. I think it should wait for the C-warnings-module Neal N's working on, though, before we really check it in. Assigning to Neal for him to take a look at. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683908&group_id=5470 From noreply at sourceforge.net Mon Mar 26 18:29:55 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 26 Mar 2007 09:29:55 -0700 Subject: [Patches] [ python-Patches-1685642 ] Add IllegalStateError Message-ID: Patches item #1685642, was opened at 2007-03-22 01:25 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685642&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Add IllegalStateError Initial Comment: Java has an exception called IllegalStateException. It is very useful for signaling "what you did would have been OK, but right now I can't do it." Python does not have a counterpart, but I think it should. For example, if you have a Python RDBMS-binding and you call db.select() before calling db.connect() it could raise a IllegalStateError (or maybe a subclass of it) that says 'IllegalStateError: "Must be connected to perform queries"'. Or for another example, take the Thread.start() function. Currently, if you call myThread.start() twice it will raise an AssertionError. That's no good because the result is undefined if you run python with -O. See Bug #904498 and Patch #1676820 (Martin v. L??wis comment). IllegalStateError should fit perfectly here: >>> t = threading.Thread() >>> t.start() >>> t.start() Traceback (most recent call last): ... IllegalStateError: thread already started ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-26 18:29 Message: Logged In: YES user_id=51702 Originator: YES Georg, do you think that I should change the patch so that IllegalStateError sublcasses RuntimeError instead? Changing exceptions in the Standard Library to IllegalStateError would be part 2 of the patch. I don't think that should cause any trouble - only exceptions like AssertionError or base Exceptions would be changed. That's why I hope it can go into python 2.x. But bringing it up on the mailing-list is still required I guess. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-23 19:41 Message: Logged In: YES user_id=849994 Originator: NO In principle this is a good idea -- currently there's no guideline what to raise in such a situation. Some libraries raise RuntimeError (probably a new exception should be made subclass thereof), some do assertions, some raise custom exceptions. However, for this to be a complete patch, you'd have to find all those places where IllegalStateError would be appropriate. Also, switching to it would be a Py3k thing, provided that this breakage is suffered by python-dev. In any case, I think you should bring it up on the python-3000 mailing list -- otherwise this will never be decided upon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685642&group_id=5470 From noreply at sourceforge.net Tue Mar 27 20:51:54 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 11:51:54 -0700 Subject: [Patches] [ python-Patches-1689402 ] Replace time_t by Py_time_t Message-ID: Patches item #1689402, was opened at 2007-03-27 20:51 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=1689402&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Replace time_t by Py_time_t Initial Comment: In the thread "datetime module enhancements" Guido and others said that it is unpythonic to limit timestamp (seconds since Epoch) to an signed int with 32bit. http://permalink.gmane.org/gmane.comp.python.devel/86750 I've made a patch that introduces a new type Py_time_t as a first step to increase the size of time stamps. For now it's just an alias for time_t. typedef time_t Py_time_t; I'm proposing to change time_t in two steps: Python 2.6: Replace every occurrence of time_t by Py_time_t and give third party authors time to change their software Python 2.7 / 3000: Change Py_time_t to a signed 64bit int on all platforms and provide the necessary workaround for platforms with a 32bit time_t. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&group_id=5470 From noreply at sourceforge.net Wed Mar 28 01:40:35 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 27 Mar 2007 16:40:35 -0700 Subject: [Patches] [ python-Patches-1676135 ] Remove trailing slash from --prefix Message-ID: Patches item #1676135, was opened at 2007-03-07 23:30 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: Remove trailing slash from --prefix Initial Comment: Two tests in test_inspect.py failed for me with the following traceback: ====================================================================== FAIL: test_stack (__main__.TestInterpreterStack) ---------------------------------------------------------------------- Traceback (most recent call last): File "test/test_inspect.py", line 92, in test_stack (modfile, 16, 'eggs', [' st = inspect.stack()\n'], 0)) AssertionError: ('/tmp/install//lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) != ('/tmp/install/lib/python2.6/test/inspect_fodder.py', 16, 'eggs', [' st = inspect.stack()\n'], 0) This happened because I configured Python with "./configure --prefix=/tmp/install/" and autoconf automagically created paths such as ${prefix}/lib so it got a double slash. Double slashes are completely harmless on Unix and test_inspect.py is probably wrong in comparing two paths like that. Nevertheless, they are ugly and I think it is worthwhile to eliminate them. So here is patch that does that by adding a "hack" to configure.in. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-28 01:40 Message: Logged In: YES user_id=51702 Originator: YES Here is patch with sed instead. I hope this should be safe because all variants of UNIX should have sed I think. File Added: fix-prefix-with-trailing-slash-problem-3.patch ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2007-03-21 15:20 Message: Logged In: YES user_id=21627 Originator: NO I think the problem with this patch is that % substitution is not widely available in /bin/sh. For example, on Solaris 9, /bin/sh gives 'bad substitution'. Even /usr/xpg4/bin/sh rejects it. So I think this should be redone using, say, sed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-21 09:56 Message: Logged In: YES user_id=849994 Originator: NO Okay, thanks. Martin, you know how to do the configure magic properly, do you want to commit this? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:08 Message: Logged In: YES user_id=51702 Originator: YES New patch fixes your concern Georg. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-20 23:06 Message: Logged In: YES user_id=51702 Originator: YES File Added: fix-prefix-with-trailing-slash-problem-2.patch ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-16 13:27 Message: Logged In: YES user_id=51702 Originator: YES Ok, I'll add a specialcase for that which should be trivial. Also, the manual for sys.prefix is a little vague and probably needs an update. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:26 Message: Logged In: YES user_id=849994 Originator: NO I'd still specialcase prefix == "/". Currently, with your patch it ends up as sys.prefix == "", which is bad if someone does x = os.path.join(sys.prefix, "lib", ...) I think who configures with --prefix=/ can live with the double slashes. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-16 03:49 Message: Logged In: YES user_id=1344176 Originator: NO Sounds good to me. How about you, Georg? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-14 00:05 Message: Logged In: YES user_id=51702 Originator: YES Yes, that could be fixed too. But all tracebacks originating from the standard library also get the double slash: >>> import fnmatch >>> fnmatch.filter(1, 2) Traceback (most recent call last): File "", line 1, in File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 46, in filter res = translate(pat) File "/home/bjourne/install//lib/python2.6/fnmatch.py", line 78, in translate i, n = 0, len(pat) TypeError: object of type 'int' has no len() IMHO, that is ugly enough that it ought to be fixed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-12 18:37 Message: Logged In: YES user_id=1344176 Originator: NO I think I'd rather fix the tests, using something like os.path.normpath(). ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-08 21:15 Message: Logged In: YES user_id=51702 Originator: YES It does. Autoconf sees that prefix is the empty string "", but as the variable is defined it does not replace it with the default /usr/local. So it should be safe. Although it would be nice if someone else could test it too. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2007-03-08 09:08 Message: Logged In: YES user_id=849994 Originator: NO Does this work if the prefix is "/"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1676135&group_id=5470 From noreply at sourceforge.net Wed Mar 28 13:41:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 04:41:03 -0700 Subject: [Patches] [ python-Patches-1689402 ] Replace time_t by Py_time_t Message-ID: Patches item #1689402, was opened at 2007-03-27 20:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Replace time_t by Py_time_t Initial Comment: In the thread "datetime module enhancements" Guido and others said that it is unpythonic to limit timestamp (seconds since Epoch) to an signed int with 32bit. http://permalink.gmane.org/gmane.comp.python.devel/86750 I've made a patch that introduces a new type Py_time_t as a first step to increase the size of time stamps. For now it's just an alias for time_t. typedef time_t Py_time_t; I'm proposing to change time_t in two steps: Python 2.6: Replace every occurrence of time_t by Py_time_t and give third party authors time to change their software Python 2.7 / 3000: Change Py_time_t to a signed 64bit int on all platforms and provide the necessary workaround for platforms with a 32bit time_t. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 13:41 Message: Logged In: YES user_id=21627 Originator: NO After a shallow review, I think the patch is incorrect. There must be places where a Py_time_t may get truncated to a time_t; in these places, no silent truncation should occur, but an exception be raised. I can find no place in the patch where this happens. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&group_id=5470 From noreply at sourceforge.net Wed Mar 28 14:00:06 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 05:00:06 -0700 Subject: [Patches] [ python-Patches-1178136 ] cgitb.py support for frozen images Message-ID: Patches item #1178136, was opened at 2005-04-07 00:45 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1178136&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: cgitb.py support for frozen images Initial Comment: cgitb.py does not report the line numbers in the stack trace if the python program is frozen. This is because the source code is not available. The attached patch fixes this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1178136&group_id=5470 From noreply at sourceforge.net Wed Mar 28 14:02:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 05:02:25 -0700 Subject: [Patches] [ python-Patches-1189216 ] zipfile module and 2G boundary Message-ID: Patches item #1189216, was opened at 2005-04-25 04:08 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1189216&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: None >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile module and 2G boundary Initial Comment: The zipfile module currently can not handle archives that have file headers that begin past the 2**31 byte boundary. This is really bug #679953 all over again -- that fix didn't solve all of the problem. Patch to CVS HEAD attached, backport candidate to 2.4.2 and 2.3.6. ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2005-10-16 21:18 Message: Logged In: YES user_id=198518 [From a post to python-help] Related to this is that zipfile raises an exception on creating a file that's too big. It seems that the limitation should be documented or removed. This is from the message to python-help: python version 4.2. the class zipfile in the module zipfile is unable to .close() a file bigger than 2^32-1 (or whatever) bytes. Traceback (most recent call last): File "bk.py", line 12, in ? zf.close() File "C:\Python24\lib\zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert to int ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1189216&group_id=5470 From noreply at sourceforge.net Wed Mar 28 16:48:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 07:48:39 -0700 Subject: [Patches] [ python-Patches-1689402 ] Replace time_t by Py_time_t Message-ID: Patches item #1689402, was opened at 2007-03-27 20:51 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Replace time_t by Py_time_t Initial Comment: In the thread "datetime module enhancements" Guido and others said that it is unpythonic to limit timestamp (seconds since Epoch) to an signed int with 32bit. http://permalink.gmane.org/gmane.comp.python.devel/86750 I've made a patch that introduces a new type Py_time_t as a first step to increase the size of time stamps. For now it's just an alias for time_t. typedef time_t Py_time_t; I'm proposing to change time_t in two steps: Python 2.6: Replace every occurrence of time_t by Py_time_t and give third party authors time to change their software Python 2.7 / 3000: Change Py_time_t to a signed 64bit int on all platforms and provide the necessary workaround for platforms with a 32bit time_t. ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-03-28 16:48 Message: Logged In: YES user_id=560817 Originator: YES Yes, you are right. There is no place where the ptch checks for truncating - because the patch doesn't change the size of time_t. The current patch defines Py_time_t is an alias for time_t so 3rd party authors can update their software to use Py_time_t instead of time_t in Python 2.6. Also it gives me time to study the impacts on systems with a 32bit time_t and to get feedback from core developers. May we take the discussion to python-ideas? I've started a thread yesterday. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2007-03-28 13:41 Message: Logged In: YES user_id=21627 Originator: NO After a shallow review, I think the patch is incorrect. There must be places where a Py_time_t may get truncated to a time_t; in these places, no silent truncation should occur, but an exception be raised. I can find no place in the patch where this happens. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&group_id=5470 From noreply at sourceforge.net Wed Mar 28 22:55:34 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 13:55:34 -0700 Subject: [Patches] [ python-Patches-1690164 ] Refactor test_sax.py to use unittest. Message-ID: Patches item #1690164, was opened at 2007-03-28 14:55 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=1690164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_sax.py to use unittest. Initial Comment: This patch refactors test_sax.py to use unittest. When this patch is applied, Lib/test/output/xmltest will be invalid, but not yet ready for removal (test_pyexpat.py refactoring still pending). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 From noreply at sourceforge.net Wed Mar 28 22:56:03 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 13:56:03 -0700 Subject: [Patches] [ python-Patches-1690164 ] Refactor test_sax.py to use unittest. Message-ID: Patches item #1690164, was opened at 2007-03-28 14:55 Message generated for change (Settings changed) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_sax.py to use unittest. Initial Comment: This patch refactors test_sax.py to use unittest. When this patch is applied, Lib/test/output/xmltest will be invalid, but not yet ready for removal (test_pyexpat.py refactoring still pending). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 From noreply at sourceforge.net Wed Mar 28 22:59:02 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 13:59:02 -0700 Subject: [Patches] [ python-Patches-1690169 ] Refactor test_pyexpat.py to use unittest. Message-ID: Patches item #1690169, was opened at 2007-03-28 14:59 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=1690169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_pyexpat.py to use unittest. Initial Comment: This patch refactors test_pyexpat.py to use unittest. When this patch is applied, Lib/test/output/test_pyexpat can be removed. This patch combined with patch 1683397 and patch 1690164 makes Lib/test/output/xmltest redundant. It can be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 From noreply at sourceforge.net Wed Mar 28 22:59:13 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 13:59:13 -0700 Subject: [Patches] [ python-Patches-1690169 ] Refactor test_pyexpat.py to use unittest. Message-ID: Patches item #1690169, was opened at 2007-03-28 14:59 Message generated for change (Settings changed) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_pyexpat.py to use unittest. Initial Comment: This patch refactors test_pyexpat.py to use unittest. When this patch is applied, Lib/test/output/test_pyexpat can be removed. This patch combined with patch 1683397 and patch 1690164 makes Lib/test/output/xmltest redundant. It can be removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 From noreply at sourceforge.net Wed Mar 28 23:52:04 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 14:52:04 -0700 Subject: [Patches] [ python-Patches-1690201 ] Added support for custom readline functions Message-ID: Patches item #1690201, was opened at 2007-03-28 17:52 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=1690201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Timby (btimby) Assigned to: Nobody/Anonymous (nobody) Summary: Added support for custom readline functions Initial Comment: This patch allows for binding a key or keyseq to a custom function named custom. A custom handler can be registered and will be called by readline when the registered sequence input. Example: rl.py -- import readline def handler(): print "need some help?" readline.set_custom_hook(handler) readline.parse_and_bind("\"?\": custom") text = raw_input("type ? for help# ") -- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690201&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:07:11 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:07:11 -0700 Subject: [Patches] [ python-Patches-1690169 ] Refactor test_pyexpat.py to use unittest. Message-ID: Patches item #1690169, was opened at 2007-03-28 16:59 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Nobody/Anonymous (nobody) Summary: Refactor test_pyexpat.py to use unittest. Initial Comment: This patch refactors test_pyexpat.py to use unittest. When this patch is applied, Lib/test/output/test_pyexpat can be removed. This patch combined with patch 1683397 and patch 1690164 makes Lib/test/output/xmltest redundant. It can be removed. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 18:07 Message: Logged In: YES user_id=1344176 Originator: NO So do I need to apply this patch plus 1683397 and 1690164 at the same time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:07:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:07:39 -0700 Subject: [Patches] [ python-Patches-1683397 ] Refactor test_minidom.py to use unittest. Message-ID: Patches item #1683397, was opened at 2007-03-19 01:05 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683397&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_minidom.py to use unittest. Initial Comment: This patch refactors test_minidom.py to use unittest. Since the test gets run by xmltest.py, this will invalidate the expected output in Lib/test/output/xmltest. There are some other files run by xmltest.py that have not yet been refactored, so Lib/test/output/xmltest is not ready for removal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683397&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:07:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:07:39 -0700 Subject: [Patches] [ python-Patches-1690169 ] Refactor test_pyexpat.py to use unittest. Message-ID: Patches item #1690169, was opened at 2007-03-28 16:59 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_pyexpat.py to use unittest. Initial Comment: This patch refactors test_pyexpat.py to use unittest. When this patch is applied, Lib/test/output/test_pyexpat can be removed. This patch combined with patch 1683397 and patch 1690164 makes Lib/test/output/xmltest redundant. It can be removed. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 18:07 Message: Logged In: YES user_id=1344176 Originator: NO So do I need to apply this patch plus 1683397 and 1690164 at the same time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:07:39 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:07:39 -0700 Subject: [Patches] [ python-Patches-1690164 ] Refactor test_sax.py to use unittest. Message-ID: Patches item #1690164, was opened at 2007-03-28 16:55 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) >Assigned to: Collin Winter (collinwinter) Summary: Refactor test_sax.py to use unittest. Initial Comment: This patch refactors test_sax.py to use unittest. When this patch is applied, Lib/test/output/xmltest will be invalid, but not yet ready for removal (test_pyexpat.py refactoring still pending). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 From noreply at sourceforge.net Thu Mar 29 00:42:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 15:42:01 -0700 Subject: [Patches] [ python-Patches-1690169 ] Refactor test_pyexpat.py to use unittest. Message-ID: Patches item #1690169, was opened at 2007-03-28 14:59 Message generated for change (Comment added) made by jseutter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_pyexpat.py to use unittest. Initial Comment: This patch refactors test_pyexpat.py to use unittest. When this patch is applied, Lib/test/output/test_pyexpat can be removed. This patch combined with patch 1683397 and patch 1690164 makes Lib/test/output/xmltest redundant. It can be removed. ---------------------------------------------------------------------- >Comment By: Jerry Seutter (jseutter) Date: 2007-03-28 16:42 Message: Logged In: YES user_id=1727609 Originator: YES It's up to you. If you patch one of them at a time, the xmltest unit test will be broken unless you regenerate the output file. If you apply all three of them at once, you can remove Lib/test/output/xmltest. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 16:07 Message: Logged In: YES user_id=1344176 Originator: NO So do I need to apply this patch plus 1683397 and 1690164 at the same time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:00:28 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:00:28 -0700 Subject: [Patches] [ python-Patches-1690201 ] Added support for custom readline functions Message-ID: Patches item #1690201, was opened at 2007-03-28 17:52 Message generated for change (Comment added) made by btimby You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Timby (btimby) Assigned to: Nobody/Anonymous (nobody) Summary: Added support for custom readline functions Initial Comment: This patch allows for binding a key or keyseq to a custom function named custom. A custom handler can be registered and will be called by readline when the registered sequence input. Example: rl.py -- import readline def handler(): print "need some help?" readline.set_custom_hook(handler) readline.parse_and_bind("\"?\": custom") text = raw_input("type ? for help# ") -- ---------------------------------------------------------------------- >Comment By: Ben Timby (btimby) Date: 2007-03-28 19:00 Message: Logged In: YES user_id=932679 Originator: YES File Added: python-2.3.4-readline_custom.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690201&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:01:25 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:01:25 -0700 Subject: [Patches] [ python-Patches-1690201 ] Added support for custom readline functions Message-ID: Patches item #1690201, was opened at 2007-03-28 17:52 Message generated for change (Comment added) made by btimby You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690201&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ben Timby (btimby) Assigned to: Nobody/Anonymous (nobody) Summary: Added support for custom readline functions Initial Comment: This patch allows for binding a key or keyseq to a custom function named custom. A custom handler can be registered and will be called by readline when the registered sequence input. Example: rl.py -- import readline def handler(): print "need some help?" readline.set_custom_hook(handler) readline.parse_and_bind("\"?\": custom") text = raw_input("type ? for help# ") -- ---------------------------------------------------------------------- >Comment By: Ben Timby (btimby) Date: 2007-03-28 19:01 Message: Logged In: YES user_id=932679 Originator: YES new Example: rl.py -- #!/usr/bin/python import readline def say_hello(): print print "this is my help text..." readline.on_new_line() readline.set_custom_hook(say_hello) readline.parse_and_bind("\"?\": custom") while True: data = raw_input("input# ") print "data: ", data -- ---------------------------------------------------------------------- Comment By: Ben Timby (btimby) Date: 2007-03-28 19:00 Message: Logged In: YES user_id=932679 Originator: YES File Added: python-2.3.4-readline_custom.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690201&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:35:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:35:01 -0700 Subject: [Patches] [ python-Patches-1690169 ] Refactor test_pyexpat.py to use unittest. Message-ID: Patches item #1690169, was opened at 2007-03-28 16:59 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_pyexpat.py to use unittest. Initial Comment: This patch refactors test_pyexpat.py to use unittest. When this patch is applied, Lib/test/output/test_pyexpat can be removed. This patch combined with patch 1683397 and patch 1690164 makes Lib/test/output/xmltest redundant. It can be removed. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:35 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54603. Thanks, Jerry! ---------------------------------------------------------------------- Comment By: Jerry Seutter (jseutter) Date: 2007-03-28 18:42 Message: Logged In: YES user_id=1727609 Originator: YES It's up to you. If you patch one of them at a time, the xmltest unit test will be broken unless you regenerate the output file. If you apply all three of them at once, you can remove Lib/test/output/xmltest. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2007-03-28 18:07 Message: Logged In: YES user_id=1344176 Originator: NO So do I need to apply this patch plus 1683397 and 1690164 at the same time? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690169&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:35:09 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:35:09 -0700 Subject: [Patches] [ python-Patches-1690164 ] Refactor test_sax.py to use unittest. Message-ID: Patches item #1690164, was opened at 2007-03-28 16:55 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_sax.py to use unittest. Initial Comment: This patch refactors test_sax.py to use unittest. When this patch is applied, Lib/test/output/xmltest will be invalid, but not yet ready for removal (test_pyexpat.py refactoring still pending). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:35 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54603. Thanks, Jerry! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690164&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:35:17 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:35:17 -0700 Subject: [Patches] [ python-Patches-1683397 ] Refactor test_minidom.py to use unittest. Message-ID: Patches item #1683397, was opened at 2007-03-19 01:05 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683397&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jerry Seutter (jseutter) Assigned to: Collin Winter (collinwinter) Summary: Refactor test_minidom.py to use unittest. Initial Comment: This patch refactors test_minidom.py to use unittest. Since the test gets run by xmltest.py, this will invalidate the expected output in Lib/test/output/xmltest. There are some other files run by xmltest.py that have not yet been refactored, so Lib/test/output/xmltest is not ready for removal. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:35 Message: Logged In: YES user_id=1344176 Originator: NO Applied as r54603. Thanks, Jerry! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1683397&group_id=5470 From noreply at sourceforge.net Thu Mar 29 01:41:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 28 Mar 2007 16:41:20 -0700 Subject: [Patches] [ python-Patches-728815 ] test_timeout updates Message-ID: Patches item #728815, was opened at 2003-04-28 06:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: test_timeout updates Initial Comment: Changes: - code refactoring; - now we catch only exceptions with proper errno codes (also see bug #708927); - addr_remote changed, ('www.google.com', 80) not always works for me since we use transparent proxy; - attempt to implement testSend(), testSendto(), testSendall(); ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-28 19:41 Message: Logged In: YES user_id=1344176 Originator: NO Bjorn's patch #1677694 supersedes this one, closing. ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2007-03-09 19:52 Message: Logged In: YES user_id=51702 Originator: NO I have created a patch that I hope can supersede this one. This patch does some nice refactorings to test_timeout.py by encapsulating some common code in a sockOperation method. Then that method is used to run the function under test. It also implements tests for testSend, testSendto and testSendall. Plus, (I think) it fixes a bug which (I think) only happens when you access the internet from behind a web proxy. I think the patch is good but there were two problems with it so I created a new one. First, it tries to filter out errors dealing with timeouts from normal socket.error's. But the author forgot about args with only one string as a value. Second, I do not like how the actual assertion of the test is done in the tearDown method. My patch fixes those problems, otherwise it is mostly identical to this patch. It is #1677694 at http://sourceforge.net/tracker/index.php?func=detail&aid=1677694&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-04-14 12:10 Message: Logged In: YES user_id=21627 rhettinger: would you like to review it now? If not, please unassign. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 10:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 10:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 10:52 Message: Logged In: YES user_id=80475 I'll give it more review. Since Py2.3b2 is out, I'm marking this as a change for Py2.4 and we can apply it in early August. ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2003-06-30 08:37 Message: Logged In: YES user_id=89016 I'm no expert in socket programming, so the final decision whether this is OK is your's. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 10:09 Message: Logged In: YES user_id=80475 Walter, are you interested in working this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=728815&group_id=5470 From noreply at sourceforge.net Thu Mar 29 12:46:59 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 03:46:59 -0700 Subject: [Patches] [ python-Patches-1664522 ] Fix for urllib.ftpwrapper.retrfile() and none existing files Message-ID: Patches item #1664522, was opened at 2007-02-20 18:33 Message generated for change (Comment added) made by pknirsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1664522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Phil Knirsch (pknirsch) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for urllib.ftpwrapper.retrfile() and none existing files Initial Comment: When trying to retrieve a none existing file using the urllib.ftpwrapper.retrfile() method the behaviour is that instead of an error message a valid hook is returned and you will recieve a 0 byte file. The current behaviour tries to emulate what one typically sees with http servers and DirIndexes, which means: 1) Try to RETR the file. 2) If that fails, assume it is a directory and LIST it. Unfortunately it doesn't actually check whether the directory actually exists. The attached patch fixes this by remembering the current directory using the PWD command, then temporarily change to that directory and switch back to the previous working directory if it was successfull. If not we raise an IO error, as the file could neither be opened (RETR) nor was it a directory. That way the behaviour is even closer to what happens with http servers where we get a 404 when we try to access a none existing file or directory. Storing the current directory and switching back to it in case of no error will also put the connection back in the proper state and directory, so no unexpected behaviour happens here. The patch is against the current SVN repository at revision 53833. Read ya, Phil ---------------------------------------------------------------------- >Comment By: Phil Knirsch (pknirsch) Date: 2007-03-29 12:46 Message: Logged In: YES user_id=1724367 Originator: YES Anyone looking at this? ;) Read ya, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1664522&group_id=5470 From noreply at sourceforge.net Thu Mar 29 12:51:14 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 03:51:14 -0700 Subject: [Patches] [ python-Patches-1664522 ] Fix for urllib.ftpwrapper.retrfile() and none existing files Message-ID: Patches item #1664522, was opened at 2007-02-20 18:33 Message generated for change (Comment added) made by pknirsch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1664522&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Phil Knirsch (pknirsch) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for urllib.ftpwrapper.retrfile() and none existing files Initial Comment: When trying to retrieve a none existing file using the urllib.ftpwrapper.retrfile() method the behaviour is that instead of an error message a valid hook is returned and you will recieve a 0 byte file. The current behaviour tries to emulate what one typically sees with http servers and DirIndexes, which means: 1) Try to RETR the file. 2) If that fails, assume it is a directory and LIST it. Unfortunately it doesn't actually check whether the directory actually exists. The attached patch fixes this by remembering the current directory using the PWD command, then temporarily change to that directory and switch back to the previous working directory if it was successfull. If not we raise an IO error, as the file could neither be opened (RETR) nor was it a directory. That way the behaviour is even closer to what happens with http servers where we get a 404 when we try to access a none existing file or directory. Storing the current directory and switching back to it in case of no error will also put the connection back in the proper state and directory, so no unexpected behaviour happens here. The patch is against the current SVN repository at revision 53833. Read ya, Phil ---------------------------------------------------------------------- >Comment By: Phil Knirsch (pknirsch) Date: 2007-03-29 12:51 Message: Logged In: YES user_id=1724367 Originator: YES Oh, and the fix is ofc against the current tree, which would be python-2.6 i guess, so fixed that. Read ya, Phil ---------------------------------------------------------------------- Comment By: Phil Knirsch (pknirsch) Date: 2007-03-29 12:46 Message: Logged In: YES user_id=1724367 Originator: YES Anyone looking at this? ;) Read ya, Phil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1664522&group_id=5470 From noreply at sourceforge.net Thu Mar 29 14:32:29 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 05:32:29 -0700 Subject: [Patches] [ python-Patches-1690578 ] Don't block on Queue get/put when time is moved back Message-ID: Patches item #1690578, was opened at 2007-03-29 07: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=1690578&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: xiaowen (xiaowen) Assigned to: Nobody/Anonymous (nobody) Summary: Don't block on Queue get/put when time is moved back Initial Comment: When Queue get and put methods are called with a timeout, they effectively store the end time and might block until that end time is reached. This breaks if the system time is moved back. The attached patch breaks out of the wait if it detects the time has been moved back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690578&group_id=5470 From noreply at sourceforge.net Thu Mar 29 20:15:01 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 11:15:01 -0700 Subject: [Patches] [ python-Patches-723312 ] ability to pass a timeout to underlying socket Message-ID: Patches item #723312, was opened at 2003-04-17 16:03 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Matthew Russell (mattruss) Assigned to: Skip Montanaro (montanaro) Summary: ability to pass a timeout to underlying socket Initial Comment: this patch superceeds an earlier one i posted (#714592) - a bit *too* enthusiastic am afraid (sorry!) classes in modules such as httplib, ftpplib do not currently allow an easy way to take advantage of the new socket timeout feature in 2.3. This patch provides that abilty though one additonal class in socket.py ( socket.NetworkConnection ) and accompying test in test_socket.py (basic though the test is :-s ) As an extra benifit, the patch removes duplicate code, as each connect method in the main class of most modules (FTP, HTTPConnection, Telnet, POP3 etc) are copies of each other. The modules that use sockets are: * ftplib * httplib * telnetlib * poplib * urllib * imaplib * nntplib * xmlrpclib Of these I have only been able to easily refactor NetworkConnection into httplib, ftplib, telnetllib, poplib and smtplib. I did look to see if there were any unittests for theese modules in .Lib/test but found none (? - I appologise if there are some, i am new to the library tests) I did however check that the test() [like] methods at the bottom of each of the afore mentioned modules worked. thanks for your advice again Skip :o) Matt ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-29 15:15 Message: Logged In: YES user_id=752496 Originator: NO After a lot of discussion in python-dev, I added a create_connection() to socket.py module, to which a timeout can be passed. Then, used this new function from httplib, poplib, smtplib, telnetlib, and ftplib, so I'll close this patch. I'm putting this as "accepted" because all my work started from here, and even not applied as is, I used it a lot . Regards, ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2007-02-25 13:43 Message: Logged In: YES user_id=261020 Originator: NO Looks good. I can't write tests right now, but just reading the code: I don't see a path in socket.NetworkConnection.connect() in which "if sock is None" is ever true. And what happens if creating a new socket object raises an exception (e.g. if too many file descriptors are open)? Then socket may be undefined, and will certainly not be None. I think it needs a sock = None before the loop, and also in the except: suite immediately before the continue statement. Some debug output in httplib has been lost (and maybe in the other modules). This is really very useful, so I think it should be preserved. In ftplib, FTP.makeport() should also use socket.NetworkConnection . PEP 8 nits: Use of thisStyleOfName, e.g. networkConnection Use of two-argument raise, e.g. raise socket.error, msg -- replace with raise socket.error(msg) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-02-11 15:14 Message: Logged In: YES user_id=44345 Originator: NO Jeez, I can be an idiot sometimes... Working on two patches in the same sandbox. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-02-11 15:11 Message: Logged In: YES user_id=44345 Originator: NO *argh* one minor tweak too many... File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-02-11 13:24 Message: Logged In: YES user_id=44345 Originator: NO New patch with minor tweaks. Added doc changes. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2007-02-10 15:57 Message: Logged In: YES user_id=44345 Originator: NO Here's an updated patch. Tests pass. There's no documentation for socket.NetworkConnection or for the API changes to smtplib, httplib, telnetlib, poplib or ftplib. File Added: timeout.diff ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-14 13:09 Message: Logged In: YES user_id=21627 mattruss, are you interested in forward-porting it to 2.5? If that gets done before the beta release, please assign it to me for review. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-10-01 00:39 Message: Logged In: YES user_id=29957 Just a quick note - this patch might be accepted for 2.5, but it's not suitable for 2.4.x - once a major release is done, subsequent minor releases (2.3.x, 2.4.x) are bugfix-only. No new features are acceptable. For more on this, see http://www.python.org/peps/pep-0006.html ---------------------------------------------------------------------- Comment By: zeidler (zeidler) Date: 2005-09-28 11:22 Message: Logged In: YES user_id=1082576 perhaps to add a little emphasis: i'd really like to see that patch included into one of the next releases too. i was just going to submit my own, much much simpler version of adding a socket timeout in httplib.py, but matt's patch is a much better way to do this... we're using xml-rpc a lot over here, and the default timeouts are just way too long to keep up a decent user interaction in case of server problems. so, we'd really appreciate this becoming part of the distro! ;) thanks & good job matt, andi ---------------------------------------------------------------------- Comment By: Gr?goire Weber (gregweb) Date: 2005-01-12 10:52 Message: Logged In: YES user_id=812601 Just lobbying: It would be nice to have that on board in futire python versions. Would this be possible in python 2.4.1? I need timeouts for xmlrpclib and subclassed xmlrpclib.Transport for my needs. But nevertheless it would be nice to have that in python 2.4.1. Thanks! Gregoire ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-20 20:20 Message: Logged In: YES user_id=737261 Errata: i forgot to mention urlllib2 as modules affected. the line above starting "The modules that use sockets are: " should really read: "classes in the modules stated below would benifit from the ability pass timeouts:" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=723312&group_id=5470 From noreply at sourceforge.net Fri Mar 30 06:15:07 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 21:15:07 -0700 Subject: [Patches] [ python-Patches-1691032 ] Migrate test_minidom.py to unittest Message-ID: Patches item #1691032, was opened at 2007-03-30 00:15 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=1691032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Migrate test_minidom.py to unittest Initial Comment: Update Lib/test/test_minidom.py to use the unittest module. Also: I noticed the test_minidom.py contains some code (now long dead) to check for reference cycles. The code is active only when Node.allnodes exists; this hasn't existed for over four years now. After re-implementing that test using gc.DEBUG_SAVEALL, I found that many tests failed because of missing unlink() calls. I added them. After that, one test was still failing. This is because expatbuilder.parseString() and friends do not clean up some cyclic references on error. The patch includes a fix for that (in Lib/xml/dom/expatbuilder.py). An alternative would be to ditch the cycle-checking test entirely. I can submit a patch that does that instead, if desired. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1691032&group_id=5470 From noreply at sourceforge.net Fri Mar 30 08:45:53 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 23:45:53 -0700 Subject: [Patches] [ python-Patches-1691070 ] Fix for bug #1283289 Message-ID: Patches item #1691070, was opened at 2007-03-30 01: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=1691070&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for bug #1283289 Initial Comment: This is a fix for [ 1283289 ] PyArg_ParseTupleAndKeywords gives misleading error message. It also yields a 10-15% decrease in cpu usage, depending on the number of arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1691070&group_id=5470 From noreply at sourceforge.net Fri Mar 30 08:49:32 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 29 Mar 2007 23:49:32 -0700 Subject: [Patches] [ python-Patches-1691032 ] Migrate test_minidom.py to unittest Message-ID: Patches item #1691032, was opened at 2007-03-30 00:15 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1691032&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: Migrate test_minidom.py to unittest Initial Comment: Update Lib/test/test_minidom.py to use the unittest module. Also: I noticed the test_minidom.py contains some code (now long dead) to check for reference cycles. The code is active only when Node.allnodes exists; this hasn't existed for over four years now. After re-implementing that test using gc.DEBUG_SAVEALL, I found that many tests failed because of missing unlink() calls. I added them. After that, one test was still failing. This is because expatbuilder.parseString() and friends do not clean up some cyclic references on error. The patch includes a fix for that (in Lib/xml/dom/expatbuilder.py). An alternative would be to ditch the cycle-checking test entirely. I can submit a patch that does that instead, if desired. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2007-03-30 02:49 Message: Logged In: YES user_id=1344176 Originator: NO test_minidom already uses unittest (as of patch #1683397, SVN r54603). Could you update your patch to the latest trunk revision? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1691032&group_id=5470 From noreply at sourceforge.net Sat Mar 31 03:22:20 2007 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Mar 2007 18:22:20 -0700 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 13:28 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- >Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 22:22 Message: Logged In: YES user_id=752496 Originator: NO Changes seems Ok, but I'd need an update to test suite to accept this patch. Can you provide the patch to test cases? Regards, ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-03-11 15:46 Message: Logged In: YES user_id=939860 modifying the version this applies to from 2.3 to 2.4 to reflect the new patch ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-03-09 15:55 Message: Logged In: YES user_id=939860 I have recreated the patch againt the 2.4 snapshot of 20040308. I also included the doc change and made TLSv1 the default. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-07 05:06 Message: Logged In: YES user_id=21627 Ok. Your patch is inapplicable to 2.3, anyway, as it adds a new feature. Are you willing to revise your patch accordingly? Please also include patches to the documentation. ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-06 13:00 Message: Logged In: YES user_id=939860 I think in 2.3.x I would leave it as SSLv23 in order to not break things going from .x to .y. I think it would be reasonable to make TLS the default in the 2.4 branch though as some breakage is moreaceptable to more people when going between bigger releases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 19:37 Message: Logged In: YES user_id=21627 Would be reasonable to change the default to TLS? ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 13:30 Message: Logged In: YES user_id=939860 one last try to have all the files uploaded to the patch ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 13:29 Message: Logged In: YES user_id=939860 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470