From noreply at sourceforge.net Thu Jan 1 02:31:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:31:54 2004 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Replace backticks with repr() Initial Comment: This patch removes most used of backticks in the standard library and replaces them with a call to repr() or uses '%r' in format string. I didn't touch the email package, the lib-old directory or test_grammar.py. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:31 Message: Logged In: YES user_id=80475 Any progress on getting this reviewed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 17:59 Message: Logged In: YES user_id=89016 Updated the patch so that the test suite works again (except for test_doctest.py) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 16:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:33:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:33:24 2004 Subject: [Patches] [ python-Patches-826074 ] cmath.log optional base argument, fixes #823209 Message-ID: Patches item #826074, was opened at 2003-10-18 13:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=826074&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) >Assigned to: Tim Peters (tim_one) Summary: cmath.log optional base argument, fixes #823209 Initial Comment: Fixes bug #823209. math.log allows an optional base argument, add the same functionality to cmath.log. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:33 Message: Logged In: YES user_id=80475 Tim, should this be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=826074&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:40:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:40:14 2004 Subject: [Patches] [ python-Patches-767600 ] Add a 'isotime' format to standard logging Message-ID: Patches item #767600, was opened at 2003-07-08 03:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=767600&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Vinay Sajip (vsajip) Summary: Add a 'isotime' format to standard logging Initial Comment: This patch adds a standard format string 'isotime' to go alongside 'asctime' in the standard logging module. The 'asctime' format is somewhat idiosyncratic (for instance the seconds,milliseconds part). 'isotime' produces UTC timestamps in ISO8601 format, that is %Y-%m-%dT%H:%M:%S.msecsZ e.g. 2003-07-08T18:02:34.012Z A good primer on ISO 8601 can be found at http://www.cl.cam.ac.uk/~mgk25/iso-time.html I'm not entirely sold on the name 'isotime' - an alternative would be 'stdtime'. ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-07-13 18:25 Message: Logged In: YES user_id=308438 The current implementation is supposed to produce ISO8601 format by default, unless a specific date format is specified for the formatter. According to the above web page, the only way in which the current default format is non-standard is that no 'Z' is provided to indicate a UTC time; so I think the patch should not introduce a new 'stdtime' or 'isotime' format, but rather change the current formatting implementation so that the standard format is actually produced. Currently, the millisecond separator is a comma (like log4j); Markus Kuhn's above page indicates that either a comma or a period are acceptable for this. Of course, it may be that better support for standard date/time formats should not be implemented in logging, but in a general-purpose package which can be used not only by logging, but by other applications which need this functionality. Anthony, nice to see that you are taking another look at logging :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-08 03:35 Message: Logged In: YES user_id=21627 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=767600&group_id=5470 From noreply at sourceforge.net Thu Jan 1 02:49:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 02:49:14 2004 Subject: [Patches] [ python-Patches-866594 ] heapq: A way to change the compare function Message-ID: Patches item #866594, was opened at 2003-12-28 12:06 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Raymond Hettinger (rhettinger) Summary: heapq: A way to change the compare function Initial Comment: It'd be nice if heapq could use a custom compare function. This way the user won't need to write a class with <= method. I've added set_cmp(cmp=None) for setting the comparision function. Using cmp and not expliclty <= makes later changes in implementation easier. Attached are the diffs. BTW: I know in CVS heapq is a C module now, don't have the time to change my patch... Miki ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2004-01-01 09:49 Message: Logged In: YES user_id=358087 Also just giving a "lambda" is much shorter than writing a class with __cmp__ which only servers for comparison. I agree that this is a lame patch but in the current design of heapq (using build-in lists) the only other solution I see is to add another "compare" parameter to the module's functions (e.g. def heappop(heap, compare=None): ...). If this is acceptable I'll submit a patch. The other way is to create a new heap object which will be a subclass of list and will have a "compare" property. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 00:54 Message: Logged In: YES user_id=80475 There is no shortage of use cases -- sometimes top priorities have higher numbers -- the use cases are basically the same as those for descending sorts. The proposed solution must be rejected because the global variable would be shared among all modules using heapq. It is possible the one module relies on __le__ while other modules might prefer __ge__. Those modules could be used at the same time. If a non-global solution is found, please re-submit. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-29 16:53 Message: Logged In: YES user_id=99874 Can you explain better the motivation for adding this? I don't find writing __le__() to be a significant problem normally, and setting the global _le seems a less-than-perfect design. What is a use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866594&group_id=5470 From noreply at sourceforge.net Thu Jan 1 03:00:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 03:00:17 2004 Subject: [Patches] [ python-Patches-849252 ] Small error in test_format Message-ID: Patches item #849252, was opened at 2003-11-25 15:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849252&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kalle Svensson (krftkndl) Assigned to: Nobody/Anonymous (nobody) Summary: Small error in test_format Initial Comment: There is an off-by-one bug in test_format, which causes a test that's supposed to run only on 32-bit machines to be skipped everywhere. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 03:00 Message: Logged In: YES user_id=80475 Looks like this was applied to 2.3.3 already. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-29 18:56 Message: Logged In: YES user_id=6380 Thanks, fixed in CVS. (I'm leaving this open since somebody might want to backport the fix to 2.3.3.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849252&group_id=5470 From noreply at sourceforge.net Thu Jan 1 03:54:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 03:54:53 2004 Subject: [Patches] [ python-Patches-868736 ] Add GC collection to timeit Message-ID: Patches item #868736, was opened at 2004-01-01 03: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=868736&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Guido van Rossum (gvanrossum) Summary: Add GC collection to timeit Initial Comment: This patch adds a gc.collect() before each timing. Since timings are only relevant when compared to other timings, it makes sense to put them on as equal footing as possible. Running a gc.collect() before each timing provides some assurance that a routine gc collection won't throw-off one timing while not affecting another. At worst, this patch does nothing. At best, it makes the timings more comparable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 From noreply at sourceforge.net Thu Jan 1 11:17:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 11:17:10 2004 Subject: [Patches] [ python-Patches-868736 ] Add GC collection to timeit Message-ID: Patches item #868736, was opened at 2004-01-01 03:54 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add GC collection to timeit Initial Comment: This patch adds a gc.collect() before each timing. Since timings are only relevant when compared to other timings, it makes sense to put them on as equal footing as possible. Running a gc.collect() before each timing provides some assurance that a routine gc collection won't throw-off one timing while not affecting another. At worst, this patch does nothing. At best, it makes the timings more comparable. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-01 11:17 Message: Logged In: YES user_id=6380 Good idea. (I don't remember -- is it still possible to build Python without gc? If it is, the gc import and use should be conditional. But I vaguely remember it's no longer optional.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 From noreply at sourceforge.net Thu Jan 1 11:48:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 11:48:55 2004 Subject: [Patches] [ python-Patches-868736 ] Add GC collection to timeit Message-ID: Patches item #868736, was opened at 2004-01-01 03:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add GC collection to timeit Initial Comment: This patch adds a gc.collect() before each timing. Since timings are only relevant when compared to other timings, it makes sense to put them on as equal footing as possible. Running a gc.collect() before each timing provides some assurance that a routine gc collection won't throw-off one timing while not affecting another. At worst, this patch does nothing. At best, it makes the timings more comparable. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-01 11:48 Message: Logged In: YES user_id=31435 Nope, gc is no longer optional. It may (or may not ...) be better to disable gc than to run it in this context, as running gc will blow the cache (by chasing every container object, and at least visiting every contained object, in existence). That effect is much worse than just letting gc run naturally (forcing collection chews through all generations; letting it run naturally usually just looks at the youngest generation). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-01 11:17 Message: Logged In: YES user_id=6380 Good idea. (I don't remember -- is it still possible to build Python without gc? If it is, the gc import and use should be conditional. But I vaguely remember it's no longer optional.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 From noreply at sourceforge.net Thu Jan 1 12:23:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 1 12:23:18 2004 Subject: [Patches] [ python-Patches-868736 ] Add GC collection to timeit Message-ID: Patches item #868736, was opened at 2004-01-01 03:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add GC collection to timeit Initial Comment: This patch adds a gc.collect() before each timing. Since timings are only relevant when compared to other timings, it makes sense to put them on as equal footing as possible. Running a gc.collect() before each timing provides some assurance that a routine gc collection won't throw-off one timing while not affecting another. At worst, this patch does nothing. At best, it makes the timings more comparable. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 12:23 Message: Logged In: YES user_id=80475 Blowing the cache is desirable because it puts each timing on the same footing. Note, the gc.collect() goes before the %setup statements which will leave their data in the cache, and the inner loop quickly establishes its own cache access pattern. IOW, the cache will only contain information relevant to the test and not reflect the state of the system just prior to the test. Trying it out a few times shows more consistent timings (or it could just be my imagination). I have a suite of timings for the set module, and even with this patch, the timings still show some sensitivity to the order the tests are run. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-01 11:48 Message: Logged In: YES user_id=31435 Nope, gc is no longer optional. It may (or may not ...) be better to disable gc than to run it in this context, as running gc will blow the cache (by chasing every container object, and at least visiting every contained object, in existence). That effect is much worse than just letting gc run naturally (forcing collection chews through all generations; letting it run naturally usually just looks at the youngest generation). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-01 11:17 Message: Logged In: YES user_id=6380 Good idea. (I don't remember -- is it still possible to build Python without gc? If it is, the gc import and use should be conditional. But I vaguely remember it's no longer optional.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 From noreply at sourceforge.net Fri Jan 2 00:36:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 2 00:36:36 2004 Subject: [Patches] [ python-Patches-826074 ] cmath.log optional base argument, fixes #823209 Message-ID: Patches item #826074, was opened at 2003-10-18 14:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=826074&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Gaul (gaul) >Assigned to: Raymond Hettinger (rhettinger) Summary: cmath.log optional base argument, fixes #823209 Initial Comment: Fixes bug #823209. math.log allows an optional base argument, add the same functionality to cmath.log. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-02 00:36 Message: Logged In: YES user_id=31435 I don't really care. I see the referenced bug report had a marginal use case; OTOH, I can't afford the time to analyze this for numeric quality and robustness (but almost all of cmathmodule is in the same boat wrt that, so that's not much of an argument against it). The patch needs new tests and doc changes, of course. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 02:33 Message: Logged In: YES user_id=80475 Tim, should this be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=826074&group_id=5470 From noreply at sourceforge.net Fri Jan 2 13:22:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 2 13:22:24 2004 Subject: [Patches] [ python-Patches-869468 ] Allow use of embedded Tcl without requiring Tk Message-ID: Patches item #869468, was opened at 2004-01-02 18: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=869468&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Ascher (david_ascher) Assigned to: Martin v. L?wis (loewis) Summary: Allow use of embedded Tcl without requiring Tk Initial Comment: Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 From noreply at sourceforge.net Fri Jan 2 15:36:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 2 15:36:48 2004 Subject: [Patches] [ python-Patches-869555 ] Building on Mac OS X 10.1 Message-ID: Patches item #869555, was opened at 2004-01-02 21:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: Building on Mac OS X 10.1 Initial Comment: This patch contains two changes to allow building on MacOS X 10.1 1) A change to macosmodule.c that only enables the code using 'CGMainDisplayID' on MacOS X 10.2 and later, the function is not available on 10.1 2) Some conditional code in Mac/OSX/Makefile that chooses pbxbuild or xcodebuild depending on which one is on the system (prefering xcodebuild). I have barely tested these changes, they seem to work well enough on 10.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869555&group_id=5470 From noreply at sourceforge.net Fri Jan 2 20:45:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 2 20:45:29 2004 Subject: [Patches] [ python-Patches-869688 ] Add start and end optional args to array.index Message-ID: Patches item #869688, was opened at 2004-01-02 17: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=869688&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Add start and end optional args to array.index Initial Comment: array.index should accept optional start and end args, like string.index and list.index. This patch adds this capability to the code, the test, and the documentation. I basically copied the code from list.index. This is my first Python patch. The submission guidelines suggested bundling the code, test, and doc patches together, so I did, even though there are separate Category entries for each of these. If I should have submitted them separately, please let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869688&group_id=5470 From noreply at sourceforge.net Sat Jan 3 06:21:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 06:21:27 2004 Subject: [Patches] [ python-Patches-868496 ] base64.py support for RFC 3548 Message-ID: Patches item #868496, was opened at 2003-12-31 17:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Tim Peters (tim_one) Summary: base64.py support for RFC 3548 Initial Comment: I needed more complete RFC 3548 support, so I hacked up the base64.py module. Here's the patch and an updated test suite. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 12:21 Message: Logged In: YES user_id=21627 Where does the Freenet encoding come from? Do we need that? Performance of the algorithms can probably be improved. For example, for base32 - _b32table should be a list (or tuple), not a dictionary: _b32table = tuple([_b32table[i] for i in range(32)]) - first hexlifying the string on encoding seems wasteful; use struct instead def f2(chunk): c1, c2, c3 = struct.unpack("!HHB", chunk) c2 += (c1 & 1) << 16 # total 17 bits c3 += (c2 & 3) << 8 # total 10 bits parts = [_b32table[c1 >> 11], _b32table[(c1 >> 6) & 31], _b32table[(c1>>1) & 31], _b32table[c2 >> 12], _b32table[(c2 >> 7) & 31], _b32table[(c2 >> 2) & 31], _b32table[c3 >> 5], _b32table[c3 & 31]] return ''.join(parts) Apart from that, the change looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 From noreply at sourceforge.net Sat Jan 3 06:58:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 06:58:54 2004 Subject: [Patches] [ python-Patches-869468 ] Allow use of embedded Tcl without requiring Tk Message-ID: Patches item #869468, was opened at 2004-01-02 19:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Ascher (david_ascher) >Assigned to: David Ascher (david_ascher) Summary: Allow use of embedded Tcl without requiring Tk Initial Comment: Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 12:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. As for documentation: it has been custom to just document the changes (and perhaps write the bare minimum of structure to add the changes) to lib/tkinter.tex. I see no problem with some features being documented and others not - over time, documentation will complete if we continue with this custom. I wonder whether the loading of Tk can be simplified as evaluating "package require Tk" instead of calling Tk_Init(); I don't know what the difference between these two is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 From noreply at sourceforge.net Sat Jan 3 14:55:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 14:55:29 2004 Subject: [Patches] [ python-Patches-868496 ] base64.py support for RFC 3548 Message-ID: Patches item #868496, was opened at 2003-12-31 11:34 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Tim Peters (tim_one) Summary: base64.py support for RFC 3548 Initial Comment: I needed more complete RFC 3548 support, so I hacked up the base64.py module. Here's the patch and an updated test suite. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-03 14:55 Message: Logged In: YES user_id=12800 Freenet alphabet is mentioned in the thread referenced by footnote [8] in the RFC. Thanks for the other suggestions. I'll work with those and unless there are any other objections, I'll commit these changes soon. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 06:21 Message: Logged In: YES user_id=21627 Where does the Freenet encoding come from? Do we need that? Performance of the algorithms can probably be improved. For example, for base32 - _b32table should be a list (or tuple), not a dictionary: _b32table = tuple([_b32table[i] for i in range(32)]) - first hexlifying the string on encoding seems wasteful; use struct instead def f2(chunk): c1, c2, c3 = struct.unpack("!HHB", chunk) c2 += (c1 & 1) << 16 # total 17 bits c3 += (c2 & 3) << 8 # total 10 bits parts = [_b32table[c1 >> 11], _b32table[(c1 >> 6) & 31], _b32table[(c1>>1) & 31], _b32table[c2 >> 12], _b32table[(c2 >> 7) & 31], _b32table[(c2 >> 2) & 31], _b32table[c3 >> 5], _b32table[c3 & 31]] return ''.join(parts) Apart from that, the change looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 From noreply at sourceforge.net Sat Jan 3 14:58:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 14:58:58 2004 Subject: [Patches] [ python-Patches-868496 ] base64.py support for RFC 3548 Message-ID: Patches item #868496, was opened at 2003-12-31 11:34 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: base64.py support for RFC 3548 Initial Comment: I needed more complete RFC 3548 support, so I hacked up the base64.py module. Here's the patch and an updated test suite. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-03 14:55 Message: Logged In: YES user_id=12800 Freenet alphabet is mentioned in the thread referenced by footnote [8] in the RFC. Thanks for the other suggestions. I'll work with those and unless there are any other objections, I'll commit these changes soon. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 06:21 Message: Logged In: YES user_id=21627 Where does the Freenet encoding come from? Do we need that? Performance of the algorithms can probably be improved. For example, for base32 - _b32table should be a list (or tuple), not a dictionary: _b32table = tuple([_b32table[i] for i in range(32)]) - first hexlifying the string on encoding seems wasteful; use struct instead def f2(chunk): c1, c2, c3 = struct.unpack("!HHB", chunk) c2 += (c1 & 1) << 16 # total 17 bits c3 += (c2 & 3) << 8 # total 10 bits parts = [_b32table[c1 >> 11], _b32table[(c1 >> 6) & 31], _b32table[(c1>>1) & 31], _b32table[c2 >> 12], _b32table[(c2 >> 7) & 31], _b32table[(c2 >> 2) & 31], _b32table[c3 >> 5], _b32table[c3 & 31]] return ''.join(parts) Apart from that, the change looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 From noreply at sourceforge.net Sat Jan 3 18:30:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 18:30:30 2004 Subject: [Patches] [ python-Patches-868496 ] base64.py support for RFC 3548 Message-ID: Patches item #868496, was opened at 2003-12-31 11:34 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: base64.py support for RFC 3548 Initial Comment: I needed more complete RFC 3548 support, so I hacked up the base64.py module. Here's the patch and an updated test suite. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-03 18:30 Message: Logged In: YES user_id=31435 Don't worry about speed -- if necessary, we can speed it after it's been checked in. I found the b32decode map01=False argument confusing. Maybe because the default was named False, I assumed the only other sensible value for it would be True. Maybe just changing the default to None would be clearer. b16decode internals should not allow the input string to contain '=' characters, since base 16 encoding doesn't use a pad character. I assume you'll add suitable doc changes. Just for fun, I'd like to see the docs claim that base64 and base32 encoding are cryptographically secure, unless the map01 argument is set to 'L' . ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-03 14:55 Message: Logged In: YES user_id=12800 Freenet alphabet is mentioned in the thread referenced by footnote [8] in the RFC. Thanks for the other suggestions. I'll work with those and unless there are any other objections, I'll commit these changes soon. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 06:21 Message: Logged In: YES user_id=21627 Where does the Freenet encoding come from? Do we need that? Performance of the algorithms can probably be improved. For example, for base32 - _b32table should be a list (or tuple), not a dictionary: _b32table = tuple([_b32table[i] for i in range(32)]) - first hexlifying the string on encoding seems wasteful; use struct instead def f2(chunk): c1, c2, c3 = struct.unpack("!HHB", chunk) c2 += (c1 & 1) << 16 # total 17 bits c3 += (c2 & 3) << 8 # total 10 bits parts = [_b32table[c1 >> 11], _b32table[(c1 >> 6) & 31], _b32table[(c1>>1) & 31], _b32table[c2 >> 12], _b32table[(c2 >> 7) & 31], _b32table[(c2 >> 2) & 31], _b32table[c3 >> 5], _b32table[c3 & 31]] return ''.join(parts) Apart from that, the change looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 From noreply at sourceforge.net Sat Jan 3 19:59:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 20:00:02 2004 Subject: [Patches] [ python-Patches-868496 ] base64.py support for RFC 3548 Message-ID: Patches item #868496, was opened at 2003-12-31 11:34 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: base64.py support for RFC 3548 Initial Comment: I needed more complete RFC 3548 support, so I hacked up the base64.py module. Here's the patch and an updated test suite. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-03 19:59 Message: Logged In: YES user_id=12800 Thanks Tim, I'll change the default for map01 and fix b16decode. I'll leave additional claims of cryptographic security to the upcoming report by the PSF's CSO . I'm also removing the freenet_* methods. Updating docs, test cases, and checking in. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-03 18:30 Message: Logged In: YES user_id=31435 Don't worry about speed -- if necessary, we can speed it after it's been checked in. I found the b32decode map01=False argument confusing. Maybe because the default was named False, I assumed the only other sensible value for it would be True. Maybe just changing the default to None would be clearer. b16decode internals should not allow the input string to contain '=' characters, since base 16 encoding doesn't use a pad character. I assume you'll add suitable doc changes. Just for fun, I'd like to see the docs claim that base64 and base32 encoding are cryptographically secure, unless the map01 argument is set to 'L' . ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-03 14:55 Message: Logged In: YES user_id=12800 Freenet alphabet is mentioned in the thread referenced by footnote [8] in the RFC. Thanks for the other suggestions. I'll work with those and unless there are any other objections, I'll commit these changes soon. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 06:21 Message: Logged In: YES user_id=21627 Where does the Freenet encoding come from? Do we need that? Performance of the algorithms can probably be improved. For example, for base32 - _b32table should be a list (or tuple), not a dictionary: _b32table = tuple([_b32table[i] for i in range(32)]) - first hexlifying the string on encoding seems wasteful; use struct instead def f2(chunk): c1, c2, c3 = struct.unpack("!HHB", chunk) c2 += (c1 & 1) << 16 # total 17 bits c3 += (c2 & 3) << 8 # total 10 bits parts = [_b32table[c1 >> 11], _b32table[(c1 >> 6) & 31], _b32table[(c1>>1) & 31], _b32table[c2 >> 12], _b32table[(c2 >> 7) & 31], _b32table[(c2 >> 2) & 31], _b32table[c3 >> 5], _b32table[c3 & 31]] return ''.join(parts) Apart from that, the change looks good. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470 From noreply at sourceforge.net Sat Jan 3 22:49:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 3 22:49:13 2004 Subject: [Patches] [ python-Patches-868736 ] Add GC collection to timeit Message-ID: Patches item #868736, was opened at 2004-01-01 03:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Raymond Hettinger (rhettinger) Summary: Add GC collection to timeit Initial Comment: This patch adds a gc.collect() before each timing. Since timings are only relevant when compared to other timings, it makes sense to put them on as equal footing as possible. Running a gc.collect() before each timing provides some assurance that a routine gc collection won't throw-off one timing while not affecting another. At worst, this patch does nothing. At best, it makes the timings more comparable. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-03 22:49 Message: Logged In: YES user_id=80475 Applied Tim's more conservative approach to Lib/timeit.py 1.16. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 12:23 Message: Logged In: YES user_id=80475 Blowing the cache is desirable because it puts each timing on the same footing. Note, the gc.collect() goes before the %setup statements which will leave their data in the cache, and the inner loop quickly establishes its own cache access pattern. IOW, the cache will only contain information relevant to the test and not reflect the state of the system just prior to the test. Trying it out a few times shows more consistent timings (or it could just be my imagination). I have a suite of timings for the set module, and even with this patch, the timings still show some sensitivity to the order the tests are run. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-01 11:48 Message: Logged In: YES user_id=31435 Nope, gc is no longer optional. It may (or may not ...) be better to disable gc than to run it in this context, as running gc will blow the cache (by chasing every container object, and at least visiting every contained object, in existence). That effect is much worse than just letting gc run naturally (forcing collection chews through all generations; letting it run naturally usually just looks at the youngest generation). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-01 11:17 Message: Logged In: YES user_id=6380 Good idea. (I don't remember -- is it still possible to build Python without gc? If it is, the gc import and use should be conditional. But I vaguely remember it's no longer optional.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868736&group_id=5470 From noreply at sourceforge.net Sun Jan 4 04:18:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 04:18:56 2004 Subject: [Patches] [ python-Patches-870286 ] make Demo/scripts/primes.py usable as a module Message-ID: Patches item #870286, was opened at 2004-01-04 10: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=870286&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: make Demo/scripts/primes.py usable as a module Initial Comment: I wanted to find all primes between 1985 and 2005, and found out that Demo/scripts/primes.py is not usable as a module, because it unconditionally executes main(). This patch adds a 'if __name__ == "__main__"' block around the execution of the main() function, so that one can simply import primes and use primes.primes(1985, 2005) in order to achieve what I wanted to achieve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470 From noreply at sourceforge.net Sun Jan 4 04:22:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 04:22:42 2004 Subject: [Patches] [ python-Patches-870287 ] Fix docstring for posixpath.getctime Message-ID: Patches item #870287, was opened at 2004-01-04 10: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=870287&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docstring for posixpath.getctime Initial Comment: (not sure whether this is "Library" or "Documentation") The docstring of posixpath.getctime calls ctime the "creation time". This is incorrect, because it is the "change time". The library documentation is correct here. This patch fixes the docstring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 From noreply at sourceforge.net Sun Jan 4 12:21:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 12:21:26 2004 Subject: [Patches] [ python-Patches-869468 ] Allow use of embedded Tcl without requiring Tk Message-ID: Patches item #869468, was opened at 2004-01-02 12:22 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Ascher (david_ascher) Assigned to: David Ascher (david_ascher) Summary: Allow use of embedded Tcl without requiring Tk Initial Comment: Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-01-04 11:21 Message: Logged In: YES user_id=2772 I think that "package require Tk" is commonly broken. It is on RedHat 9 and Fedora Core 1. [jepler@parrot]$ tclsh % package require Tk can't find package Tk ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-03 05:58 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. As for documentation: it has been custom to just document the changes (and perhaps write the bare minimum of structure to add the changes) to lib/tkinter.tex. I see no problem with some features being documented and others not - over time, documentation will complete if we continue with this custom. I wonder whether the loading of Tk can be simplified as evaluating "package require Tk" instead of calling Tk_Init(); I don't know what the difference between these two is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=869468&group_id=5470 From noreply at sourceforge.net Sun Jan 4 14:56:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 14:56:33 2004 Subject: [Patches] [ python-Patches-870500 ] Error in PEP 320: list.sorted -> sorted Message-ID: Patches item #870500, was opened at 2004-01-04 20:56 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=870500&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Error in PEP 320: list.sorted -> sorted Initial Comment: PEP 320 says a new classmethod called list.sorted was added, but this is a builtin called sorted (don't know the Category, there is None ;). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870500&group_id=5470 From noreply at sourceforge.net Sun Jan 4 18:48:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 18:48:16 2004 Subject: [Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows Message-ID: Patches item #870606, was opened at 2004-01-04 23: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=870606&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: make test_urllib2 work on Windows Initial Comment: This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 From noreply at sourceforge.net Sun Jan 4 18:51:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 18:52:00 2004 Subject: [Patches] [ python-Patches-852995 ] tests and processors patch for urllib2 Message-ID: Patches item #852995, was opened at 2003-12-03 00:53 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: tests and processors patch for urllib2 Initial Comment: Here are some unit tests for urllib2 and a revised version of my urllib2 "processors" patch (originally posted as RFE 759792 -- I'm posting it here since it is a patch, not just a wish). The tests depend on the patch, but test more than just the changes introduced by the patch. A fuller discussion is in the original RFE tracker item, but briefly: the patch makes it possible to implement functionality like HTTP cookie handling, Refresh handling, etc. etc. using handler objects. At the moment urllib2's handler objects aren't quite up to the job, which results in a lot of cut-n-paste and subclassing. I believe the changes are backwards-compatible, with the exception of people who've reimplemented build_opener()'s functionality -- those people would need to call opener.add_handler(HTTPErrorProcessor). The main change is allowing handlers to implement methods like: http_request(request) http_response(request, response) In addition to the usual http_open(request) http_error{_*}(...) I call handlers that implement these methods "processors". These methods get called for *every* processor (in contrast to the ordinary handler methods, where the OpenerDirector stops calling the methods as soon as the first handler handles the request by returning a response) to pre-process requests and post-process responses. If this is accepted, I can submit patches for handlers (processors) that do HTTP Refresh redirection, cookie handling etc. Changes in the patch: -OpenerDirector changes to call new _request and _response methods. I haven't put all the documentation for this interface in this set of patches because there's no obvious place for it: handlers aren't really documented either. The urllib2 docs need a cleanup, but I'll do that in a separate patch. -Added .unredirected_hdrs dict to Request, together with .add_unredirected_headers() and .has_header() methods. These headers don't get copied to redirected requests. I didn't add this as a feature for people calling urlopen on a Request. Rather, the motivation comes from the fact that processors need to explicitly add headers to Requests (Cookie, Referer, Content-Length, etc.), rather than directly sending them over the wire. The problem is, if they add them to the regular .headers attribute of requests, processors will end up clobbering headers added by the user who called urlopen (which would break backwards-compatibility). Having processors use a separate set of headers that never get redirected makes this problem go away: users can add headers (with either .add_header() or .add_unredirected_header(), since processors don't clobber either) and know that they won't get clobbered by any handler. -HTTPErrorProcessor is necessary to allow response processors to see responses before redirections &c happen, by moving the call to parent.error() out of AbstractHTTPHandler.do_open(). It has the side-effect of stopping people grumbling that 200 is not the only success code in HTTP <0.5 wink>, since it makes it feasible to override urllib2's behaviour of raising an exception unless the HTTP code == 200. -Split part of AbstractHTTPHandler.do_open (which implements http_open / https_open in the HTTP/HTTPSHandler subclasses) into a new .do_request (which implements http_request in the subclasses). Just because I could, really (with the new *_request methods). It seems clearer to me. -Single string-formatting-character change to OpenerDirector.error() to allow "refresh" as an error code. -Added .code and .msg attributes to HTTP response objects, so that processors can know what the response code and message are. I haven't documented these, because they're HTTP-specific. -Renamed HTTPRedirectHandler.error_302_dict --> .redirect_dict -Finally, there's one bugfix to HTTPRedirectHandler included in the patch, because the tests test for it: multiple visits to a single URL with different redirect codes is no longer erroneously detected as a loop. http://a.com/a --> 302 --> http://a.com/b --> Refresh --> http://a.com/a Yes, I have seen a site where this really happens! There are a few other bugs that turned up while writing the tests, and those tests are commented out ATM. I'll file bug reports for those separately after this one is sorted out. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2004-01-04 23:51 Message: Logged In: YES user_id=261020 Fixed tests in patch 870606. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 04:00 Message: Logged In: YES user_id=80475 FWIW, the test for urllib2 is currently failing and needs to be fixed. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 16:11 Message: Logged In: YES user_id=261020 Reopening to add a note to Misc/NEWS about the backwards-incompatibility for people who don't use build_opener(). I presume that's the right place for this note? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-14 15:17 Message: Logged In: YES user_id=261020 Just a note that my justification of Request.add_unredirected_hdrs above makes no sense. :-/ I mis-remembered my own reasons for adding this. My original comment from 759792 is correct: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-12-14 05:28 Message: Logged In: YES user_id=31392 Committed as rev 1.57 of urllib2.py ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-08 00:04 Message: Logged In: YES user_id=261020 Oops, I left a couple of lines in urllib2.py that add an HTTP debugging method and constructor arg. Please ignore that part of the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852995&group_id=5470 From noreply at sourceforge.net Sun Jan 4 18:58:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 18:59:01 2004 Subject: [Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows Message-ID: Patches item #870606, was opened at 2004-01-04 18:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: Jeremy Hylton (jhylton) Summary: make test_urllib2 work on Windows Initial Comment: This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-04 18:58 Message: Logged In: YES user_id=31435 I confirm that the patch allows test_urllib2 to pass again on Windows. Assigned to Jeremy, as I made no attempt to try to understand what the patch does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 From noreply at sourceforge.net Sun Jan 4 19:30:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 19:31:00 2004 Subject: [Patches] [ python-Patches-866875 ] str.split optimization for one character separaters Message-ID: Patches item #866875, was opened at 2003-12-29 12:21 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866875&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: str.split optimization for one character separaters Initial Comment: Attached patch tries to optimize str.split by a speciaiized splitter for one character separacters. This trick is used for unicode.split too. I just applied it to str.split. :) quick perf. test: - BEFORE - % ./python Lib/timeit.py '"/aaa/bbb/ccc/ddd/eee/fff/ggg/hhh/iii".split("/")' 100000 loops, best of 3: 7.84 usec per loop - AFTER - % ./python Lib/timeit.py '"/aaa/bbb/ccc/ddd/eee/fff/ggg/hhh/iii".split("/")' 100000 loops, best of 3: 5.39 usec per loop ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-05 09:30 Message: Logged In: YES user_id=55188 Committed as string_tests.py 1.37 and stringobject.c 2.217 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866875&group_id=5470 From noreply at sourceforge.net Sun Jan 4 19:36:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 19:36:50 2004 Subject: [Patches] [ python-Patches-737473 ] traceback module caches sources invalid Message-ID: Patches item #737473, was opened at 2003-05-14 14:44 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 Category: Library (Lib) >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: traceback module caches sources invalid Initial Comment: traceback.{extract,print}_tb function doesn't check source code's mtime validity. attached script copies the bug situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=737473&group_id=5470 From noreply at sourceforge.net Sun Jan 4 19:42:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 19:42:07 2004 Subject: [Patches] [ python-Patches-720585 ] iconv_codec 3rd generation Message-ID: Patches item #720585, was opened at 2003-04-13 20:02 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720585&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: iconv_codec 3rd generation Initial Comment: Full featured and standalone iconv_codec implementation. - Supports UCS, UCS-SWAPPED, UTF-8 unicode encodings with runtime detection. - Supports even _sane_ StreamReader and StreamWriter. Tested on {Free,Net}BSD, Debian Linux, MacOS X, Solaris 9 and Cygwin ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-05 09:42 Message: Logged In: YES user_id=55188 I'll submit CJKCodecs instead of this. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2003-04-13 20:29 Message: Logged In: YES user_id=55188 If the poor libiconv implementations are concerned, how about enabling iconv_codec only on platforms that we can expect sane iconv? - if platform not in ['darwin'] and iconv_incs is not None: + if platform in ['freebsd3', 'freebsd4', 'freebsd5', 'netbsd1', + 'linux2', 'sunos5'] and iconv_incs is not None: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=720585&group_id=5470 From noreply at sourceforge.net Sun Jan 4 23:25:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 23:25:25 2004 Subject: [Patches] [ python-Patches-870693 ] make test___all__ again Message-ID: Patches item #870693, was opened at 2004-01-05 13: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=870693&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: make test___all__ again Initial Comment: test___all__ started to fail 2 days ago for base64's problem. Attached patch may fix the problem. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870693&group_id=5470 From noreply at sourceforge.net Sun Jan 4 23:25:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 4 23:25:59 2004 Subject: [Patches] [ python-Patches-870693 ] make test___all__ work again Message-ID: Patches item #870693, was opened at 2004-01-05 13:25 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870693&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Barry A. Warsaw (bwarsaw) >Summary: make test___all__ work again Initial Comment: test___all__ started to fail 2 days ago for base64's problem. Attached patch may fix the problem. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870693&group_id=5470 From noreply at sourceforge.net Mon Jan 5 05:13:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 5 05:14:05 2004 Subject: [Patches] [ python-Patches-864863 ] Bisect C implementation Message-ID: Patches item #864863, was opened at 2003-12-23 03:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Raymond Hettinger (rhettinger) Summary: Bisect C implementation Initial Comment: Bisect C implementation. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-05 05:13 Message: Logged In: YES user_id=80475 Thanks for the patch. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-12-29 03:18 Message: Logged In: YES user_id=388573 > One idea is to rename it to _bisect and then conditionally > import it into bisect.py. That would preserve the teaching > value of the existing module while providing a good speed-up > for users working with sorted data. Maybe just do 'from _bisect import *' while preserve old code as comment or doc string? > Since this module has been around for a long time, it is likely > that there have been many uncoventential uses. So, it is > important to make sure a replacement can handle all of the > same types of input (any container object defining __len__(), > __getitem__(), and insert(); and member objects defining > __lt__()). I've made new test case for custom container object. One new idea I have is full slice semantic for lo and hi arguments. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-26 11:55 Message: Logged In: YES user_id=80475 I'll take a look at this in a few days. One idea is to rename it to _bisect and then conditionally import it into bisect.py. That would preserve the teaching value of the existing module while providing a good speed-up for users working with sorted data. Since this module has been around for a long time, it is likely that there have been many uncoventential uses. So, it is important to make sure a replacement can handle all of the same types of input (any container object defining __len__(), __getitem__(), and insert(); and member objects defining __lt__()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864863&group_id=5470 From noreply at sourceforge.net Mon Jan 5 05:18:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 5 05:18:23 2004 Subject: [Patches] [ python-Patches-870807 ] optparse int, long types support binary, octal and hex forma Message-ID: Patches item #870807, was opened at 2004-01-05 12: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=870807&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: optparse int, long types support binary, octal and hex forma Initial Comment: Hello, I've added support for binary, octal and hexa number with the "int" and "long" types. binary : 0b10 (= 2) octal : 010 (= 8) hexa: 0x10 (= 16) Diff for optparse.py and test_optparse.py attached. Miki. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870807&group_id=5470 From wedfr at msn.com Mon Jan 5 15:03:18 2004 From: wedfr at msn.com (Ofelia Collier) Date: Mon Jan 5 08:13:04 2004 Subject: [Patches] a Great news today! tvuve trjc Message-ID: <5-0x25qs0u4bf--i95m@xtqu0> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040105/3d6af598/attachment.html From noreply at sourceforge.net Mon Jan 5 21:46:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 5 21:47:03 2004 Subject: [Patches] [ python-Patches-871402 ] add link to DDJ's article Message-ID: Patches item #871402, was opened at 2004-01-06 11:46 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=871402&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add link to DDJ's article Initial Comment: The document of difflib refers to an article published by DDJ. www.python.org/doc/current/lib/module-difflib.html http://www.ddj.com/ "Pattern Matching: The Gestalt Approach" by John W. Ratcliff & D. E. Metzener Luckily, this article is available on DDJ's site, so why not add a link to that URI? # http://www.ddj.com/articles/1988/8807/ # http://www.ddj.com/documents/s=1103/ddj8807c/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 From noreply at sourceforge.net Tue Jan 6 08:40:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 6 08:41:01 2004 Subject: [Patches] [ python-Patches-871657 ] math.sqrt EDOM handling for FreeBSD, OpenBSD Message-ID: Patches item #871657, was opened at 2004-01-06 22: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=871657&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: math.sqrt EDOM handling for FreeBSD, OpenBSD Initial Comment: math.sqrt(-1) doesn't raise ValueError currently. The attached patch may fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871657&group_id=5470 From noreply at sourceforge.net Tue Jan 6 15:04:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 6 15:04:24 2004 Subject: [Patches] [ python-Patches-871896 ] msilib.py EnsureModule does not work Message-ID: Patches item #871896, was opened at 2004-01-06 21:04 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=871896&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: msilib.py EnsureModule does not work Initial Comment: See the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 From noreply at sourceforge.net Tue Jan 6 15:05:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 6 15:05:19 2004 Subject: [Patches] [ python-Patches-871896 ] msilib.py EnsureModule does not work Message-ID: Patches item #871896, was opened at 2004-01-06 21:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: msilib.py EnsureModule does not work Initial Comment: See the patch. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-01-06 21:05 Message: Logged In: YES user_id=11105 I assume the EnsureMSM function needs the same fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 From noreply at sourceforge.net Wed Jan 7 00:18:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 7 00:18:48 2004 Subject: [Patches] [ python-Patches-871896 ] msilib.py EnsureModule does not work Message-ID: Patches item #871896, was opened at 2004-01-06 21:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 Category: None Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: msilib.py EnsureModule does not work Initial Comment: See the patch. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-07 06:18 Message: Logged In: YES user_id=21627 I believe you are right. Fixed in 1.4. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-01-06 21:05 Message: Logged In: YES user_id=11105 I assume the EnsureMSM function needs the same fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 From noreply at sourceforge.net Wed Jan 7 00:23:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 7 00:24:08 2004 Subject: [Patches] [ python-Patches-870500 ] Error in PEP 320: list.sorted -> sorted Message-ID: Patches item #870500, was opened at 2004-01-04 20:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870500&group_id=5470 Category: None Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) >Summary: Error in PEP 320: list.sorted -> sorted Initial Comment: PEP 320 says a new classmethod called list.sorted was added, but this is a builtin called sorted (don't know the Category, there is None ;). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-07 06:23 Message: Logged In: YES user_id=21627 Thanks, applied as 1.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870500&group_id=5470 From noreply at sourceforge.net Wed Jan 7 03:52:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 7 03:52:57 2004 Subject: [Patches] [ python-Patches-871896 ] msilib.py EnsureModule does not work Message-ID: Patches item #871896, was opened at 2004-01-06 21:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 Category: None Group: Python 2.4 Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Martin v. L?wis (loewis) Summary: msilib.py EnsureModule does not work Initial Comment: See the patch. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-01-07 09:52 Message: Logged In: YES user_id=11105 It seems I guessed wrong about the EnsureMSM function. Here's the output of 'makepy -i' on my system: c:\sf\python\nondist\sandbox\msi>py24 \python24\lib\site-packages\win32com\client\makepy.py -i "Microsoft MSM Merge Type Library" Microsoft MSM Merge Type Library {0ADDA82F-2C26-11D2-AD65-00A0C9AF11A6}, lcid=0, major=2, minor=0 >>> # Use these commands in Python code to auto generate .py support >>> from win32com.client import gencache >>> gencache.EnsureModule('{0ADDA82F-2C26-11D2-AD65-00A0C9AF11A6}', 0, 2, 0) c:\sf\python\nondist\sandbox\msi>py24 \python24\lib\site-packages\win32com\client\makepy.py -i "Microsoft Windows Instal ler Object Library" Microsoft Windows Installer Object Library {000C1092-0000-0000-C000-000000000046}, lcid=1033, major=1, minor=0 >>> # Use these commands in Python code to auto generate .py support >>> from win32com.client import gencache >>> gencache.EnsureModule('{000C1092-0000-0000-C000-000000000046}', 1033, 1, 0) c:\sf\python\nondist\sandbox\msi> OTOH, it seems that EnsureMSM is not required to work while EnsureMSI is, because win32com.client.constants does not contain the msi* values. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-07 06:18 Message: Logged In: YES user_id=21627 I believe you are right. Fixed in 1.4. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-01-06 21:05 Message: Logged In: YES user_id=11105 I assume the EnsureMSM function needs the same fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871896&group_id=5470 From noreply at sourceforge.net Wed Jan 7 07:10:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 7 07:10:51 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 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=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Nobody/Anonymous (nobody) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Wed Jan 7 07:25:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 7 07:25:17 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) >Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Wed Jan 7 23:50:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 7 23:51:02 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Thu Jan 8 00:44:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 00:44:42 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Thu Jan 8 13:29:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 13:29:04 2004 Subject: [Patches] [ python-Patches-873224 ] Marshal clean-up Message-ID: Patches item #873224, was opened at 2004-01-08 18: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=873224&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 2 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: Marshal clean-up Initial Comment: Reading random bytes with the marshal module can segfault the interpreter. Moreover, reading a truncated .pyc file can also successfully return a (corrupted) object instead of raising an error. Please review the attached patch if you consider this to be worth fixing. The patch also fixes a minor bug in import.c, which would sometimes write incomplete .pyc files in case of write error (and hence the truncated .pyc file problems could actually show up, in theory). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 From noreply at sourceforge.net Thu Jan 8 13:50:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 13:53:30 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 12:10 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-01-08 18:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 05:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 04:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 12:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Thu Jan 8 13:55:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 13:55:23 2004 Subject: [Patches] [ python-Patches-873224 ] Marshal clean-up Message-ID: Patches item #873224, was opened at 2004-01-08 18:29 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 2 Submitted By: Armin Rigo (arigo) >Assigned to: Michael Hudson (mwh) Summary: Marshal clean-up Initial Comment: Reading random bytes with the marshal module can segfault the interpreter. Moreover, reading a truncated .pyc file can also successfully return a (corrupted) object instead of raising an error. Please review the attached patch if you consider this to be worth fixing. The patch also fixes a minor bug in import.c, which would sometimes write incomplete .pyc files in case of write error (and hence the truncated .pyc file problems could actually show up, in theory). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-01-08 18:55 Message: Logged In: YES user_id=6656 This patch results from my comments on IRC, so I'll take a look at it. Needs testcases! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 From noreply at sourceforge.net Thu Jan 8 14:00:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 14:00:42 2004 Subject: [Patches] [ python-Patches-873224 ] Marshal clean-up Message-ID: Patches item #873224, was opened at 2004-01-08 18:29 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 2 Submitted By: Armin Rigo (arigo) >Assigned to: Nobody/Anonymous (nobody) Summary: Marshal clean-up Initial Comment: Reading random bytes with the marshal module can segfault the interpreter. Moreover, reading a truncated .pyc file can also successfully return a (corrupted) object instead of raising an error. Please review the attached patch if you consider this to be worth fixing. The patch also fixes a minor bug in import.c, which would sometimes write incomplete .pyc files in case of write error (and hence the truncated .pyc file problems could actually show up, in theory). ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-01-08 19:00 Message: Logged In: YES user_id=4771 Test cases: >>> marshal.loads('0') -> SystemError >>> marshal.loads('f') -> segfault >>> marshal.dumps(5L) 'l\x01\x00\x00\x00\x05\x00' >>> marshal.loads(_[:-1]) 65285L ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-08 18:55 Message: Logged In: YES user_id=6656 This patch results from my comments on IRC, so I'll take a look at it. Needs testcases! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 From noreply at sourceforge.net Thu Jan 8 13:07:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 14:01:21 2004 Subject: [Patches] [ python-Patches-873211 ] trace.py: simple bug in write_results_file Message-ID: Patches item #873211, was opened at 2004-01-08 18:07 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=873211&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bruno da Silva de Oliveira (nicoddemus) Assigned to: Nobody/Anonymous (nobody) Summary: trace.py: simple bug in write_results_file Initial Comment: The callers of write_results_file expect it to return a tuple (n_lines, n_hits), but right at the beginning of the function there's an attempt to open the results file, and if that fails it just "return"s, which causes an exception in the callers when they try to unpack the tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873211&group_id=5470 From noreply at sourceforge.net Thu Jan 8 14:03:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 14:03:31 2004 Subject: [Patches] [ python-Patches-873224 ] Marshal clean-up Message-ID: Patches item #873224, was opened at 2004-01-08 18:29 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 2 Submitted By: Armin Rigo (arigo) >Assigned to: Michael Hudson (mwh) Summary: Marshal clean-up Initial Comment: Reading random bytes with the marshal module can segfault the interpreter. Moreover, reading a truncated .pyc file can also successfully return a (corrupted) object instead of raising an error. Please review the attached patch if you consider this to be worth fixing. The patch also fixes a minor bug in import.c, which would sometimes write incomplete .pyc files in case of write error (and hence the truncated .pyc file problems could actually show up, in theory). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-08 19:00 Message: Logged In: YES user_id=4771 Test cases: >>> marshal.loads('0') -> SystemError >>> marshal.loads('f') -> segfault >>> marshal.dumps(5L) 'l\x01\x00\x00\x00\x05\x00' >>> marshal.loads(_[:-1]) 65285L ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-08 18:55 Message: Logged In: YES user_id=6656 This patch results from my comments on IRC, so I'll take a look at it. Needs testcases! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873224&group_id=5470 From noreply at sourceforge.net Thu Jan 8 15:46:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 15:47:00 2004 Subject: [Patches] [ python-Patches-873305 ] list.__setitem__(slice) behavior Message-ID: Patches item #873305, was opened at 2004-01-08 15:46 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=873305&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Brandmeyer (jbrandmeyer) Assigned to: Nobody/Anonymous (nobody) Summary: list.__setitem__(slice) behavior Initial Comment: Consider the following: >>> x = [0, 1, 2, 3, 4] >>> x[-1:0] = [5, 6, 7] Currently the result is that x == [0,1,2,3,5,6,7,4]. However, I believe that calling setitem with an empty slice should be a no-op, rather than performing an insertion starting at the 'begin' index of the slice. The following patch to Objects/listobject.c makes this change. Thanks, Jonathan Brandmeyer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873305&group_id=5470 From noreply at sourceforge.net Thu Jan 8 16:03:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 16:10:19 2004 Subject: [Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows Message-ID: Patches item #870606, was opened at 2004-01-04 18:48 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: make test_urllib2 work on Windows Initial Comment: This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-01-08 16:03 Message: Logged In: YES user_id=764593 Today, a missing host or protocol indicates a relative URL. At one point, it could also have meant file (or ftp) to the localhost. proto://host/path -> file://localhost/path -> //localhost/path -> ///path Therefore, ///path == //localhost/path, which may well be different from BASEURI/path. Note that on unix, /path is well-defined, but on windows, it isn't. It should probably map to C:\path, unless there is already a driver letter in path -- and I believe that old enough browsers supported paths with or without a driver letter. I do not know what the Mac equivalent of /path should be. I suspect the least bad choice for /// is to keep doing whatever it did before. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-04 18:58 Message: Logged In: YES user_id=31435 I confirm that the patch allows test_urllib2 to pass again on Windows. Assigned to Jeremy, as I made no attempt to try to understand what the patch does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 From noreply at sourceforge.net Thu Jan 8 19:08:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 19:09:01 2004 Subject: [Patches] [ python-Patches-873418 ] email/Message.py: del_param fails when specifying a header Message-ID: Patches item #873418, was opened at 2004-01-09 00: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=873418&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: email/Message.py: del_param fails when specifying a header Initial Comment: [forwarded from http://bugs.debian.org/225421] Consider the following code: import email.Message msg = email.Message.Message() msg.add_header('Content-Disposition', 'attachment', filename='bud.gif') msg.del_param('filename', 'Content-Disposition') According to the documentation, this should be the correct syntax. However, ValueError is raised in del_param. Traceback (most recent call last): File "pybug.py", line 4, in ? msg.del_param('filename', 'Content-Disposition') File "/usr/lib/python2.3/email/Message.py", line 675, in del_param for p, v in self.get_params(header, unquote=requote): ValueError: need more than 1 value to unpack It seems to me like a simple mistake of the argument order in the get_params call. The included patch fixes it, at least my program works again (maybe the same mistake is made in more places). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873418&group_id=5470 From noreply at sourceforge.net Thu Jan 8 20:49:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 8 20:49:52 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Fri Jan 9 02:55:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 9 02:55:36 2004 Subject: [Patches] [ python-Patches-873597 ] The cjkcodecs integration Message-ID: Patches item #873597, was opened at 2004-01-09 16: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=873597&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: The cjkcodecs integration Initial Comment: (finally :) CJKCodecs includes support for many East Asian legacy encodings: * Chinese (PRC): gb2312 gbk gb18030 hz * Chinese (ROC): big5 cp950 * Japanese: cp932 shift-jis shift-jisx0213 euc-jp euc-jisx0213 iso-2022-jp iso-2022-jp-1 iso-2022-jp-2 iso-2022-jp-3 iso-2022-jp-ext * Korean: cp949 euc-kr johab iso-2022-kr CJKCodecs integration to main python will make CJK users more comfortable with the default installation package. And it's not as big as you might guess. :) It bloats only 2% by source size: % du -d0 -k python 37714 python % du -d0 -k python+cjkcodecs 38504 python+cjkcodecs And it bloats only 4% by source lines: % echo `find python.cjkcodecs -type f -exec cat {} \;|wc -l` "*100/" `find python -type f -exec cat {} \;|wc -l` "-100" | bc 4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 From noreply at sourceforge.net Fri Jan 9 03:00:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 9 03:00:36 2004 Subject: [Patches] [ python-Patches-873597 ] The cjkcodecs integration Message-ID: Patches item #873597, was opened at 2004-01-09 16:55 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: The cjkcodecs integration Initial Comment: (finally :) CJKCodecs includes support for many East Asian legacy encodings: * Chinese (PRC): gb2312 gbk gb18030 hz * Chinese (ROC): big5 cp950 * Japanese: cp932 shift-jis shift-jisx0213 euc-jp euc-jisx0213 iso-2022-jp iso-2022-jp-1 iso-2022-jp-2 iso-2022-jp-3 iso-2022-jp-ext * Korean: cp949 euc-kr johab iso-2022-kr CJKCodecs integration to main python will make CJK users more comfortable with the default installation package. And it's not as big as you might guess. :) It bloats only 2% by source size: % du -d0 -k python 37714 python % du -d0 -k python+cjkcodecs 38504 python+cjkcodecs And it bloats only 4% by source lines: % echo `find python.cjkcodecs -type f -exec cat {} \;|wc -l` "*100/" `find python -type f -exec cat {} \;|wc -l` "-100" | bc 4 ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-09 17:00 Message: Logged In: YES user_id=55188 Hmm. SF seems not to accept big patches. (385KB) I uploaded the patch to http://people.freebsd.org/~perky/pythoncjkcodecs.diff.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 From noreply at sourceforge.net Fri Jan 9 16:10:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 9 16:12:34 2004 Subject: [Patches] [ python-Patches-873597 ] The cjkcodecs integration Message-ID: Patches item #873597, was opened at 2004-01-09 08:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: The cjkcodecs integration Initial Comment: (finally :) CJKCodecs includes support for many East Asian legacy encodings: * Chinese (PRC): gb2312 gbk gb18030 hz * Chinese (ROC): big5 cp950 * Japanese: cp932 shift-jis shift-jisx0213 euc-jp euc-jisx0213 iso-2022-jp iso-2022-jp-1 iso-2022-jp-2 iso-2022-jp-3 iso-2022-jp-ext * Korean: cp949 euc-kr johab iso-2022-kr CJKCodecs integration to main python will make CJK users more comfortable with the default installation package. And it's not as big as you might guess. :) It bloats only 2% by source size: % du -d0 -k python 37714 python % du -d0 -k python+cjkcodecs 38504 python+cjkcodecs And it bloats only 4% by source lines: % echo `find python.cjkcodecs -type f -exec cat {} \;|wc -l` "*100/" `find python -type f -exec cat {} \;|wc -l` "-100" | bc 4 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-09 22:10 Message: Logged In: YES user_id=21627 Can you please make that server report the file type as application/octet-stream? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-09 09:00 Message: Logged In: YES user_id=55188 Hmm. SF seems not to accept big patches. (385KB) I uploaded the patch to http://people.freebsd.org/~perky/pythoncjkcodecs.diff.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 From noreply at sourceforge.net Fri Jan 9 16:24:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 9 16:25:10 2004 Subject: [Patches] [ python-Patches-873597 ] The cjkcodecs integration Message-ID: Patches item #873597, was opened at 2004-01-09 08:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) Summary: The cjkcodecs integration Initial Comment: (finally :) CJKCodecs includes support for many East Asian legacy encodings: * Chinese (PRC): gb2312 gbk gb18030 hz * Chinese (ROC): big5 cp950 * Japanese: cp932 shift-jis shift-jisx0213 euc-jp euc-jisx0213 iso-2022-jp iso-2022-jp-1 iso-2022-jp-2 iso-2022-jp-3 iso-2022-jp-ext * Korean: cp949 euc-kr johab iso-2022-kr CJKCodecs integration to main python will make CJK users more comfortable with the default installation package. And it's not as big as you might guess. :) It bloats only 2% by source size: % du -d0 -k python 37714 python % du -d0 -k python+cjkcodecs 38504 python+cjkcodecs And it bloats only 4% by source lines: % echo `find python.cjkcodecs -type f -exec cat {} \;|wc -l` "*100/" `find python -type f -exec cat {} \;|wc -l` "-100" | bc 4 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-09 22:24 Message: Logged In: YES user_id=21627 These changes look good to me, please apply them. As for the regrtest modification, please change the tests to provide a skip_expected setting, which is computed depending on the presence of the test data - see test_normalization.py for an example. It would be good if the header files containing large tables would contain an indication on how these tables have been created (e.g. what data source have been used, and what modification had been applied after the tables where created from the sources). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-09 22:10 Message: Logged In: YES user_id=21627 Can you please make that server report the file type as application/octet-stream? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-09 09:00 Message: Logged In: YES user_id=55188 Hmm. SF seems not to accept big patches. (385KB) I uploaded the patch to http://people.freebsd.org/~perky/pythoncjkcodecs.diff.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 From noreply at sourceforge.net Fri Jan 9 16:42:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 9 16:42:59 2004 Subject: [Patches] [ python-Patches-874083 ] Bluetooth support for socket module Message-ID: Patches item #874083, was opened at 2004-01-09 21: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=874083&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Frederik Fix (frederikfix) Assigned to: Nobody/Anonymous (nobody) Summary: Bluetooth support for socket module Initial Comment: This patch adds support for Bluetooth sockets to the socket module. It supports the L2CAP, RFCOMM and SCO protocols. I have tested it on Linux 2.6.0 with the built-in Bluetooth stack. I have only tested server sockets, but client sockets should work just the same. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 From noreply at sourceforge.net Fri Jan 9 18:04:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 9 18:04:43 2004 Subject: [Patches] [ python-Patches-870693 ] make test___all__ work again Message-ID: Patches item #870693, was opened at 2004-01-04 23:25 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870693&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Barry A. Warsaw (bwarsaw) Summary: make test___all__ work again Initial Comment: test___all__ started to fail 2 days ago for base64's problem. Attached patch may fix the problem. :) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-01-09 18:04 Message: Logged In: YES user_id=12800 I don't know why I didn't see the original notice of this patch submission, but in any event I was convinced that it wasn't necessary to add the freenet encoder/decoder. So technically, I'm rejecting this patch (which also has cruft in it not related to this specific report). Instead, I fixed __all__ in base64.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870693&group_id=5470 From noreply at sourceforge.net Sat Jan 10 05:47:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 10 05:47:45 2004 Subject: [Patches] [ python-Patches-874358 ] imageop on little-endian systems uses reversed byte order Message-ID: Patches item #874358, was opened at 2004-01-10 11: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=874358&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Guido van Rossum (gvanrossum) Summary: imageop on little-endian systems uses reversed byte order Initial Comment: The format of the string data used in the imageop module is described as "This is the same format as used by gl.lrectwrite() and the imgfile module." This implies a certain byte order in multi-byte pixel formats. However, the code was originally written on an SGI (big-endian) and *uses* the fact that bytes are stored in a particular order in ints. This means that the code uses and produces different byte order on little-endian systems. The attached patch adds a module-level flag "backward_compatible" (default not set, and if not set, behaves as if set to 1--i.e. backward compatible) that can be used on a little-endian system to use the same byte order as the SGI. Using this flag it is then possible to prepare SGI-compatible images on a little-endian system. This patch is the result of a (small) discussion on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874358&group_id=5470 From noreply at sourceforge.net Sat Jan 10 09:52:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 10 09:52:16 2004 Subject: [Patches] [ python-Patches-870606 ] make test_urllib2 work on Windows Message-ID: Patches item #870606, was opened at 2004-01-04 23:48 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Jeremy Hylton (jhylton) Summary: make test_urllib2 work on Windows Initial Comment: This fixes HandlerTests.test_file() on Windows. Hope it works -- I don't have 2.4 CVS on Windows. Also cleaned up testing of generated Last-Modified header. Still needs testing on Mac. I had to introduce a sanepathname2url() to replace urllib.pathname2url(). I don't understand why urllib.pathname2url() behaves as it does (returning a path starting with three slashes /// instead of one) -- seems wrong according to RFC 1738. Should it be fixed in urllib? ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2004-01-10 14:52 Message: Logged In: YES user_id=261020 I fear you're right that "fixing" urllib.pathname2url is a bad idea for backwards-compatibility reasons. Anyway, ISTR file: URLs with one, two and three slashes, so I guess I have to admit standardization has failed here. For the record, though: You're supposed to have those extra two slashes in a *full* URL on unix, too. But the docs say: ------ Convert the pathname path from the local syntax for a path to the form used in the path component of a URL. This does not produce a complete URL. ------ RFC 1738, section 3.10, makes it clear that the path component of a file: URL doesn't include those first two slashes (actually, it's claims the third isn't, either, presumably just to be subtly different from the generic syntax of RFC 2396 - argh!). Your point about unix vs. Windows is not relevant: the path component of a file: URL isn't supposed to be directly interpreted as an OS filesystem path (RFC 1738 gives a VMS example). ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-01-08 21:03 Message: Logged In: YES user_id=764593 Today, a missing host or protocol indicates a relative URL. At one point, it could also have meant file (or ftp) to the localhost. proto://host/path -> file://localhost/path -> //localhost/path -> ///path Therefore, ///path == //localhost/path, which may well be different from BASEURI/path. Note that on unix, /path is well-defined, but on windows, it isn't. It should probably map to C:\path, unless there is already a driver letter in path -- and I believe that old enough browsers supported paths with or without a driver letter. I do not know what the Mac equivalent of /path should be. I suspect the least bad choice for /// is to keep doing whatever it did before. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-04 23:58 Message: Logged In: YES user_id=31435 I confirm that the patch allows test_urllib2 to pass again on Windows. Assigned to Jeremy, as I made no attempt to try to understand what the patch does. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870606&group_id=5470 From noreply at sourceforge.net Sat Jan 10 11:50:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 10 11:50:44 2004 Subject: [Patches] [ python-Patches-874358 ] imageop on little-endian systems uses reversed byte order Message-ID: Patches item #874358, was opened at 2004-01-10 05:47 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874358&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Sjoerd Mullender (sjoerd) Summary: imageop on little-endian systems uses reversed byte order Initial Comment: The format of the string data used in the imageop module is described as "This is the same format as used by gl.lrectwrite() and the imgfile module." This implies a certain byte order in multi-byte pixel formats. However, the code was originally written on an SGI (big-endian) and *uses* the fact that bytes are stored in a particular order in ints. This means that the code uses and produces different byte order on little-endian systems. The attached patch adds a module-level flag "backward_compatible" (default not set, and if not set, behaves as if set to 1--i.e. backward compatible) that can be used on a little-endian system to use the same byte order as the SGI. Using this flag it is then possible to prepare SGI-compatible images on a little-endian system. This patch is the result of a (small) discussion on python-dev. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-10 11:50 Message: Logged In: YES user_id=6380 Works for me! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874358&group_id=5470 From noreply at sourceforge.net Sat Jan 10 15:44:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 10 15:44:44 2004 Subject: [Patches] [ python-Patches-874358 ] imageop on little-endian systems uses reversed byte order Message-ID: Patches item #874358, was opened at 2004-01-10 11:47 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874358&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Sjoerd Mullender (sjoerd) Summary: imageop on little-endian systems uses reversed byte order Initial Comment: The format of the string data used in the imageop module is described as "This is the same format as used by gl.lrectwrite() and the imgfile module." This implies a certain byte order in multi-byte pixel formats. However, the code was originally written on an SGI (big-endian) and *uses* the fact that bytes are stored in a particular order in ints. This means that the code uses and produces different byte order on little-endian systems. The attached patch adds a module-level flag "backward_compatible" (default not set, and if not set, behaves as if set to 1--i.e. backward compatible) that can be used on a little-endian system to use the same byte order as the SGI. Using this flag it is then possible to prepare SGI-compatible images on a little-endian system. This patch is the result of a (small) discussion on python-dev. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2004-01-10 21:44 Message: Logged In: YES user_id=43607 Checked in as rev 2.28 (imageop.c) and 1.12 (libimageop.tex). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-10 17:50 Message: Logged In: YES user_id=6380 Works for me! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874358&group_id=5470 From patches at python.org Sun Jan 11 09:49:52 2004 From: patches at python.org (Lilit) Date: Sun Jan 11 01:49:01 2004 Subject: [Patches] Trans... Message-ID: <29210761838.547052501010727@python.org> :::Asian trans::: Getting her cock sucked is Jackie's idea of a fun night! As Nikki sucks on her cock, she uses her finger to make small circles around Jackie's virgin asshole. She then bends her over and sticks her tongue in and out of her asshole in a teasing motion. She then follows up by sticking her dick deep into her ass while she plays with her balls. http://dot.hoha.ru/trans --- Hours and hours of video --- Daily updated --- Thousands of exclusive photos --- Michelle slowly removes Anna's panties exposing her nice cock ... --- Getting her cock sucked is Jackie's idea of a fun night! --- !!! But that's not all you get 2 addition sites for 1 instant acseess http://dot.hoha.ru/trans ^^^ ^^^ ^^^ ^^^ Click here -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040111/44e671f2/attachment.html From noreply at sourceforge.net Sun Jan 11 06:07:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 11 06:07:32 2004 Subject: [Patches] [ python-Patches-738094 ] for i in range(N) optimization Message-ID: Patches item #738094, was opened at 2003-05-15 07:14 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: Later Priority: 2 Submitted By: Sebastien Keim (s_keim) Assigned to: Guido van Rossum (gvanrossum) Summary: for i in range(N) optimization Initial Comment: This patch is intended to special case the built-in range function in the common "for i in range(...):" construct. The goal is to make range() return an iterator instead of creating a real list, and then being able to depreciate the xrange type. It has once been suggested to make the compiler aware of the "for i in range(N):" construct and to make it able to produce optimized bytecode. But this solution is really hard to achieve because you have to ensure that the range built-in is not overridden. The patch take an opposite approach: it let the range built-in function looks at its execution context, and return an iterator if the next frame opcode to be executed is the GET_ITER opcode. Speed increase for the piece of code "for i in range(N): pass" : N (speed gain) 10 (+ 64%) 100 (+ 29%) 1000 (+ 23%) 10000 (+ 68%) 100000 (+108%) Since the patch only affect a small construct of the language, performance improvements for real applications are less impressive but they are still interesting: pystone.py (+7%) test_userstring.py (+8%) test_datetime.py (+20%) Note that the performance loss for "A = range(10)" is not measurable (less than 1%). If the patch is accepted, the same recipe may be applicable in some few other places. So the Py_IsIterationContext function must probably live somewhere else (is there a standard location for byte-code dependent stuff?). Maybe other opcodes (for sample JUMP_IF_FALSE) could provide other useful specialization contexts. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-01-11 11:07 Message: Logged In: YES user_id=4771 Here is a safer patch. It adds a keyword argument 'iter' to range(), e.g.: >>> range(10, iter=True) and using an appropriate METH_XXX flag, the CALL_FUNCTION opcode now inserts a 'iter=True' keyword to the call when it is followed by GET_ITER. The patch doesn't live up to its performance promizes. I don't get any improvement at all on any real application. The only example it accelerates is a set of three nested loops :-( I still attach it for reference, and if someone else want to play with it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 16:22 Message: Logged In: YES user_id=6380 In the sake of stability for Python 2.3's accelerated release schedule, I'm postponing this until after 2.3. I'm also skeptical that it ca be absolutely correct. What if there is Python code of the form for i in some_function(): ... where some_function() is a C extension that at some point invokes range(), directly from C. Then when range() peeks in the opcode stream, it would believe that it was being called in the place of some_function(). So maybe I should just reject it as unsafe? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-18 21:18 Message: Logged In: YES user_id=6380 I'm interested, but have to ponder more, which will have to wait until I'm back from vacation. I expect that any hope to deprecate xrange() will prove naive -- people will want to pass ranges around between functions or reuse them (e.g. this happens a lot in timing tests). Maybe in Python 3.0 I can make range() act as an iterator generator. You'd have to say list(range(N)) to get an actual list then. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-17 23:25 Message: Logged In: YES user_id=80475 Assigning to Guido to see whether he is interested because it makes xrange less necessary or whether he thinks it is a horrendous hack --or maybe both ;-) ---------------------------------------------------------------------- Comment By: Sebastien Keim (s_keim) Date: 2003-05-15 15:14 Message: Logged In: YES user_id=498191 I have also thought about slicing, map and filter which could all be replaced by itertools equivalents , but I have failed to find a way to ensure that the argument lists aren't mutated during the for loop. Maybe it could be interesting to investigate into copy on write semantic for lists objects? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-05-15 14:33 Message: Logged In: YES user_id=80475 zip() would benefit greatly from your approach. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=738094&group_id=5470 From absoluteIdeal90 at hotmail.com Sun Jan 11 14:02:21 2004 From: absoluteIdeal90 at hotmail.com (No Employees Needed) Date: Sun Jan 11 14:02:13 2004 Subject: [Patches] Reach 500,000 more people Message-ID: <200401111901.i0BJ1sIM056767@mxzilla6.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040111/1c6cd592/attachment.html From patches at python.org Mon Jan 12 00:39:54 2004 From: patches at python.org (Webmaster) Date: Sun Jan 11 16:39:13 2004 Subject: [Patches] So sweet ... Message-ID: <56523054121.212701250961412@python.org> ..::: Max Teens :::... http://210.101.95.254/maxteen/ ^^^ ^^^ Click here to see more Every day you see a lot you teens on the streets but you never know what do they usually do when alone! You think studying and learning poems? You're wrong then. When young hot girls are alone - they lose their "good girls" face and show their lascivious nature! Have you ever seen young boy and girls fucking like mad beasts on the floor in the bathroom? Have you ever seen them sucking one another's crotches right on the white leather sofa? Be sure - soon you will get this chance! http://210.101.95.254/maxteen/ ^^^ ^^^ Click here to see more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040112/f22b3e03/attachment.html From noreply at sourceforge.net Sun Jan 11 18:32:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 11 18:32:53 2004 Subject: [Patches] [ python-Patches-870287 ] Fix docstring for posixpath.getctime Message-ID: Patches item #870287, was opened at 2004-01-04 04:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docstring for posixpath.getctime Initial Comment: (not sure whether this is "Library" or "Documentation") The docstring of posixpath.getctime calls ctime the "creation time". This is incorrect, because it is the "change time". The library documentation is correct here. This patch fixes the docstring. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-11 18:32 Message: Logged In: YES user_id=80475 IIRC, it is creation time on some platforms and is the change time on others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 From noreply at sourceforge.net Sun Jan 11 18:35:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 11 18:35:56 2004 Subject: [Patches] [ python-Patches-871402 ] add link to DDJ's article Message-ID: Patches item #871402, was opened at 2004-01-05 21:46 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: add link to DDJ's article Initial Comment: The document of difflib refers to an article published by DDJ. www.python.org/doc/current/lib/module-difflib.html http://www.ddj.com/ "Pattern Matching: The Gestalt Approach" by John W. Ratcliff & D. E. Metzener Luckily, this article is available on DDJ's site, so why not add a link to that URI? # http://www.ddj.com/articles/1988/8807/ # http://www.ddj.com/documents/s=1103/ddj8807c/ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-11 18:35 Message: Logged In: YES user_id=80475 Usually, we don't put in links unless pretty sure that the link will remain valid for a long time. The DDJ site is relatively stable, but it is still a judgement call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 From noreply at sourceforge.net Sun Jan 11 18:44:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 11 18:44:21 2004 Subject: [Patches] [ python-Patches-870286 ] make Demo/scripts/primes.py usable as a module Message-ID: Patches item #870286, was opened at 2004-01-04 04:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: make Demo/scripts/primes.py usable as a module Initial Comment: I wanted to find all primes between 1985 and 2005, and found out that Demo/scripts/primes.py is not usable as a module, because it unconditionally executes main(). This patch adds a 'if __name__ == "__main__"' block around the execution of the main() function, so that one can simply import primes and use primes.primes(1985, 2005) in order to achieve what I wanted to achieve. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-11 18:44 Message: Logged In: YES user_id=80475 If you're going to improve this one, consider going all the way. * Modernize the code -- the current version reads like Cobol * Stop building the sieve after sqrt(MAX) entries have been found. Possibly use islice() to check only the relevant entries in the primes table. * Change the API to: prime x [n] which finds the first n (default 1) primes larger than x. prime(10,3) --> [11, 13, 17] * If x is large, switch to a modern primality testing algorithm so that arbitrarily large primes can be found (perhaps for RSA purposes or some such). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470 From noreply at sourceforge.net Sun Jan 11 22:26:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 11 22:27:06 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Sun Jan 11 23:11:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 11 23:11:38 2004 Subject: [Patches] [ python-Patches-870287 ] Fix docstring for posixpath.getctime Message-ID: Patches item #870287, was opened at 2004-01-04 18:22 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docstring for posixpath.getctime Initial Comment: (not sure whether this is "Library" or "Documentation") The docstring of posixpath.getctime calls ctime the "creation time". This is incorrect, because it is the "change time". The library documentation is correct here. This patch fixes the docstring. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-12 13:11 Message: Logged In: YES user_id=671362 > IIRC, it is creation time on some platforms and is the > change time on others. This was discussed before. [ 827902 ] ctime is not creation time http://www.python.org/sf/827902 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-12 08:32 Message: Logged In: YES user_id=80475 IIRC, it is creation time on some platforms and is the change time on others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 From noreply at sourceforge.net Mon Jan 12 14:14:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 12 14:14:18 2004 Subject: [Patches] [ python-Patches-796772 ] CGIHTTPServer fix Message-ID: Patches item #796772, was opened at 2003-08-28 12:34 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796772&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) >Assigned to: Guido van Rossum (gvanrossum) Summary: CGIHTTPServer fix Initial Comment: Here's a fix for the CGI server. The problem only occurs on systems that support os.fork(). When you invoke a CGI script with a query string and then subsequent invoke it without a query string (or with an empty query string), the second invocation gets passed the query string of the first invocation. This is because of the way os.environ is updated in the parent, but when there is no query string, the old query string doesn't get deleted. The solution is to update the os.environ in the child. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 02:12 Message: Logged In: YES user_id=21627 I agree with rhettinger. The original patch assumes that the platform has putenv/setenv, which it might not (if it doesn't, then the os.environ.update is not reflected in the C environment, and thus has no effect on os.execv). Whether or not os.environ needs to be copied is debatable; the copying has its cost, but avoiding the putenv calls would save some of the costs. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-31 10:48 Message: Logged In: YES user_id=80475 The first part of the patch makes sense to me. The second part updates os.environ which is shared between successive calls. I would have expected something like: childenv = os.environ.copy() childenv.update(env) . . . os.execve(scriptfile, args, childenv) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=796772&group_id=5470 From noreply at sourceforge.net Mon Jan 12 14:19:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 12 14:19:51 2004 Subject: [Patches] [ python-Patches-874083 ] Bluetooth support for socket module Message-ID: Patches item #874083, was opened at 2004-01-09 16:42 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Frederik Fix (frederikfix) Assigned to: Nobody/Anonymous (nobody) Summary: Bluetooth support for socket module Initial Comment: This patch adds support for Bluetooth sockets to the socket module. It supports the L2CAP, RFCOMM and SCO protocols. I have tested it on Linux 2.6.0 with the built-in Bluetooth stack. I have only tested server sockets, but client sockets should work just the same. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-12 14:19 Message: Logged In: YES user_id=6380 Looks reasonable to me, except the mention of SCO raises a red flag. Is this the same SCO that is sueing Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 From noreply at sourceforge.net Mon Jan 12 16:30:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 12 16:34:43 2004 Subject: [Patches] [ python-Patches-875689 ] >100k alloc wasted on startup Message-ID: Patches item #875689, was opened at 2004-01-12 22: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=875689&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Pall (mikesfpy) Assigned to: Nobody/Anonymous (nobody) Summary: >100k alloc wasted on startup Initial Comment: A glaring error in Objects/intobject.c function _PyInt_Init(): It allocates a whole BLOCK of ints each time through the loop (i.e. 106 blocks of 1K size) and not just 106 int objects. Allocating 106 blocks means a preallocation of more than 8600 int objects which is VERY unlikely to be needed by most programs. So this bug wastes more than 100K on every startup. The appended patch is vs. the current CVS. The bug is present in 2.3.* and also in 2.2.? (not sure if I interpret the CVS logs right). If you don't believe that this bug exists, just add a putc('#',stderr); right before the code in fill_free_list() and see what happens when you startup python. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=875689&group_id=5470 From noreply at sourceforge.net Mon Jan 12 16:45:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 12 16:45:28 2004 Subject: [Patches] [ python-Patches-875689 ] >100k alloc wasted on startup Message-ID: Patches item #875689, was opened at 2004-01-12 16:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=875689&group_id=5470 Category: Core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Pall (mikesfpy) Assigned to: Nobody/Anonymous (nobody) >Summary: >100k alloc wasted on startup Initial Comment: A glaring error in Objects/intobject.c function _PyInt_Init(): It allocates a whole BLOCK of ints each time through the loop (i.e. 106 blocks of 1K size) and not just 106 int objects. Allocating 106 blocks means a preallocation of more than 8600 int objects which is VERY unlikely to be needed by most programs. So this bug wastes more than 100K on every startup. The appended patch is vs. the current CVS. The bug is present in 2.3.* and also in 2.2.? (not sure if I interpret the CVS logs right). If you don't believe that this bug exists, just add a putc('#',stderr); right before the code in fill_free_list() and see what happens when you startup python. :-) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-12 16:45 Message: Logged In: YES user_id=31435 Good eye! Your analysis is correct, and the patch looks good too. It's probably bad that the current code is spraying the "frequently used" little integers all over memory too. The patch also fixes that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=875689&group_id=5470 From noreply at sourceforge.net Tue Jan 13 04:07:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 04:07:55 2004 Subject: [Patches] [ python-Patches-874083 ] Bluetooth support for socket module Message-ID: Patches item #874083, was opened at 2004-01-09 21:42 Message generated for change (Comment added) made by frederikfix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Frederik Fix (frederikfix) Assigned to: Nobody/Anonymous (nobody) Summary: Bluetooth support for socket module Initial Comment: This patch adds support for Bluetooth sockets to the socket module. It supports the L2CAP, RFCOMM and SCO protocols. I have tested it on Linux 2.6.0 with the built-in Bluetooth stack. I have only tested server sockets, but client sockets should work just the same. ---------------------------------------------------------------------- >Comment By: Frederik Fix (frederikfix) Date: 2004-01-13 09:07 Message: Logged In: YES user_id=947584 SCO in this case stands for Synchronous Connection-oriented protocol. It's one of the protocols that can be layered on top of Bluetooth. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-12 19:19 Message: Logged In: YES user_id=6380 Looks reasonable to me, except the mention of SCO raises a red flag. Is this the same SCO that is sueing Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 From noreply at sourceforge.net Tue Jan 13 10:20:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 10:20:30 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08: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=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Tue Jan 13 10:23:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 10:23:35 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Settings changed) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Tim Peters (tim_one) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Tue Jan 13 10:32:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 10:32:20 2004 Subject: [Patches] [ python-Patches-579435 ] Shadow Password Support Module Message-ID: Patches item #579435, was opened at 2002-07-09 23:13 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 Category: Modules >Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Lance Ellinghaus (ellinghaus) >Assigned to: A.M. Kuchling (akuchling) Summary: Shadow Password Support Module Initial Comment: Attached is the spwd module. This module provides support for Shadow Passwords on Solaris 2.8. This compliments the nis and pwd modules. This is the only way to gain access to the encrypted passwords when using shadow passwords on Solaris. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-01-13 10:32 Message: Logged In: YES user_id=11375 As it happens, I was hunting for Python shadow password support and came across this patch. The module isn't Solaris-specific, and would be necessary on Linux, too. However, the interface for getting shadow passwords doesn't seem to be standardized; see http://www.unixpapa.com/incnote/passwd. html for a list. (The Single Unix spec doesn't seem to mention shadow passwords.) One question is whether we want a new module for this, or if the functions should be in the existing pwd module. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:22 Message: Logged In: YES user_id=33168 There doesn't seem to be much interest in this patch. I don't think it reaches a wide-enough audience, therefore, I'm rejecting it. If there is broader support (many people are interested in seeing shadow password support in the core), we can add it later. I think it would be best to provide this as a third-party module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=579435&group_id=5470 From noreply at sourceforge.net Tue Jan 13 11:17:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 11:17:39 2004 Subject: [Patches] [ python-Patches-876178 ] input() vs __future__ Message-ID: Patches item #876178, was opened at 2004-01-13 16:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876178&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: input() vs __future__ Initial Comment: There's a thread on comp.lang.python about input()s lack of interaction with __future__ statements: >>> from __future__ import division >>> input('blah: ') blah: 1/2 0 This simple patch fixes that. Not sure how to write a testcase, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876178&group_id=5470 From noreply at sourceforge.net Tue Jan 13 11:35:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 11:35:32 2004 Subject: [Patches] [ python-Patches-876193 ] reorganize, extend function call optimizations Message-ID: Patches item #876193, was opened at 2004-01-13 16:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876193&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: reorganize, extend function call optimizations Initial Comment: This patch rejigs the optimizations for certain kinds of function call -- easy Python functions, METH_O functions and so on. It also extends the "easy Python function" optimization to handle default arguments. It adds a tp_pythoncall field to type objects, with the signature of the ceval.c local static function do_call (which is now exported and called PyEval_DoCall). This field is filled out in the function and method constructors appropriately. What do you think? Makes little performance difference (0.5% improvement in pystone on one machine), but I think I prefer this arrangement. It generalizes better, for one thing. The patch is a little untidy at present -- some code duplication and it utterly mangles the function call statistics code -- but these should be shallow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876193&group_id=5470 From noreply at sourceforge.net Tue Jan 13 11:43:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 11:43:06 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Greg Stein (gstein) Summary: easiest 1% improvement in pystone ever Initial Comment: I've always been a bit suspicious of the machinery to allow arbitrary objects that support the read buffer interface as the co_code attribute of code objects, but didn't realise that hacking it out improved pystone by a repeatable 1%! Greg, according to CVS this is your feature I'm proposing removing -- can you explain its value? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Tue Jan 13 11:49:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 11:49:55 2004 Subject: [Patches] [ python-Patches-876206 ] scary frame speed hacks Message-ID: Patches item #876206, was opened at 2004-01-13 16:49 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=876206&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: scary frame speed hacks Initial Comment: In ceval.c we find /* XXX Perhaps we should create a specialized PyFrame_New() that doesn't take locals, but does take builtins without sanity checking them. */ This patch takes that idea rather further than you might have expected... it creates a "light" subtype of frame that assumes certain things about the frame, gives this type its own free list (so it can assume more about objects on the freelist) and converts light frames into "heavy" frames when assumptions stop being true. Good for a ~5% improvement on "./python -s 'def f(): pass' 'f()'"; a bit less on pystone. It also conflicts slightly with my function reorg patch -- apply that first, apply this, ignore the reject and edit func_caller_nofrees in funcobject.c to call PyFrame_NewLight. All three patches I just submitted together get ~6% on pystone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 From noreply at sourceforge.net Tue Jan 13 13:20:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 13:20:18 2004 Subject: [Patches] [ python-Patches-876206 ] scary frame speed hacks Message-ID: Patches item #876206, was opened at 2004-01-13 16:49 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: scary frame speed hacks Initial Comment: In ceval.c we find /* XXX Perhaps we should create a specialized PyFrame_New() that doesn't take locals, but does take builtins without sanity checking them. */ This patch takes that idea rather further than you might have expected... it creates a "light" subtype of frame that assumes certain things about the frame, gives this type its own free list (so it can assume more about objects on the freelist) and converts light frames into "heavy" frames when assumptions stop being true. Good for a ~5% improvement on "./python -s 'def f(): pass' 'f()'"; a bit less on pystone. It also conflicts slightly with my function reorg patch -- apply that first, apply this, ignore the reject and edit func_caller_nofrees in funcobject.c to call PyFrame_NewLight. All three patches I just submitted together get ~6% on pystone. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2004-01-13 18:20 Message: Logged In: YES user_id=31392 I don't see any files attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 From noreply at sourceforge.net Tue Jan 13 13:23:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 13:23:08 2004 Subject: [Patches] [ python-Patches-876206 ] scary frame speed hacks Message-ID: Patches item #876206, was opened at 2004-01-13 16:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: scary frame speed hacks Initial Comment: In ceval.c we find /* XXX Perhaps we should create a specialized PyFrame_New() that doesn't take locals, but does take builtins without sanity checking them. */ This patch takes that idea rather further than you might have expected... it creates a "light" subtype of frame that assumes certain things about the frame, gives this type its own free list (so it can assume more about objects on the freelist) and converts light frames into "heavy" frames when assumptions stop being true. Good for a ~5% improvement on "./python -s 'def f(): pass' 'f()'"; a bit less on pystone. It also conflicts slightly with my function reorg patch -- apply that first, apply this, ignore the reject and edit func_caller_nofrees in funcobject.c to call PyFrame_NewLight. All three patches I just submitted together get ~6% on pystone. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-01-13 18:23 Message: Logged In: YES user_id=6656 sigh ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-01-13 18:20 Message: Logged In: YES user_id=31392 I don't see any files attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 From noreply at sourceforge.net Tue Jan 13 15:05:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 13 15:05:29 2004 Subject: [Patches] [ python-Patches-871402 ] add link to DDJ's article Message-ID: Patches item #871402, was opened at 2004-01-05 21:46 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 Category: Documentation Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: add link to DDJ's article Initial Comment: The document of difflib refers to an article published by DDJ. www.python.org/doc/current/lib/module-difflib.html http://www.ddj.com/ "Pattern Matching: The Gestalt Approach" by John W. Ratcliff & D. E. Metzener Luckily, this article is available on DDJ's site, so why not add a link to that URI? # http://www.ddj.com/articles/1988/8807/ # http://www.ddj.com/documents/s=1103/ddj8807c/ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-11 18:35 Message: Logged In: YES user_id=80475 Usually, we don't put in links unless pretty sure that the link will remain valid for a long time. The DDJ site is relatively stable, but it is still a judgement call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 From patches at python.org Wed Jan 14 03:04:55 2004 From: patches at python.org (News for you) Date: Tue Jan 13 19:04:48 2004 Subject: [Patches] So young ... Message-ID: <09890563094.947634767010567@python.org> ..::: TEENAGER P0RN 2 :::... http://210.101.95.254/teenagerporn/ ^^^^^ ^^^^^ CLICK HERE TO START WATCHING! Tired of those sites that only give you a few crappy feeds to watch, and they never change or update them? Well you won`t find that here! Project "Teenager p0rno 2" has Full Length , high quality videos with sound, that can be watched full screen ! Hot lesbians, wild blowjobs, horny sex babes, threesomes and all ready for instant download. This is the closest thing to an online p0rn video lirbrary - but you keep our movies. Join now and get the best Quality XXX Porn Movies! You'll never find a site on the net like this one. Satisfaction guaranteed! GET INSTANT ACCESS TO OUR HOT XXX MOVIES 100% Exclusive Hardcore Content - Updated Constantly - Live Sex Shows And More http://210.101.95.254/teenagerporn/ ^^^^^ ^^^^^ CLICK HERE TO START WATCHING! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040114/b2fcfe53/attachment.html From patches at python.org Wed Jan 14 06:12:02 2004 From: patches at python.org (Webmaster) Date: Tue Jan 13 22:11:58 2004 Subject: [Patches] So sweet ... Message-ID: <67630365672.989096321830503@python.org> ..::: Max Teens :::... http://210.101.95.254/maxteens/ ^^^ ^^^ Click here to see more Every day you see a lot you teens on the streets but you never know what do they usually do when alone! You think studying and learning poems? You're wrong then. When young hot girls are alone - they lose their "good girls" face and show their lascivious nature! Have you ever seen young boy and girls fucking like mad beasts on the floor in the bathroom? Have you ever seen them sucking one another's crotches right on the white leather sofa? Be sure - soon you will get this chance! http://210.101.95.254/maxteens/ ^^^ ^^^ Click here to see more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040114/d81ee797/attachment.html From patches at python.org Wed Jan 14 06:13:12 2004 From: patches at python.org (Webmaster) Date: Tue Jan 13 22:13:08 2004 Subject: [Patches] So sweet ... Message-ID: <07612341672.387474569434523@python.org> ..::: Max Teens :::... http://210.101.95.254/maxteens/ ^^^ ^^^ Click here to see more Every day you see a lot you teens on the streets but you never know what do they usually do when alone! You think studying and learning poems? You're wrong then. When young hot girls are alone - they lose their "good girls" face and show their lascivious nature! Have you ever seen young boy and girls fucking like mad beasts on the floor in the bathroom? Have you ever seen them sucking one another's crotches right on the white leather sofa? Be sure - soon you will get this chance! http://210.101.95.254/maxteens/ ^^^ ^^^ Click here to see more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040114/00710533/attachment.html From patches at python.org Wed Jan 14 09:42:32 2004 From: patches at python.org (- 0bulk -) Date: Wed Jan 14 01:42:34 2004 Subject: [Patches] Drunk Young Message-ID: <65030387250.945892369236589@python.org> http://210.101.95.254/drunk-young/ What is DrunkYoung ? Who owns it ? And what we offer you ? Just read following attentively! DrunkYoung is a new project of two young fellows having a hobby of taking pictures - the youngest girls pictures! Once a month I and my friend get on our way to some small town near Moscow and rent a flat there for four or six days or simply use a hotel apartments and then we as to call it "go into the city" to pick up some young pretties, usually we manage to hook up to for girls a day - indeed extremely young! We spend some time with them, go somewhere like to the cinema then to some bar and eventually offer them to go with us to our place, then.. then.. we propose them to take some pictures, seduce them to pose naked... and do whatever else you might imagine. Some are easily persuaded other take some time to get ready for the show but trust our experience in arising even the humblest! http://210.101.95.254/drunk-young/ With each girl we take at least 20 minutes of video and we make them take a shower and shave pubis hair and then to shave pussy - you will see it - and then while I photo them with my camera my friend takes video (high quality) as she touches her pussy with tips of her fingers, takes vibrator inside her pussy or inserts a finger in her pink ass - believe me it is really a rush!!! http://210.101.95.254/drunk-young/ I hope you join our club and I will see you among our members! http://210.101.95.254/drunk-young/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040114/5f0a67e8/attachment.html From patches at python.org Wed Jan 14 15:08:36 2004 From: patches at python.org (Isabella) Date: Wed Jan 14 07:08:40 2004 Subject: [Patches] Ripe woman Message-ID: <41292163812.383216529630125@python.org> COME ON HERE: http://zone.hoha.ru/allstrip What can be better than hard fuck? Here you will see how it should be done by all rules!  Ripe girls are ready to start it even now!  Kathy took soft yet dick in her hands and by few movements made it hard as stone!  Here it is - power and skill of the ripe woman! But if she had only skilful hands, she hardly could be here!  Tight-assed and lustfull - what she is! She will not think long and her desires will hold the reins! 100% Cock Hungry Girls - real girls that love to fuck and suck a dick until they get covered in cum! From noreply at sourceforge.net Wed Jan 14 12:35:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 14 12:36:10 2004 Subject: [Patches] [ python-Patches-876206 ] scary frame speed hacks Message-ID: Patches item #876206, was opened at 2004-01-13 16:49 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: scary frame speed hacks Initial Comment: In ceval.c we find /* XXX Perhaps we should create a specialized PyFrame_New() that doesn't take locals, but does take builtins without sanity checking them. */ This patch takes that idea rather further than you might have expected... it creates a "light" subtype of frame that assumes certain things about the frame, gives this type its own free list (so it can assume more about objects on the freelist) and converts light frames into "heavy" frames when assumptions stop being true. Good for a ~5% improvement on "./python -s 'def f(): pass' 'f()'"; a bit less on pystone. It also conflicts slightly with my function reorg patch -- apply that first, apply this, ignore the reject and edit func_caller_nofrees in funcobject.c to call PyFrame_NewLight. All three patches I just submitted together get ~6% on pystone. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-01-14 17:35 Message: Logged In: YES user_id=4771 (Side note first: I'm not sure 'builtins = back->f_builtins' is right.) Is the whole subclassing complexity worth the effort, given that the invariants of light frames only seem to be that four specific fields are null? Changing the type of an object under Python code's feet is calling for troubles. Moreover it is bound to break code that expect 'type(frame)==FrameType', even if such code can be considered bad style. Moreover it requires a number of hacks here and there -- e.g. you turn a light frame into a "heavy" frame when f_trace is set; is it on purpose that you don't do it when f_locals is set? I cannot seem to get reliable performance results on my machine, but maybe you want to compare with the attached patch which speeds up the regular PyFrame_New by putting stronger invariants on all the frames in the free_list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-13 18:23 Message: Logged In: YES user_id=6656 sigh ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-01-13 18:20 Message: Logged In: YES user_id=31392 I don't see any files attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 From noreply at sourceforge.net Thu Jan 15 06:02:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 15 06:02:42 2004 Subject: [Patches] [ python-Patches-876206 ] scary frame speed hacks Message-ID: Patches item #876206, was opened at 2004-01-13 16:49 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: scary frame speed hacks Initial Comment: In ceval.c we find /* XXX Perhaps we should create a specialized PyFrame_New() that doesn't take locals, but does take builtins without sanity checking them. */ This patch takes that idea rather further than you might have expected... it creates a "light" subtype of frame that assumes certain things about the frame, gives this type its own free list (so it can assume more about objects on the freelist) and converts light frames into "heavy" frames when assumptions stop being true. Good for a ~5% improvement on "./python -s 'def f(): pass' 'f()'"; a bit less on pystone. It also conflicts slightly with my function reorg patch -- apply that first, apply this, ignore the reject and edit func_caller_nofrees in funcobject.c to call PyFrame_NewLight. All three patches I just submitted together get ~6% on pystone. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-01-15 11:02 Message: Logged In: YES user_id=6656 I'm fairly sure this made a difference on my iBook; haven't tried on x86. It's possible that the correct response to this patch is to add "... nah, not worth it" to the XXX comment in ceval.c... ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-14 17:35 Message: Logged In: YES user_id=4771 (Side note first: I'm not sure 'builtins = back->f_builtins' is right.) Is the whole subclassing complexity worth the effort, given that the invariants of light frames only seem to be that four specific fields are null? Changing the type of an object under Python code's feet is calling for troubles. Moreover it is bound to break code that expect 'type(frame)==FrameType', even if such code can be considered bad style. Moreover it requires a number of hacks here and there -- e.g. you turn a light frame into a "heavy" frame when f_trace is set; is it on purpose that you don't do it when f_locals is set? I cannot seem to get reliable performance results on my machine, but maybe you want to compare with the attached patch which speeds up the regular PyFrame_New by putting stronger invariants on all the frames in the free_list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-13 18:23 Message: Logged In: YES user_id=6656 sigh ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-01-13 18:20 Message: Logged In: YES user_id=31392 I don't see any files attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 From noreply at sourceforge.net Sat Jan 17 09:47:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 17 09:47:17 2004 Subject: [Patches] [ python-Patches-873597 ] The cjkcodecs integration Message-ID: Patches item #873597, was opened at 2004-01-09 16:55 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) Summary: The cjkcodecs integration Initial Comment: (finally :) CJKCodecs includes support for many East Asian legacy encodings: * Chinese (PRC): gb2312 gbk gb18030 hz * Chinese (ROC): big5 cp950 * Japanese: cp932 shift-jis shift-jisx0213 euc-jp euc-jisx0213 iso-2022-jp iso-2022-jp-1 iso-2022-jp-2 iso-2022-jp-3 iso-2022-jp-ext * Korean: cp949 euc-kr johab iso-2022-kr CJKCodecs integration to main python will make CJK users more comfortable with the default installation package. And it's not as big as you might guess. :) It bloats only 2% by source size: % du -d0 -k python 37714 python % du -d0 -k python+cjkcodecs 38504 python+cjkcodecs And it bloats only 4% by source lines: % echo `find python.cjkcodecs -type f -exec cat {} \;|wc -l` "*100/" `find python -type f -exec cat {} \;|wc -l` "-100" | bc 4 ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-17 23:47 Message: Logged In: YES user_id=55188 Okay. Committed as: Modified files: Doc/lib/libcodecs.tex 1.27 Lib/email/test/test_email_codecs.py 1.5 Lib/encodings/aliases.py 1.21 Modules/Setup.dist 1.43 Lib/test/regrtest.py 1.151 setup.py 1.181 Added files: Lib/encodings/big5.py Lib/encodings/cp932.py Lib/encodings/cp949.py Lib/encodings/cp950.py Lib/encodings/euc_jisx0213.py Lib/encodings/euc_jp.py Lib/encodings/euc_kr.py Lib/encodings/gb18030.py Lib/encodings/gb2312.py Lib/encodings/gbk.py Lib/encodings/iso2022_jp.py Lib/encodings/iso2022_jp_1.py Lib/encodings/iso2022_jp_2.py Lib/encodings/iso2022_jp_3.py Lib/encodings/iso2022_jp_ext.py Lib/encodings/iso2022_kr.py Lib/encodings/johab.py Lib/encodings/shift_jis.py Lib/encodings/shift_jisx0213.py Lib/test/cjkencodings_test.py Lib/test/test_codecencodings_cn.py Lib/test/test_codecencodings_jp.py Lib/test/test_codecencodings_kr.py Lib/test/test_codecencodings_tw.py Lib/test/test_codecmaps_cn.py Lib/test/test_codecmaps_jp.py Lib/test/test_codecmaps_kr.py Lib/test/test_codecmaps_tw.py Lib/test/test_multibytecodec.py Lib/test/test_multibytecodec_support.py Modules/cjkcodecs/README Modules/cjkcodecs/_big5.c Modules/cjkcodecs/_cp932.c Modules/cjkcodecs/_cp949.c Modules/cjkcodecs/_cp950.c Modules/cjkcodecs/_euc_jisx0213.c Modules/cjkcodecs/_euc_jp.c Modules/cjkcodecs/_euc_kr.c Modules/cjkcodecs/_gb18030.c Modules/cjkcodecs/_gb2312.c Modules/cjkcodecs/_gbk.c Modules/cjkcodecs/_hz.c Modules/cjkcodecs/_iso2022_jp.c Modules/cjkcodecs/_iso2022_jp_1.c Modules/cjkcodecs/_iso2022_jp_2.c Modules/cjkcodecs/_iso2022_jp_3.c Modules/cjkcodecs/_iso2022_jp_ext.c Modules/cjkcodecs/_iso2022_kr.c Modules/cjkcodecs/_johab.c Modules/cjkcodecs/_shift_jis.c Modules/cjkcodecs/_shift_jisx0213.c Modules/cjkcodecs/alg_iso8859_1.h Modules/cjkcodecs/alg_iso8859_7.h Modules/cjkcodecs/alg_jisx0201.h Modules/cjkcodecs/cjkcommon.h Modules/cjkcodecs/codeccommon.h Modules/cjkcodecs/codecentry.h Modules/cjkcodecs/iso2022common.h Modules/cjkcodecs/map_big5.h Modules/cjkcodecs/map_cp932ext.h Modules/cjkcodecs/map_cp949.h Modules/cjkcodecs/map_cp949ext.h Modules/cjkcodecs/map_cp950ext.h Modules/cjkcodecs/map_gb18030ext.h Modules/cjkcodecs/map_gb18030uni.h Modules/cjkcodecs/map_gb2312.h Modules/cjkcodecs/map_gbcommon.h Modules/cjkcodecs/map_gbkext.h Modules/cjkcodecs/map_jisx0208.h Modules/cjkcodecs/map_jisx0212.h Modules/cjkcodecs/map_jisx0213.h Modules/cjkcodecs/map_jisx0213_pairs.h Modules/cjkcodecs/map_jisxcommon.h Modules/cjkcodecs/map_ksx1001.h Modules/cjkcodecs/mapdata_ja_JP.c Modules/cjkcodecs/mapdata_ko_KR.c Modules/cjkcodecs/mapdata_zh_CN.c Modules/cjkcodecs/mapdata_zh_TW.c Modules/cjkcodecs/multibytecodec.c Modules/cjkcodecs/multibytecodec.h Modules/cjkcodecs/tweak_gbk.h Thank you! :-) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-10 06:24 Message: Logged In: YES user_id=21627 These changes look good to me, please apply them. As for the regrtest modification, please change the tests to provide a skip_expected setting, which is computed depending on the presence of the test data - see test_normalization.py for an example. It would be good if the header files containing large tables would contain an indication on how these tables have been created (e.g. what data source have been used, and what modification had been applied after the tables where created from the sources). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-10 06:10 Message: Logged In: YES user_id=21627 Can you please make that server report the file type as application/octet-stream? ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-09 17:00 Message: Logged In: YES user_id=55188 Hmm. SF seems not to accept big patches. (385KB) I uploaded the patch to http://people.freebsd.org/~perky/pythoncjkcodecs.diff.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873597&group_id=5470 From noreply at sourceforge.net Sat Jan 17 09:55:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 17 09:56:58 2004 Subject: [Patches] [ python-Patches-870287 ] Fix docstring for posixpath.getctime Message-ID: Patches item #870287, was opened at 2004-01-04 10:22 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docstring for posixpath.getctime Initial Comment: (not sure whether this is "Library" or "Documentation") The docstring of posixpath.getctime calls ctime the "creation time". This is incorrect, because it is the "change time". The library documentation is correct here. This patch fixes the docstring. ---------------------------------------------------------------------- >Comment By: Gerrit Holl (gerrit) Date: 2004-01-17 15:55 Message: Logged In: YES user_id=13298 The docstring is a different issue: The standard library needs to be accurate for all platforms, whereas each platform has it's own implementation of os.path.getctime. Hence, it's possible to give each platform it's own docstring for os.path.getctime, so that posixpath.getctime.__doc__ != ntpath.getctime.__doc__. Is this it a good thing to have different docstrings? If so, I'd say that each platform documents for it's own getctime what ctime means. If not, I'd say we copy the standard library documentation. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-12 05:11 Message: Logged In: YES user_id=671362 > IIRC, it is creation time on some platforms and is the > change time on others. This was discussed before. [ 827902 ] ctime is not creation time http://www.python.org/sf/827902 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-12 00:32 Message: Logged In: YES user_id=80475 IIRC, it is creation time on some platforms and is the change time on others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 From noreply at sourceforge.net Sat Jan 17 09:58:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 17 09:59:19 2004 Subject: [Patches] [ python-Patches-870286 ] make Demo/scripts/primes.py usable as a module Message-ID: Patches item #870286, was opened at 2004-01-04 10:18 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: make Demo/scripts/primes.py usable as a module Initial Comment: I wanted to find all primes between 1985 and 2005, and found out that Demo/scripts/primes.py is not usable as a module, because it unconditionally executes main(). This patch adds a 'if __name__ == "__main__"' block around the execution of the main() function, so that one can simply import primes and use primes.primes(1985, 2005) in order to achieve what I wanted to achieve. ---------------------------------------------------------------------- >Comment By: Gerrit Holl (gerrit) Date: 2004-01-17 15:58 Message: Logged In: YES user_id=13298 Hm, I don't think I have enough mathematical knowledge to go 'all the way', although some of the suggestions are doable. I'll have a look at it next week (week of Jan-26). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-12 00:44 Message: Logged In: YES user_id=80475 If you're going to improve this one, consider going all the way. * Modernize the code -- the current version reads like Cobol * Stop building the sieve after sqrt(MAX) entries have been found. Possibly use islice() to check only the relevant entries in the primes table. * Change the API to: prime x [n] which finds the first n (default 1) primes larger than x. prime(10,3) --> [11, 13, 17] * If x is large, switch to a modern primality testing algorithm so that arbitrarily large primes can be found (perhaps for RSA purposes or some such). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870286&group_id=5470 From noreply at sourceforge.net Sun Jan 18 02:12:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 18 02:12:09 2004 Subject: [Patches] [ python-Patches-870287 ] Fix docstring for posixpath.getctime Message-ID: Patches item #870287, was opened at 2004-01-04 18:22 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Fix docstring for posixpath.getctime Initial Comment: (not sure whether this is "Library" or "Documentation") The docstring of posixpath.getctime calls ctime the "creation time". This is incorrect, because it is the "change time". The library documentation is correct here. This patch fixes the docstring. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-18 16:12 Message: Logged In: YES user_id=671362 Yes, your're right. The library document of os.path.ctime was fixed, but the docstring of posixpath.py has been left unchanged. So I'm +1 for applying this patch. I've noticed that there are still several places where the definition of ctime is not fixed. For example, stat.st_ctime and os.stat. http://www.python.org/doc/current/lib/module-stat.html > ST_CTIME : Time of last status change (see manual pages for details). http://www.python.org/doc/current/lib/os-file-dir.html > st_ctime (time of most recent content modification or metadata change). In my opinion, these two also need to be corrected. ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-01-17 23:55 Message: Logged In: YES user_id=13298 The docstring is a different issue: The standard library needs to be accurate for all platforms, whereas each platform has it's own implementation of os.path.getctime. Hence, it's possible to give each platform it's own docstring for os.path.getctime, so that posixpath.getctime.__doc__ != ntpath.getctime.__doc__. Is this it a good thing to have different docstrings? If so, I'd say that each platform documents for it's own getctime what ctime means. If not, I'd say we copy the standard library documentation. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-12 13:11 Message: Logged In: YES user_id=671362 > IIRC, it is creation time on some platforms and is the > change time on others. This was discussed before. [ 827902 ] ctime is not creation time http://www.python.org/sf/827902 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-12 08:32 Message: Logged In: YES user_id=80475 IIRC, it is creation time on some platforms and is the change time on others. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870287&group_id=5470 From infoHaugen at golfgod.net Sun Jan 18 07:15:12 2004 From: infoHaugen at golfgod.net (Psa-members) Date: Sun Jan 18 12:33:06 2004 Subject: [Patches] Info regarding vigra Message-ID: how Vigra? works. So you can better understand, what Vigra can do for you. If you are sensible about your health, reflect on what you can do for your seual health, to keep the chances that you will need Vigra as low as possible. fleecy connote Englewood, political. Inrease Seks Drive Bost Seual Performance Fuller & Harder Erecions Inrease Stamna & Endurance Quicker Rechages http://www.securemedpills.com/index.php?pid=pharmaboss combined denounces scrutiny, Morse. furnished outruns bricklayer, inhaler. Thanks, frightful From patches at python.org Sun Jan 18 22:38:08 2004 From: patches at python.org (Incest Advertiser) Date: Sun Jan 18 14:39:24 2004 Subject: [Patches] New Incest Site Message-ID: <30705656549.412529458101292@python.org> http://210.101.95.254/homeamuse/ ..Dad yanked off my little red silky panties and massaged my pussy rubbing my clit. Then without saying anything He rammed into me . He was so big I could feel him hit the back of my pussy. He was so rough and hard with me that I began to moan and he had to put his hand over my mouth to muffle the screams. He just kept going harder and harder until finally I came spilling my jucies all over my table. But still he kept going he wouldnt stop until he got what he wanted. Until finally he came too filling me full of jizz. I screamed and collapsed on the desk. We both re cooperated and i got redy to leave. As I was going out the door he called out to me,"Don't tell it to our mother"... <<<--------------------------------------------------------------------------------->>> There is a lot of examples of INCEST on our site. Want to see some real examples of what incest actually IS and to read about experiences of people involved? We have mega-tons of highest-quality images, real-life photos, videos and stories. Today we have more than 5500 members from miscellaneous country. http://210.101.95.254/homeamuse/ JOIN NOW to see new 2004 forbidden incest scenes! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040118/e4db4d55/attachment.html From noreply at sourceforge.net Mon Jan 19 06:10:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 19 06:10:15 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Tue Jan 20 08:17:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 20 08:17:24 2004 Subject: [Patches] [ python-Patches-880552 ] Fix typo in usage message(prechm.py) Message-ID: Patches item #880552, was opened at 2004-01-20 22:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880552&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: Fix typo in usage message(prechm.py) Initial Comment: The script name displayed in usage message of prechm.py is wrong. $ python prechm.py Usage: make_chm.py [-c] [-k] [-p] [-v 1.5[.x]] filename ~~~~~~~~~~~ [snip] Its original name was 'make_chm.py' but has been renamed to 'prechm.py'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880552&group_id=5470 From noreply at sourceforge.net Tue Jan 20 10:15:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 20 10:15:42 2004 Subject: [Patches] [ python-Patches-880621 ] incorrect end-of-message handling in mailbox.BabylMailbox Message-ID: Patches item #880621, was opened at 2004-01-20 15: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=880621&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: KAJIYAMA, Tamito (kajiyama) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect end-of-message handling in mailbox.BabylMailbox Initial Comment: The mailbox.BabylMailbox class does not handle end of message correctly. The last message in a mailbox ends in '\037' instead of '\037\014\n' (i.e. FF and LF do not exist at the end of the mailbox). However, the class in question does not take this special case into account, so that application programs get '\037' as the last line of the last message. Following is a simple fix of this bug: --- mailbox.py.orig Tue Jan 20 23:10:32 2004 +++ mailbox.py Tue Jan 20 23:08:17 2004 @@ -263,7 +263,7 @@ line = self.fp.readline() if not line: return - if line == '\037\014\n': + if line == '\037\014\n' or line == '\037': self.fp.seek(pos) return The bug is in Python 2.3.3 and probably all of older versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880621&group_id=5470 From noreply at sourceforge.net Tue Jan 20 15:46:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 20 15:46:56 2004 Subject: [Patches] [ python-Patches-873418 ] email/Message.py: del_param fails when specifying a header Message-ID: Patches item #873418, was opened at 2004-01-08 19:08 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873418&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/Message.py: del_param fails when specifying a header Initial Comment: [forwarded from http://bugs.debian.org/225421] Consider the following code: import email.Message msg = email.Message.Message() msg.add_header('Content-Disposition', 'attachment', filename='bud.gif') msg.del_param('filename', 'Content-Disposition') According to the documentation, this should be the correct syntax. However, ValueError is raised in del_param. Traceback (most recent call last): File "pybug.py", line 4, in ? msg.del_param('filename', 'Content-Disposition') File "/usr/lib/python2.3/email/Message.py", line 675, in del_param for p, v in self.get_params(header, unquote=requote): ValueError: need more than 1 value to unpack It seems to me like a simple mistake of the argument order in the get_params call. The included patch fixes it, at least my program works again (maybe the same mistake is made in more places). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=873418&group_id=5470 From noreply at sourceforge.net Tue Jan 20 15:52:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 20 15:52:25 2004 Subject: [Patches] [ python-Patches-866982 ] Bad behavior of email.Charset.Charset when locale is tr_TR Message-ID: Patches item #866982, was opened at 2003-12-29 05:29 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Matthias Klose (doko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Bad behavior of email.Charset.Charset when locale is tr_TR Initial Comment: Charset class' behaviour is bad when locale is set to tr_TR. The problems's source is input_charset = input_charset.lower() at line 393 of /usr/lib/python2.3/email/Charset.py . This exeample code can reproduce the error: import locale from email.Charset import Charset locale.setlocale(locale.LC_ALL,("tr_TR","ISO-8859-9")) foo = Charset(locale.nl_langinfo(locale.CODESET)) repr(foo) #Returns \xfdso-8859-9 which is not a charset instead of iso-8859-9 The problem exists because the lower() of I in turkish charset is ? (\xfd), not i. I will try to create and submit a patch ASAP. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-12-29 12:29 Message: Logged In: YES user_id=21627 See the python-dev discussion. My proposal is to add ascii_lower to , and use that. Charset.py might then use your code as a fallback. Actually, it might be even more performant to do lower_map = string.maketrans(string.ascii_upper, string.ascii_lower) def _ascii_lower(str): return str.translate(lower_map) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=866982&group_id=5470 From noreply at sourceforge.net Wed Jan 21 09:14:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 21 09:14:31 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Wed Jan 21 13:13:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 21 13:13:57 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 12:10 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-01-21 18:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 14:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 11:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 03:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 01:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-08 18:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 05:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 04:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 12:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Wed Jan 21 13:32:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 21 13:32:23 2004 Subject: [Patches] [ python-Patches-871402 ] add link to DDJ's article Message-ID: Patches item #871402, was opened at 2004-01-05 21:46 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 Category: Documentation Group: Python 2.2.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: add link to DDJ's article Initial Comment: The document of difflib refers to an article published by DDJ. www.python.org/doc/current/lib/module-difflib.html http://www.ddj.com/ "Pattern Matching: The Gestalt Approach" by John W. Ratcliff & D. E. Metzener Luckily, this article is available on DDJ's site, so why not add a link to that URI? # http://www.ddj.com/articles/1988/8807/ # http://www.ddj.com/documents/s=1103/ddj8807c/ ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-01-21 13:32 Message: Logged In: YES user_id=3066 I've committed the change as Doc/lib/libdifflib.tex revisions 1.17 and 1.15.10.1. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-11 18:35 Message: Logged In: YES user_id=80475 Usually, we don't put in links unless pretty sure that the link will remain valid for a long time. The DDJ site is relatively stable, but it is still a judgement call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=871402&group_id=5470 From noreply at sourceforge.net Wed Jan 21 14:28:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 21 14:28:37 2004 Subject: [Patches] [ python-Patches-778323 ] Tk Dialog Upon Subprocess Socket Error Message-ID: Patches item #778323, was opened at 2003-07-26 23:13 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=778323&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 6 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Tk Dialog Upon Subprocess Socket Error Initial Comment: Alex Martelli identified a problem on a particular machine which was unable to start IDLE's subprocess if not connected to the Internet. The user was not receiving any error message. This patch raises a Tk error box and also adds a timeout to the listening socket so that a stuck process is not left behind. See discussion on Python-dev 26July03. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2004-01-21 14:28 Message: Logged In: YES user_id=149084 checked in an enhanced version of sockerr.patch. cf. http://mail.python.org/pipermail/python-checkins/2004-January/039597. html for details. PyShell 1.84 ScriptBinding 1.26 run 1.28 BACKPORT CANDIDATE ---------------------------------------------------------------------- Comment By: Aahz (aahz) Date: 2003-07-28 13:13 Message: Logged In: YES user_id=175591 bugs.ht updated ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 10:55 Message: Logged In: YES user_id=12800 Postponing until 2.3.1. Too much code change before 2.3 final. Assigning to Aahz so he can add appropriate text to pydotorg's 2.3/bugs.ht file. We'll call this a known bug in 2.3 to be fixed in 2.3.1. Also, lowering the priority. Aahz, once you've made the change to bugs.ht, please re-assign to Kurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=778323&group_id=5470 From noreply at sourceforge.net Wed Jan 21 15:30:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 21 15:30:26 2004 Subject: [Patches] [ python-Patches-881676 ] logging says to call shutdown - make it more likely Message-ID: Patches item #881676, was opened at 2004-01-21 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=881676&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: logging says to call shutdown - make it more likely Initial Comment: The logging module says (in the code) that logging. shutdown() should be called at application exit, but there is no way to enforce this -- particularly with an interactive session. Calling it twice leads to errors. This patch (1) Makes it safe to call shutdown more than once. (2) Uses atexit (with a workaround for Python 1.5) to flush and close buffers automatically when the system is shutting down normally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881676&group_id=5470 From noreply at sourceforge.net Wed Jan 21 18:35:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 21 18:35:15 2004 Subject: [Patches] [ python-Patches-881820 ] look in libbsd.a also for openpty and forkpty Message-ID: Patches item #881820, was opened at 2004-01-21 23:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881820&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Dyck (dcd) Assigned to: Nobody/Anonymous (nobody) Summary: look in libbsd.a also for openpty and forkpty Initial Comment: fix bug [ 880996 ] 2.3.3 make fails build posix_openpty' where libbsd.a contains openpty (and forkpty) instead of libutil.a. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881820&group_id=5470 From allaugh at wongfaye.com Wed Jan 21 06:32:48 2004 From: allaugh at wongfaye.com (Greg) Date: Thu Jan 22 08:31:51 2004 Subject: [Patches] nesws regarding vigros Bretons Message-ID: simplest, How Vigras works. And you can better understand, what Vigras can do for you. If you are sensible about your health, reflect on what you can do for your seual health, to keep the chances that you will need Vigras as low as possible. dancers circuitous bleats, relented. http://www.effectiveherbs.com/index.php?pid=genviag Inrease Seks Drive Bost Seual Performance Fuller & Harder Erecions Inrease Stamna & Endurance Quicker Rechages conspire Syrianizes plucking, genders. Burch soles Georgia, prophetic. Happy holidays, Goethe From vwluimylyblmo at yahoo.com Sat Jan 24 06:45:37 2004 From: vwluimylyblmo at yahoo.com (Ivan Dolan) Date: Fri Jan 23 16:55:43 2004 Subject: [Patches] dilapidate bar calcutta foray bowstring macrostructure caddy chastity speak intensify franciscan jack resonate stew button friar snout stella downtown fanny alberta dim travesty presence allergy brinkmanship agricola officeholder stepmother keddah comb hurst deuce sumerian carbonate osmosis caress Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040124/f4e3b1d2/attachment.html From noreply at sourceforge.net Sun Jan 25 01:45:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 25 01:45:47 2004 Subject: [Patches] [ python-Patches-884022 ] dynamic execution profiling vs opcode prediction Message-ID: Patches item #884022, was opened at 2004-01-25 17: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=884022&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) Assigned to: Nobody/Anonymous (nobody) Summary: dynamic execution profiling vs opcode prediction Initial Comment: This patch is a proposed fix/work around for bug #884020. It disables opcode prediction when dynamic execution profiling is in effect, so the profiling counters at the top of the main interpreter loop in eval_frame() are updated for each opcode. It does give rise to warnings about unused labels (with gcc anyway) which could be resolved by #define'ing all the prediction machinery away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=884022&group_id=5470 From noreply at sourceforge.net Sun Jan 25 16:03:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 25 16:03:11 2004 Subject: [Patches] [ python-Patches-884022 ] dynamic execution profiling vs opcode prediction Message-ID: Patches item #884022, was opened at 2004-01-25 01:45 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=884022&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew I MacIntyre (aimacintyre) >Assigned to: Raymond Hettinger (rhettinger) Summary: dynamic execution profiling vs opcode prediction Initial Comment: This patch is a proposed fix/work around for bug #884020. It disables opcode prediction when dynamic execution profiling is in effect, so the profiling counters at the top of the main interpreter loop in eval_frame() are updated for each opcode. It does give rise to warnings about unused labels (with gcc anyway) which could be resolved by #define'ing all the prediction machinery away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=884022&group_id=5470 From noreply at sourceforge.net Sun Jan 25 16:04:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 25 16:05:28 2004 Subject: [Patches] [ python-Patches-881676 ] logging says to call shutdown - make it more likely Message-ID: Patches item #881676, was opened at 2004-01-21 15:30 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881676&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Vinay Sajip (vsajip) Summary: logging says to call shutdown - make it more likely Initial Comment: The logging module says (in the code) that logging. shutdown() should be called at application exit, but there is no way to enforce this -- particularly with an interactive session. Calling it twice leads to errors. This patch (1) Makes it safe to call shutdown more than once. (2) Uses atexit (with a workaround for Python 1.5) to flush and close buffers automatically when the system is shutting down normally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881676&group_id=5470 From noreply at sourceforge.net Sun Jan 25 16:05:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 25 16:13:11 2004 Subject: [Patches] [ python-Patches-880552 ] Fix typo in usage message(prechm.py) Message-ID: Patches item #880552, was opened at 2004-01-20 08:17 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880552&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix typo in usage message(prechm.py) Initial Comment: The script name displayed in usage message of prechm.py is wrong. $ python prechm.py Usage: make_chm.py [-c] [-k] [-p] [-v 1.5[.x]] filename ~~~~~~~~~~~ [snip] Its original name was 'make_chm.py' but has been renamed to 'prechm.py'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=880552&group_id=5470 From noreply at sourceforge.net Sun Jan 25 18:44:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 25 18:44:07 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 08:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-22 03:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Sun Jan 25 22:17:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Jan 25 22:17:38 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 10:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: M.-A. Lemburg (lemburg) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-01-25 22:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Mon Jan 26 01:17:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 01:17:15 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 15:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 08:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-22 03:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Mon Jan 26 10:15:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 10:16:01 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 12:10 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-01-26 15:15 Message: Logged In: YES user_id=4771 >>> (a for d in a) Fatal Python error: unknown scope for a in (1) in symbols: {'a': 2048, '_[1]': 4, 'd': 2} locals: {'_[1]': 0, 'd': 1} globals: {} ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 06:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-25 23:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-21 18:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 14:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 11:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 03:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 01:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-08 18:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 05:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 04:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 12:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Mon Jan 26 13:36:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 13:36:25 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: M.-A. Lemburg (lemburg) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Mon Jan 26 15:11:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 15:11:33 2004 Subject: [Patches] [ python-Patches-885008 ] Erroneous error message in test_types Message-ID: Patches item #885008, was opened at 2004-01-26 21: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=885008&group_id=5470 Category: Tests Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous error message in test_types Initial Comment: test_types.py states: if 1 and 1: pass else: raise TestFailed, '1 and 1 is false instead of false' I think this should be: if 1 and 1: pass else: raise TestFailed, '1 and 1 is false instead of true' This patch changes this. (BTW, shouldn't "if True:" and "if False:" also be here? I didn't add it to the patch, because I'm not sure and it's no work to add, so just notifying should be enough if the should be there) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885008&group_id=5470 From noreply at sourceforge.net Mon Jan 26 15:46:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 15:46:12 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 16:20 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: M.-A. Lemburg (lemburg) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 21:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 19:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-26 04:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Mon Jan 26 16:02:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 16:07:22 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 08:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: M.-A. Lemburg (lemburg) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 14:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 13:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 11:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-25 20:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Mon Jan 26 20:15:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Jan 26 20:18:17 2004 Subject: [Patches] [ python-Patches-712317 ] Bug fix 548176: urlparse('http://foo?blah') errs Message-ID: Patches item #712317, was opened at 2003-03-30 12:16 Message generated for change (Comment added) made by mrovner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712317&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: Bug fix 548176: urlparse('http://foo?blah') errs Initial Comment: For detailed description of the problem, see http://www.python.org/sf/548176 In summary, URLs such as http://www.example.com?query=spam are misparsed by urlparse.urlparse, which decides that everything after the '//' is the host name. This is contrary to RFC 2396 and probably contrary to the intent of RFC 1738. The patch corrects the problem, adds a test to expose it, and rearranges some of the tests to better exercise the code in question. ---------------------------------------------------------------------- Comment By: Mike Rovner (mrovner) Date: 2004-01-26 17:15 Message: Logged In: YES user_id=162094 -1. See my comment at http://www.python.org/sf/548176 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=712317&group_id=5470 From noreply at sourceforge.net Tue Jan 27 02:44:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 27 02:44:24 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2004-01-27 16:44 Message: Logged In: YES user_id=595483 I fixed the patch for the bug that arigo mentioned, and for what perky mentioned - PyList_GetSlice error handling - . now, I'll tackle python compiler package :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-27 00:15 Message: Logged In: YES user_id=4771 >>> (a for d in a) Fatal Python error: unknown scope for a in (1) in symbols: {'a': 2048, '_[1]': 4, 'd': 2} locals: {'_[1]': 0, 'd': 1} globals: {} ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 15:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 08:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-22 03:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Tue Jan 27 12:03:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 27 12:03:15 2004 Subject: [Patches] [ python-Patches-876206 ] scary frame speed hacks Message-ID: Patches item #876206, was opened at 2004-01-13 16:49 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: scary frame speed hacks Initial Comment: In ceval.c we find /* XXX Perhaps we should create a specialized PyFrame_New() that doesn't take locals, but does take builtins without sanity checking them. */ This patch takes that idea rather further than you might have expected... it creates a "light" subtype of frame that assumes certain things about the frame, gives this type its own free list (so it can assume more about objects on the freelist) and converts light frames into "heavy" frames when assumptions stop being true. Good for a ~5% improvement on "./python -s 'def f(): pass' 'f()'"; a bit less on pystone. It also conflicts slightly with my function reorg patch -- apply that first, apply this, ignore the reject and edit func_caller_nofrees in funcobject.c to call PyFrame_NewLight. All three patches I just submitted together get ~6% on pystone. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2004-01-27 17:03 Message: Logged In: YES user_id=4771 Here is yet another try, which seems to perform better on my PentiumIII. I get the following speed improvements for this patch alone, for a loop calling an empty function: zombie-frames.diff: 11.4% (PyStone 3.8%) scary-frame-hacks.diff: 6.4% (PyStone 0.85%) The idea is to get rid of the free_list and instead store the most recently finished ("zombie") frame in an internal field of the code object. This saves half of the frame creation overhead because half of the fields are already correct when the frame is reused, e.g. f_code, f_nlocals, f_stacksize, f_valuestack... (you might need to cvs up frameobject.c before you can apply the patch) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-15 11:02 Message: Logged In: YES user_id=6656 I'm fairly sure this made a difference on my iBook; haven't tried on x86. It's possible that the correct response to this patch is to add "... nah, not worth it" to the XXX comment in ceval.c... ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-14 17:35 Message: Logged In: YES user_id=4771 (Side note first: I'm not sure 'builtins = back->f_builtins' is right.) Is the whole subclassing complexity worth the effort, given that the invariants of light frames only seem to be that four specific fields are null? Changing the type of an object under Python code's feet is calling for troubles. Moreover it is bound to break code that expect 'type(frame)==FrameType', even if such code can be considered bad style. Moreover it requires a number of hacks here and there -- e.g. you turn a light frame into a "heavy" frame when f_trace is set; is it on purpose that you don't do it when f_locals is set? I cannot seem to get reliable performance results on my machine, but maybe you want to compare with the attached patch which speeds up the regular PyFrame_New by putting stronger invariants on all the frames in the free_list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-13 18:23 Message: Logged In: YES user_id=6656 sigh ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2004-01-13 18:20 Message: Logged In: YES user_id=31392 I don't see any files attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876206&group_id=5470 From noreply at sourceforge.net Tue Jan 27 19:35:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Jan 27 19:35:51 2004 Subject: [Patches] [ python-Patches-885905 ] _socket fails to build with latest SGI compiler Message-ID: Patches item #885905, was opened at 2004-01-27 16:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885905&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: _socket fails to build with latest SGI compiler Initial Comment: The Python 2.3 mechanism of defining _POSIX_C_SOURCE et. al. prevents configure from finding everything. It kind of worked for the SGI 7.3 compilers, but always fails for the 7.4 compilers. With the patch the gross ifdef in socketmodule.c that defines _SGIAPI is not used and likewise for various other ifdef __sgi's. Since they are not used anymore, I didn't remove them in this patch. Attached is a patch to configure.in that eliminates the various _SOURCE defines on IRIX and works with both the 7.3.1.2m and 7.4.1m compilers. The same patch can be applied to configure for those who don't have autoconf working on their system. - Greg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885905&group_id=5470 From noreply at sourceforge.net Wed Jan 28 06:49:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 28 06:49:13 2004 Subject: [Patches] [ python-Patches-876130 ] add C API to datetime module Message-ID: Patches item #876130, was opened at 2004-01-13 16:20 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: M.-A. Lemburg (lemburg) Summary: add C API to datetime module Initial Comment: The datetime module does not have a C API which means that modules written in C cannot take advantage of the datetime module without incurring significant overhead. These patches supply this lack and are based on the C API exported by the mxDateTime module and the cStringIO module and enhanced as suggested by Guido. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 12:49 Message: Logged In: YES user_id=38388 Thanks for the clarification. I had forgotten about the macros -- I'd suggest that you document them in the datetimeapi.h include file to not cause the same confusion on the developer side (the trick to achieve adoption is to make things easy on the developer). As for TimeFromTicks(): This should be rather straight forward to implement: you take the time part of the ticks timestamp and create a time object from it. This is the way the DB API constructor works. Could you add C APIs for the three DB API ticks interface methods ? Other things that are missing: * documentation of the way the CAPI object can be used in datetimeapi.h * documentation of the various CAPI entries * documentation of the API magic number (there should be some scheme for this) I think that datetimeapi.h should be enough for a developer to read in order to use the interface. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 22:02 Message: Logged In: YES user_id=619560 I didn't think any additional API would be necessary for extracting date time information since the following macros are available: PyDateTime_GET_YEAR(o) PyDateTime_GET_MONTH(o) PyDateTime_GET_DAY(o) PyDateTime_DATE_GET_HOUR(o) PyDateTime_DATE_GET_MINUTE(o) PyDateTime_DATE_GET_SECOND(o) PyDateTime_DATE_GET_MICROSECOND(o) PyDateTime_TIME_GET_HOUR(o) PyDateTime_TIME_GET_MINUTE(o) PyDateTime_TIME_GET_SECOND(o) PyDateTime_TIME_GET_MICROSECOND(o) Were you thinking of something else that is needed? As for interfacing at the C level for converting from Unix ticks, the following method is already available and could simply be used as a drop in replacement for DateFromTicks() and TimestampFromTicks() from the DB API document. DateFromTicks() --> datetime.date.fromtimestamp() TimestampFromTicks() --> datetime.datetime.fromtimestamp() TimeFromTicks() is not already exposed but discussions with Tim Peters already suggested that would not happen since the concept is rather strange. You'll have to discuss that with him if you disagree! :-) Any comments? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-26 21:46 Message: Logged In: YES user_id=38388 This is a good start. However, you should add more APIs for extracting date/time information to the C API. mxDateTime.h from egenix-mx-base can provide a good basis for this. If you want to make the datetime module usable for database interfacing at C level, you'll also have to add interfaces for Unix ticks conversion, since these are often used by database C level interfaces. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-01-26 19:36 Message: Logged In: YES user_id=619560 I have no objection to providing patches for doc and test. A quick look at _testcapimodule.c doesn't provide any obvious ideas as to how to patch it. I looked for cStringIO which has a C API already and found nothing in there at all. The documentation also simply says "see the source for the information you require". Any suggestions as to how to proceed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-26 04:17 Message: Logged In: YES user_id=31435 Marc-Andre, can you review this? I think you have more experience building C APIs for modules than anyone else (while I don't have any). There's certainly no objection to giving datetime a C API, and Guido already said he doesn't want to rely on that Martin changed datetime to be built as part of the core (in 2.3 on Windows, datetime.pyd was a distinct DLL; in CVS, datetime is compiled into the core DLL now). Anthony, you probably need to add doc and test patches. _testcapimodule.c holds tests of things you can only get at from C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876130&group_id=5470 From noreply at sourceforge.net Wed Jan 28 18:20:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Jan 28 18:20:20 2004 Subject: [Patches] [ python-Patches-885905 ] _socket fails to build with latest SGI compiler Message-ID: Patches item #885905, was opened at 2004-01-28 01:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885905&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: _socket fails to build with latest SGI compiler Initial Comment: The Python 2.3 mechanism of defining _POSIX_C_SOURCE et. al. prevents configure from finding everything. It kind of worked for the SGI 7.3 compilers, but always fails for the 7.4 compilers. With the patch the gross ifdef in socketmodule.c that defines _SGIAPI is not used and likewise for various other ifdef __sgi's. Since they are not used anymore, I didn't remove them in this patch. Attached is a patch to configure.in that eliminates the various _SOURCE defines on IRIX and works with both the 7.3.1.2m and 7.4.1m compilers. The same patch can be applied to configure for those who don't have autoconf working on their system. - Greg ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-29 00:20 Message: Logged In: YES user_id=21627 This patch is inappropriate. Can you please explain why defining _POSIX_C_SOURCE prevents configure from finding everything? If you are certain that IRIX is so broken that you cannot compile conforming POSIX programs, please use the facility define_xopen_source to disable POSIX. Make sure you list your name and a specific problem; "cannot compile socketmodule" would not be specific, but "struct foo is defined twice, once in bar.h and once in foobar.h" would be specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885905&group_id=5470 From noreply at sourceforge.net Thu Jan 29 06:48:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 29 06:48:43 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-29 20:48 Message: Logged In: YES user_id=671362 yet another Fatal Python error; >>> (a for a in (b for b in (0,1))) >>> (a for a in (b for b in range(2))) Fatal Python error: unknown scope for range in ?(0) in symbols: {'range': 8} locals: {} globals: {} Aborted # applied patch as of 2004-01-27 ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-27 16:44 Message: Logged In: YES user_id=595483 I fixed the patch for the bug that arigo mentioned, and for what perky mentioned - PyList_GetSlice error handling - . now, I'll tackle python compiler package :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-27 00:15 Message: Logged In: YES user_id=4771 >>> (a for d in a) Fatal Python error: unknown scope for a in (1) in symbols: {'a': 2048, '_[1]': 4, 'd': 2} locals: {'_[1]': 0, 'd': 1} globals: {} ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 15:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 08:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-22 03:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Thu Jan 29 22:01:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Jan 29 22:01:21 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by jiwon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Jiwon Seo (jiwon) Date: 2004-01-30 12:01 Message: Logged In: YES user_id=595483 ok, I've fixed the bug quiver commented, and added related test code to test_grammar.py. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-29 20:48 Message: Logged In: YES user_id=671362 yet another Fatal Python error; >>> (a for a in (b for b in (0,1))) >>> (a for a in (b for b in range(2))) Fatal Python error: unknown scope for range in ?(0) in symbols: {'range': 8} locals: {} globals: {} Aborted # applied patch as of 2004-01-27 ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-27 16:44 Message: Logged In: YES user_id=595483 I fixed the patch for the bug that arigo mentioned, and for what perky mentioned - PyList_GetSlice error handling - . now, I'll tackle python compiler package :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-27 00:15 Message: Logged In: YES user_id=4771 >>> (a for d in a) Fatal Python error: unknown scope for a in (1) in symbols: {'a': 2048, '_[1]': 4, 'd': 2} locals: {'_[1]': 0, 'd': 1} globals: {} ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 15:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 08:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-22 03:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Fri Jan 30 00:09:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 00:09:17 2004 Subject: [Patches] [ python-Patches-872326 ] generator expression implementation Message-ID: Patches item #872326, was opened at 2004-01-07 21:10 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jiwon Seo (jiwon) Assigned to: Hye-Shik Chang (perky) Summary: generator expression implementation Initial Comment: Since I was interested in pep 289(generator expression), I dabbled with it, and implemented a working version of it. I'm not sure if I did it right, but maybe someone who knows better can fix it right. 1. Grammar has two changes, which is a. atom: '(' [testlist] ')' | '[' [listmaker] ']' | ... changes to atom: '(' [testgenexpr] ')' | '[' [listmaker] ']' | ... where testgenexpr defines like this. testgenexpr: test ( gen_for | (',' test)* [','] ) b. argument: [test '='] test changes to argument: [test '='] test [gen_for] (gen_for, gen_if, gen_iter is similar to list_for, list_if, list_iter respectively.) 2. Instead of changing rule of arglist in Grammar to accept generator expression, I changed argument rule like 1.b. This means Grammar accepts generator expression without parenthesis in function call even there are several arguments, like reduce(operator.add, (x for x in range(10))) This is against what pep requires, so I made parsermodule.c and compile.c to catch that and throw error message when there's more than one argument in a function. The reason I did it that way is to go around a problem of ambiguity in the grammar by adding generator expression to arglist. 3. I implemented generator expression as equivalent to a call to a function which has variable capturing code and generator code. For example, x = 1 g = (x for i in range(10)) is equivalent to x = 1 def __gen_wrapper(): _[x] = x # variable capture here def __gen(): for i in range(10): yield _[x] return __gen() g = __gen_wrapper() 4. Since I implemented generator expression equivalent to a function call, symbol table should enter new scope when it meets generator expression. So I ended up with adding following code to symtable.c PyObject * PySymtableEntry_New(struct symtable *st, char *name, int type, int lineno) { ... switch (type) { case funcdef: case lambdef: ! case testgenexpr: /* generator expression */ ! case argument: /* generator expression */ ste->ste_type = TYPE_FUNCTION; break; ... so that generator expression can be dealt as function type. This is kind of stupid, but I couldn't find other easy for it, so I just left it like that. 5. this patch does not include diff of src/Lib/symbol.py, so you must run python Lib/symbol.py to get it right. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-01-30 14:09 Message: Logged In: YES user_id=55188 Yet another Fatal Python error; >>> (a for a in (b for b in (a for a in 'xxx' if True) if False) if True) lookup 'True' in ? 3 -1 freevars of : ('True',) Fatal Python error: com_make_closure() zsh: abort (core dumped) ./python # applied patch as of 2004-01-30 ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-30 12:01 Message: Logged In: YES user_id=595483 ok, I've fixed the bug quiver commented, and added related test code to test_grammar.py. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-01-29 20:48 Message: Logged In: YES user_id=671362 yet another Fatal Python error; >>> (a for a in (b for b in (0,1))) >>> (a for a in (b for b in range(2))) Fatal Python error: unknown scope for range in ?(0) in symbols: {'range': 8} locals: {} globals: {} Aborted # applied patch as of 2004-01-27 ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-27 16:44 Message: Logged In: YES user_id=595483 I fixed the patch for the bug that arigo mentioned, and for what perky mentioned - PyList_GetSlice error handling - . now, I'll tackle python compiler package :) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-27 00:15 Message: Logged In: YES user_id=4771 >>> (a for d in a) Fatal Python error: unknown scope for a in (1) in symbols: {'a': 2048, '_[1]': 4, 'd': 2} locals: {'_[1]': 0, 'd': 1} globals: {} ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 15:17 Message: Logged In: YES user_id=55188 Please ignore the previous comment. It was a result from an old revision of patches. It works on the recent. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-26 08:44 Message: Logged In: YES user_id=55188 BTW, does unavaliability of yield (genexpr) and return (genexpr) an intended behavior? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-01-22 03:13 Message: Logged In: YES user_id=6656 Documentation would be nice! ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-21 23:14 Message: Logged In: YES user_id=55188 Okay. My review is done. The revised patch "gexp.diff" looks fine for me. There're few minor tweaks still needed to get into CVS. - Some error exit cases are ignored. You need to provide safe exit paths for MemoryError. (eg. PyList_GetSlice usage of Python/ compiler.c) - A patch for 'compiler' pure python package. (there's an old implementation on SF #795947) ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-19 20:10 Message: Logged In: YES user_id=595483 ok. I modified the patch so that it evaluates iterator expr in generator expression creation time. That means, g = (x for x in range(10)) is equivalent to def __gen(iter1): for x in iter1: yield x g = __gen(range(10)) so, evalution of range(10) is not deferred anymore. I also changed testgenexpr to testlist_gexp in Grammar/Grammar, since Hye-Shik Chang advised as such. I'm willing to take any advice about this patch, so please do. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-12 12:26 Message: Logged In: YES user_id=595483 ok. I've implemented capturing variables part as arigo suggested. File genexpr-capture-vars-in-args.diff is that. If you look at the code, you'll find that the code for generator expression is much shorter, and there's lesser modification in the existing code. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-09 10:49 Message: Logged In: YES user_id=595483 What arigo wrote sounds reasonable, and not very difficult to implement. I'll try to do that way. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-01-09 03:50 Message: Logged In: YES user_id=4771 We may not need two levels of nested anonymous functions. It seems to me that the following equivalent code would do, because it captures the variable in an argument instead of via nested scopes: x = 1 def __gen(x): for i in range(10): yield x g = __gen(x) I don't know though if this is easy to implement in compile.c. Alternatively: x = 1 def __gen(x=x): for i in range(10): yield x g = __gen() ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-08 14:44 Message: Logged In: YES user_id=55188 Okay. I verified that basic characteristics mentioned on PEP are working. I started to review the implementation. ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-01-08 13:50 Message: Logged In: YES user_id=595483 I added diff of Lib/symbol.py, so no need to run python Lib/symbol.py now. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-07 21:25 Message: Logged In: YES user_id=55188 Assigned to me. The originator is my friend and I have much interest on this. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=872326&group_id=5470 From noreply at sourceforge.net Fri Jan 30 12:29:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Jan 30 12:29:53 2004 Subject: [Patches] [ python-Patches-562100 ] Installation database patch Message-ID: Patches item #562100, was opened at 2002-05-29 17:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470 Category: Distutils and setup.py Group: None >Status: Open >Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: A.M. Kuchling (akuchling) Summary: Installation database patch Initial Comment: The attached patch implements an installation database. This patch is not yet correct; don't bother proofreading it yet. I simply wanted to create a patch number so I could put it in PEP 262. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2004-01-30 12:29 Message: Logged In: YES user_id=11375 Reviving this patch. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-10-03 16:19 Message: Logged In: YES user_id=139309 This should be brought back into play (patch finished, PEP heavily considered, or however that goes), the Package Manager effort going on in pythonmac-sig needs this functionality as part of distutils. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-10-24 15:13 Message: Logged In: YES user_id=11375 Closing this patch with the withdrawal of PEP 262. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=562100&group_id=5470 From noreply at sourceforge.net Sat Jan 31 07:36:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 07:36:33 2004 Subject: [Patches] [ python-Patches-874083 ] Bluetooth support for socket module Message-ID: Patches item #874083, was opened at 2004-01-09 22:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 Category: Modules Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Frederik Fix (frederikfix) Assigned to: Nobody/Anonymous (nobody) Summary: Bluetooth support for socket module Initial Comment: This patch adds support for Bluetooth sockets to the socket module. It supports the L2CAP, RFCOMM and SCO protocols. I have tested it on Linux 2.6.0 with the built-in Bluetooth stack. I have only tested server sockets, but client sockets should work just the same. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-31 13:36 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as configure 1.437 configure.in 1.448 pyconfig.h.in 1.91 ACKS 1.258 NEWS 1.925 socketmodule.c 1.282 socketmodule.h 1.10 ---------------------------------------------------------------------- Comment By: Frederik Fix (frederikfix) Date: 2004-01-13 10:07 Message: Logged In: YES user_id=947584 SCO in this case stands for Synchronous Connection-oriented protocol. It's one of the protocols that can be layered on top of Bluetooth. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-01-12 20:19 Message: Logged In: YES user_id=6380 Looks reasonable to me, except the mention of SCO raises a red flag. Is this the same SCO that is sueing Linux? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=874083&group_id=5470 From noreply at sourceforge.net Sat Jan 31 07:39:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 07:39:34 2004 Subject: [Patches] [ python-Patches-870807 ] optparse int, long types support binary, octal and hex forma Message-ID: Patches item #870807, was opened at 2004-01-05 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=870807&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: optparse int, long types support binary, octal and hex forma Initial Comment: Hello, I've added support for binary, octal and hexa number with the "int" and "long" types. binary : 0b10 (= 2) octal : 010 (= 8) hexa: 0x10 (= 16) Diff for optparse.py and test_optparse.py attached. Miki. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-31 13:39 Message: Logged In: YES user_id=21627 Can you please provide a patch for Doc/lib/liboptparse.tex as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=870807&group_id=5470 From noreply at sourceforge.net Sat Jan 31 07:44:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 07:44:43 2004 Subject: [Patches] [ python-Patches-849278 ] improve embeddability of python Message-ID: Patches item #849278, was opened at 2003-11-25 23:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: improve embeddability of python Initial Comment: Add PyInitializeX that omits check in environment variables to set debugging, optimize, and verbose flags. Add PySetSysPaths to specify location of modules and the prefixes and the full path. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-01-31 13:44 Message: Logged In: YES user_id=21627 Can you please provide patches for the documentation as well? What is the change to Makefile.pre.in? ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-12-11 21:21 Message: Logged In: YES user_id=876734 Here are the Windows patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 From noreply at sourceforge.net Sat Jan 31 07:55:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 07:56:01 2004 Subject: [Patches] [ python-Patches-849262 ] 832799 proposed changes Message-ID: Patches item #849262, was opened at 2003-11-25 22:25 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) >Assigned to: Martin v. L?wis (loewis) Summary: 832799 proposed changes Initial Comment: 1) allow a subclass of build_ext.py to specify global extra_link_args in addition to the per-ext ones. 2) make the toplevel setup.py set this as specified by an environment var. 3) Make Makefile.pre.in set this up when building shared libs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849262&group_id=5470 From noreply at sourceforge.net Sat Jan 31 09:32:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 09:32:07 2004 Subject: [Patches] [ python-Patches-888148 ] Bluetooth support for FreeBSD systems. Message-ID: Patches item #888148, was opened at 2004-01-31 23: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=888148&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Nobody/Anonymous (nobody) Summary: Bluetooth support for FreeBSD systems. Initial Comment: Attached patch tunes socketmodule for FreeBSD support of bluetooth. FreeBSD supports SCO via HCI, but the current implementation can't be adapted to it readily yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888148&group_id=5470 From noreply at sourceforge.net Sat Jan 31 19:44:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Jan 31 19:44:33 2004 Subject: [Patches] [ python-Patches-888380 ] popen2.popen2() 'cmd' list syntax docstring Message-ID: Patches item #888380, was opened at 2004-01-31 16: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=888380&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Connelly (jeffconnelly) Assigned to: Nobody/Anonymous (nobody) Summary: popen2.popen2() 'cmd' list syntax docstring Initial Comment: This simple patch documents using popen2() with a list as the first argument. Currently this feature is not documented. It is good practice to use the list-popen2 as it avoids shell interpretation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888380&group_id=5470