From noreply at sourceforge.net Sun Feb 1 00:46:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 00:46:28 2004 Subject: [Patches] [ python-Patches-876178 ] input() vs __future__ Message-ID: Patches item #876178, was opened at 2004-01-14 01:17 Message generated for change (Comment added) made by perky 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. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-02-01 14:46 Message: Logged In: YES user_id=55188 I wrote a unittest. How's this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876178&group_id=5470 From noreply at sourceforge.net Sun Feb 1 05:10:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 05:10:40 2004 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Comment added) made by gerrit 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: Gerrit Holl (gerrit) Date: 2004-02-01 11:10 Message: Logged In: YES user_id=13298 Raymond Hettinger asked me if I could do a second review for this patch, so I did. I found three errors. The first one is in Lib/lib-old/codehack.py. It's a mistake that the change is there at all. The second one in in Lib/plat-mac/aetypes.py where a 'r' is missing. The third and last one is in Tools/scripts/methfix.py. Here, a variable is printed twice. First one: - key = `co` # arbitrary but uniquely identifying string + key = co` # arbitrary but uniquely identifying string Second one: - return "QDRectangle(%s, %s, %s, %s)" % (`self.v0`, `self.h0`, - `self.v1`, `self.h1`) + return "QDRectangle(%r, %r, %r, %)" % (self.v0, self.h0, self.v1, self.h1) Third one: - err(tempname + ': warning: chmod failed (' + `msg` + ')\n') + err(tempname + '%s: warning: chmod failed (%r)\n' % (tempname, msg)) # Then make a backup of the original file as filename~ try: os.rename(filename, filename + '~') except os.error, msg: - err(filename + ': warning: backup failed (' + `msg` + ')\n') + err(filename + '%s: warning: backup failed (%r)\n' % (filename, msg)) # Now move the temp file to the original file try: os.rename(tempname, filename) except os.error, msg: - err(filename + ': rename failed (' + `msg` + ')\n') + err(filename + '%s: rename failed (%r)\n' % (filename, msg)) Attached is a meta-patch containing the differences between the original backticks2repr.txt which contains some errors, and the one with the errors removed. Note that I did not run any test suite or something like that, because I understand that had already been done. Other things I noticed: - sometimes this patch uses "foo %r bar" % baz, sometimes "foo %r bar" % (baz,), and sometimes "foo " + repr(baz) + " bar" - division needs a check as well, as '/' should be replaced by '//' in a lot of places. - there is one place where a (very) small behaviour change occurs, namely in Demo/sockets/gopher.py, where "print '(Bad line from server:', `line`, ')'" is replaced by "print '(Bad line from server: %r)' % (line,)", which is a difference of one whitespace character - I don't think it would cause a lot of trouble ;-) - it is possible that there are more errors in the patch which I didn't see, but it's also possible that there aren't any. (Hmm, I don't see immediatly how to add a patch...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 08:31 Message: Logged In: YES user_id=80475 Any progress on getting this reviewed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 23:59 Message: Logged In: YES user_id=89016 Updated the patch so that the test suite works again (except for test_doctest.py) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 22:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Sun Feb 1 05:19:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 05:20:41 2004 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Comment added) made by gerrit 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: Gerrit Holl (gerrit) Date: 2004-02-01 11:19 Message: Logged In: YES user_id=13298 Hmm, it doesn't seem to be possible to add an attachement to a tracker not sumbitted by yourself. I've now uploaded the metapatch to: http://people.nl.linux.org/~gerrit/creaties/b2r.metadiff ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 11:10 Message: Logged In: YES user_id=13298 Raymond Hettinger asked me if I could do a second review for this patch, so I did. I found three errors. The first one is in Lib/lib-old/codehack.py. It's a mistake that the change is there at all. The second one in in Lib/plat-mac/aetypes.py where a 'r' is missing. The third and last one is in Tools/scripts/methfix.py. Here, a variable is printed twice. First one: - key = `co` # arbitrary but uniquely identifying string + key = co` # arbitrary but uniquely identifying string Second one: - return "QDRectangle(%s, %s, %s, %s)" % (`self.v0`, `self.h0`, - `self.v1`, `self.h1`) + return "QDRectangle(%r, %r, %r, %)" % (self.v0, self.h0, self.v1, self.h1) Third one: - err(tempname + ': warning: chmod failed (' + `msg` + ')\n') + err(tempname + '%s: warning: chmod failed (%r)\n' % (tempname, msg)) # Then make a backup of the original file as filename~ try: os.rename(filename, filename + '~') except os.error, msg: - err(filename + ': warning: backup failed (' + `msg` + ')\n') + err(filename + '%s: warning: backup failed (%r)\n' % (filename, msg)) # Now move the temp file to the original file try: os.rename(tempname, filename) except os.error, msg: - err(filename + ': rename failed (' + `msg` + ')\n') + err(filename + '%s: rename failed (%r)\n' % (filename, msg)) Attached is a meta-patch containing the differences between the original backticks2repr.txt which contains some errors, and the one with the errors removed. Note that I did not run any test suite or something like that, because I understand that had already been done. Other things I noticed: - sometimes this patch uses "foo %r bar" % baz, sometimes "foo %r bar" % (baz,), and sometimes "foo " + repr(baz) + " bar" - division needs a check as well, as '/' should be replaced by '//' in a lot of places. - there is one place where a (very) small behaviour change occurs, namely in Demo/sockets/gopher.py, where "print '(Bad line from server:', `line`, ')'" is replaced by "print '(Bad line from server: %r)' % (line,)", which is a difference of one whitespace character - I don't think it would cause a lot of trouble ;-) - it is possible that there are more errors in the patch which I didn't see, but it's also possible that there aren't any. (Hmm, I don't see immediatly how to add a patch...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 08:31 Message: Logged In: YES user_id=80475 Any progress on getting this reviewed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 23:59 Message: Logged In: YES user_id=89016 Updated the patch so that the test suite works again (except for test_doctest.py) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 22:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Sun Feb 1 06:31:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 06:31:13 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 (Comment added) made by tebeka 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: Miki Tebeka (tebeka) Date: 2004-02-01 13:31 Message: Logged In: YES user_id=358087 Attached. Please check it, English is *not* my native language. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-31 14: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 Sun Feb 1 10:10:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 10:10:55 2004 Subject: [Patches] [ python-Patches-888573 ] "van rossum" misspelled Message-ID: Patches item #888573, was opened at 2004-02-02 00: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=888573&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: "van rossum" misspelled Initial Comment: "van rossum" is misspelled in PEP-326. [2] (1, 2) Re: [Python-Dev] Got None. Maybe Some?, von Rossum, Guido s/von rossum/van rossum This may be a typical mistake, but ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888573&group_id=5470 From noreply at sourceforge.net Sun Feb 1 13:23:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 13:23:31 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 (Settings changed) 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: Martin v. L?wis (loewis) 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: Miki Tebeka (tebeka) Date: 2004-02-01 12:31 Message: Logged In: YES user_id=358087 Attached. Please check it, English is *not* my native language. ---------------------------------------------------------------------- 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 Sun Feb 1 14:40:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 14:40:34 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Sun Feb 1 14:44:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 14:44:49 2004 Subject: [Patches] [ python-Patches-888573 ] "van rossum" misspelled Message-ID: Patches item #888573, was opened at 2004-02-01 16:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888573&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: "van rossum" misspelled Initial Comment: "van rossum" is misspelled in PEP-326. [2] (1, 2) Re: [Python-Dev] Got None. Maybe Some?, von Rossum, Guido s/von rossum/van rossum This may be a typical mistake, but ... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:44 Message: Logged In: YES user_id=21627 Thanks, fixed in 1.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888573&group_id=5470 From noreply at sourceforge.net Sun Feb 1 14:47:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 14:47:35 2004 Subject: [Patches] [ python-Patches-888148 ] Bluetooth support for FreeBSD systems. Message-ID: Patches item #888148, was opened at 2004-01-31 15:32 Message generated for change (Comment added) made by loewis 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: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) >Assigned to: Hye-Shik Chang (perky) 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. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. There is no need to incorporate generated files (configure, config.h.in) in SF patches, though. They outdate quickly, and need to be regenerated by whoever applies the patch, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888148&group_id=5470 From noreply at sourceforge.net Sun Feb 1 21:03:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 21:04:02 2004 Subject: [Patches] [ python-Patches-849278 ] improve embeddability of python Message-ID: Patches item #849278, was opened at 2003-11-25 17:00 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: improve embeddability of python Initial Comment: Add PyInitializeX that omits check in environment variables to set debugging, optimize, and verbose flags. Add PySetSysPaths to specify location of modules and the prefixes and the full path. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2004-02-01 21:03 Message: Logged In: YES user_id=876734 The makefile.pre.in change was included here as a mistake. Please ignore it. I'll tackle the documentation as soon as I can. --benson ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-31 07: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 15:21 Message: Logged In: YES user_id=876734 Here are the Windows patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=849278&group_id=5470 From noreply at sourceforge.net Sun Feb 1 22:29:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 22:29:17 2004 Subject: [Patches] [ python-Patches-888839 ] cygwinccompiler should set C++ compiler Message-ID: Patches item #888839, was opened at 2004-02-02 12: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=888839&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: cygwinccompiler should set C++ compiler Initial Comment: When C++ linking gotcha that have persisted in distutils was fixed in Python 2.3, I was glad. Unfortunately, it seems MinGW (I suspect same for Cygwin) was not fixed at the time. cygwinccompiler currently does not set compiler_cxx, so linking C++ just fails, even though all the machinery needed for linking C++ is there. Fix is simple, and I thank niemeyer and people involved for fixing #413582. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888839&group_id=5470 From noreply at sourceforge.net Sun Feb 1 23:33:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 1 23:33:26 2004 Subject: [Patches] [ python-Patches-888839 ] cygwinccompiler should set C++ compiler Message-ID: Patches item #888839, was opened at 2004-02-02 12:29 Message generated for change (Comment added) made by sanxiyn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888839&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: cygwinccompiler should set C++ compiler Initial Comment: When C++ linking gotcha that have persisted in distutils was fixed in Python 2.3, I was glad. Unfortunately, it seems MinGW (I suspect same for Cygwin) was not fixed at the time. cygwinccompiler currently does not set compiler_cxx, so linking C++ just fails, even though all the machinery needed for linking C++ is there. Fix is simple, and I thank niemeyer and people involved for fixing #413582. ---------------------------------------------------------------------- >Comment By: Seo Sanghyeon (sanxiyn) Date: 2004-02-02 13:33 Message: Logged In: YES user_id=837148 Oops, Cygwin should have -mcywgin, not -mno-cygwin, of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888839&group_id=5470 From gerinse at crumbly.com Mon Feb 2 15:23:56 2004 From: gerinse at crumbly.com (Mason Diamond) Date: Mon Feb 2 00:30:30 2004 Subject: [Patches] 86.AE. a smart move to help u last until 36 hours Message-ID: OFFSHORE PHARMACY! Not a single question asked! Super Viaggra - CIALIS is Here - as seen during the SUPER BOWL Dubbed "The Weekend Pill" * LONGER LIFE Up to 36 hours compared to 4 hours for viagra * ACTS FASTER from as little as 15 minutes compared to 60 minutes for viagra * BEST SEX EVER solid erection and only whenever you need it. With cialis YOU are in control "Cialis works in 15 minutes and lasts for 36 hours giving you strong healthy erections whenever you want or need them!" NO QUESTIONS. JUST PAY & WE SHIP. COMPLETE PRIVACY & CONFIDENTIATLITY. 128-bit encrypted website for maximum security. We also have an assortment of other drugs such as soma, valium, xanax, meridia, etc. http://respectful.bacconed.com/m0013/index.php?id=m0013 No more of this sort of material. Honoured in 24-48 hours. http://coffeepot.bacconed.com/a.html abc breezy peat helena costa disc implantation execute fame bravura mudsling carbuncle stefan spatterdock precept slick compression combat spinneret dairyman sonny trustful exquisite allege alumina depredate citizen operatic pageant attentive flashback polis hydroxide yZ From noreply at sourceforge.net Mon Feb 2 01:08:45 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 01:08:49 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 (Comment added) made by perky 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: Closed Resolution: Accepted Priority: 5 Submitted By: Hye-Shik Chang (perky) Assigned to: Hye-Shik Chang (perky) 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. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 15:08 Message: Logged In: YES user_id=55188 Checked in as: configure.in 1.449 Modules/socketmodule.c 1.283 configure 1.438 pyconfig.h.in 1.92 Thanks for the review! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 04:47 Message: Logged In: YES user_id=21627 The patch is fine, please apply. There is no need to incorporate generated files (configure, config.h.in) in SF patches, though. They outdate quickly, and need to be regenerated by whoever applies the patch, anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=888148&group_id=5470 From noreply at sourceforge.net Mon Feb 2 03:29:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 03:30:26 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-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Mon Feb 2 06:00:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 06:00:16 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 (Comment added) made by mwh 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: Hye-Shik Chang (perky) 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. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-02-02 11:00 Message: Logged In: YES user_id=6656 Looks fine to me. Check it in. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-01 05:46 Message: Logged In: YES user_id=55188 I wrote a unittest. How's this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876178&group_id=5470 From noreply at sourceforge.net Mon Feb 2 06:20:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 06:21:03 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-02-02 11:20 Message: Logged In: YES user_id=6656 Did I mention this idea to you or did you come up with it independently? I forget... I'll try to time stuff on my iBook tomorrow. ---------------------------------------------------------------------- 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 Mon Feb 2 06:47:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 06:47: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-02-02 20:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Mon Feb 2 07:37:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 07:37:49 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-02-02 21:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 20:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Mon Feb 2 07:58:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 07:58:33 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-02-02 12:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 12:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 11:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 08:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-30 05: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 03: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 11: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 07: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-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 Feb 2 08:04:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 08:04:49 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-02-02 13:04 Message: Logged In: YES user_id=4771 I guess the idea was just in the air, after your published attempts. Ideally I'd have liked to have the cached frame depend on the globals as well as the code object itself; I considered moving the cache field to function objects. This way you also save the f_globals and f_builtins initialization. There were problems but maybe we should try harder. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-02 11:20 Message: Logged In: YES user_id=6656 Did I mention this idea to you or did you come up with it independently? I forget... I'll try to time stuff on my iBook tomorrow. ---------------------------------------------------------------------- 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 Mon Feb 2 08:43:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 08:43:28 2004 Subject: [Patches] [ python-Patches-876178 ] input() vs __future__ Message-ID: Patches item #876178, was opened at 2004-01-14 01:17 Message generated for change (Comment added) made by perky 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: Closed Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Hye-Shik Chang (perky) 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. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 22:43 Message: Logged In: YES user_id=55188 Ok. Checked in: Misc/NEWS 1.926 Python/bltinmodule.c 2.308 Lib/test/test_builtin.py 1.28 ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-02 20:00 Message: Logged In: YES user_id=6656 Looks fine to me. Check it in. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-01 14:46 Message: Logged In: YES user_id=55188 I wrote a unittest. How's this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876178&group_id=5470 From noreply at sourceforge.net Mon Feb 2 13:35:17 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 13:35:24 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 16:35:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 16:35:15 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 16:15:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 16:41:57 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 16:42:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 16:43:02 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 16:21:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 16:59:56 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 17:00:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 17:00:38 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 17:04:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 17:04:39 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Mon Feb 2 17:20:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 2 17:20:31 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Tue Feb 3 04:07:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 04:07:44 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-02-03 18:07 Message: Logged In: YES user_id=671362 Thanks, Arigo and Perky. Hmm, maybe I should read PEP and the thread about namespace more carefully, not just skim the surface. Anyway, PEP has not been updated since last October, so I think it's good time to merge recent progress of genexpr and update PEP-289. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-02 21:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 21:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 20:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Tue Feb 3 06:46:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 06:46:25 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-02-03 11:46 Message: Logged In: YES user_id=4771 After thinking a bit more on the issue, note that the generator version of your example is equivalent to: def g(): for y in range(3): yield lambda x: x+y which means that it can suffer from the same problem as the first example, but more subtly (and even more confusingly): for f in g(): print f(0) # 0, 1, 2 for f in list(g()): print f(0) # 2, 2, 2 This is because due to Python's nested scope rules the above generator is equivalent to: def g(): result = lambda x: x+y for y in range(3): yield result at which point I think it gets pretty confusing... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-03 09:07 Message: Logged In: YES user_id=671362 Thanks, Arigo and Perky. Hmm, maybe I should read PEP and the thread about namespace more carefully, not just skim the surface. Anyway, PEP has not been updated since last October, so I think it's good time to merge recent progress of genexpr and update PEP-289. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-02 12:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 12:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 11:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 08:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-01-30 05: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 03: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 11: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 07: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-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 Tue Feb 3 11:29:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 11:30:44 2004 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 11:28 Message generated for change (Comment added) made by adamg-work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 11:29 Message: Logged In: YES user_id=939860 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 From noreply at sourceforge.net Tue Feb 3 11:28:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 12:38:51 2004 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 From noreply at sourceforge.net Tue Feb 3 11:30:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 12:52:51 2004 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 11:28 Message generated for change (Comment added) made by adamg-work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- >Comment By: adam goucher (adamg-work) Date: 2004-02-03 11:30 Message: Logged In: YES user_id=939860 one last try to have all the files uploaded to the patch ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 11:29 Message: Logged In: YES user_id=939860 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 From noreply at sourceforge.net Tue Feb 3 13:50:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 13:51:49 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From amparowitt at uk2.net Wed Feb 4 06:42:22 2004 From: amparowitt at uk2.net (Charity Snyder) Date: Tue Feb 3 15:47:58 2004 Subject: [Patches] 78.BZM. Stay hard with Cialis Message-ID: OFFSHORE PHARMACY! Not a single question asked! Super Viaggra - CIALIS is Here - as seen during the SUPER BOWL Dubbed "The Weekend Pill" * LONGER LIFE Up to 36 hours compared to 4 hours for viagra * ACTS FASTER from as little as 15 minutes compared to 60 minutes for viagra * BEST SEX EVER solid erection and only whenever you need it. With cialis YOU are in control "Cialis works in 15 minutes and lasts for 36 hours giving you strong healthy erections whenever you want or need them!" NO QUESTIONS. JUST PAY & WE SHIP. COMPLETE PRIVACY & CONFIDENTIATLITY. 128-bit encrypted website for maximum security. We also have an assortment of other drugs such as soma, valium, xanax, meridia, etc. http://cuff.bacconed.com/m0013/index.php?id=3Dm0013 No more of this sort of material. Honoured in 24-48 hours. http://slack.bacconed.com/a.html abe beresford stearate churchillian inclination inhibitor binghamton terbi= um gibberish credent account ahoy admitted andromeda blueprint mountain in= adequate oil staminate gal=20 uu From noreply at sourceforge.net Tue Feb 3 15:58:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 3 15:59:45 2004 Subject: [Patches] [ python-Patches-889949 ] Make `commands' module work on Windows Message-ID: Patches item #889949, was opened at 2004-02-03 22:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889949&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: Make `commands' module work on Windows Initial Comment: Currently the `commands' module does not work on windows. A small patch fix this. `getstatus' is not created on windows. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889949&group_id=5470 From noreply at sourceforge.net Wed Feb 4 01:13:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 01:13:57 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-02-04 15:13 Message: Logged In: YES user_id=595483 Again, I fixed the patch so that it can get error from '(x for x in None)' immediately. (upto now, error does not occur until generator expression is evaluated) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-03 20:46 Message: Logged In: YES user_id=4771 After thinking a bit more on the issue, note that the generator version of your example is equivalent to: def g(): for y in range(3): yield lambda x: x+y which means that it can suffer from the same problem as the first example, but more subtly (and even more confusingly): for f in g(): print f(0) # 0, 1, 2 for f in list(g()): print f(0) # 2, 2, 2 This is because due to Python's nested scope rules the above generator is equivalent to: def g(): result = lambda x: x+y for y in range(3): yield result at which point I think it gets pretty confusing... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-03 18:07 Message: Logged In: YES user_id=671362 Thanks, Arigo and Perky. Hmm, maybe I should read PEP and the thread about namespace more carefully, not just skim the surface. Anyway, PEP has not been updated since last October, so I think it's good time to merge recent progress of genexpr and update PEP-289. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-02 21:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 21:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 20:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Wed Feb 4 01:30:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 01:30:43 2004 Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support Message-ID: Patches item #890203, was opened at 2004-02-03 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=890203&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: DragonFly BSD support Initial Comment: I spent some time building a simple little patch that gets Python up and running under DragonFly BSD. At the moment, DragonFly (as a platform) is nearly identical to FreeBSD (from which is was forked), so the generated the patch was largely mechanical. I'll continue to make efforts to support Python on DragonFly should things become more complicated. The only known issue is a test case failure for test_fcntl. I don't know whether this failure is unique to DragonFly at this time. I'll investigate that soon. This patch is valid for DragonFly 1.0-CURRENT using either GCC 2.95.4 or GCC 3.3.3 20040126. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 From noreply at sourceforge.net Wed Feb 4 01:32:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 01:32:52 2004 Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support Message-ID: Patches item #890203, was opened at 2004-02-03 22:30 Message generated for change (Comment added) made by jparise You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: DragonFly BSD support Initial Comment: I spent some time building a simple little patch that gets Python up and running under DragonFly BSD. At the moment, DragonFly (as a platform) is nearly identical to FreeBSD (from which is was forked), so the generated the patch was largely mechanical. I'll continue to make efforts to support Python on DragonFly should things become more complicated. The only known issue is a test case failure for test_fcntl. I don't know whether this failure is unique to DragonFly at this time. I'll investigate that soon. This patch is valid for DragonFly 1.0-CURRENT using either GCC 2.95.4 or GCC 3.3.3 20040126. ---------------------------------------------------------------------- >Comment By: Jon Parise (jparise) Date: 2004-02-03 22:32 Message: Logged In: YES user_id=485579 Also, attached in the generated IN.py Lib/plat-dragonfly1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 From noreply at sourceforge.net Wed Feb 4 06:26:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 06:26: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 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-02-04 19:45 Message: Logged In: YES user_id=671362 What about this code? In the currently implementation, loop variables inside a list comprehension is not visible outside if you use it inside a generator expression. For example: >>> (a*b for a in [b for b in range(5)]) Traceback (most recent call last): File "", line 1, in ? NameError: name 'b' is not defined Its list comprehension counterpart is: >>> [a*b for a in [b for b in range(5)]] [0, 4, 8, 12, 16] ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-04 15:13 Message: Logged In: YES user_id=595483 Again, I fixed the patch so that it can get error from '(x for x in None)' immediately. (upto now, error does not occur until generator expression is evaluated) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-03 20:46 Message: Logged In: YES user_id=4771 After thinking a bit more on the issue, note that the generator version of your example is equivalent to: def g(): for y in range(3): yield lambda x: x+y which means that it can suffer from the same problem as the first example, but more subtly (and even more confusingly): for f in g(): print f(0) # 0, 1, 2 for f in list(g()): print f(0) # 2, 2, 2 This is because due to Python's nested scope rules the above generator is equivalent to: def g(): result = lambda x: x+y for y in range(3): yield result at which point I think it gets pretty confusing... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-03 18:07 Message: Logged In: YES user_id=671362 Thanks, Arigo and Perky. Hmm, maybe I should read PEP and the thread about namespace more carefully, not just skim the surface. Anyway, PEP has not been updated since last October, so I think it's good time to merge recent progress of genexpr and update PEP-289. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-02 21:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 21:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 20:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Wed Feb 4 08:53:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 08:54:12 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-02-04 22:53 Message: Logged In: YES user_id=55188 As it mentioned in PEP, even listcomp's leaking of loop value will be dropped in Python 3. I'm sorry but I don't see that the usage is solid in the future. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-04 19:45 Message: Logged In: YES user_id=671362 What about this code? In the currently implementation, loop variables inside a list comprehension is not visible outside if you use it inside a generator expression. For example: >>> (a*b for a in [b for b in range(5)]) Traceback (most recent call last): File "", line 1, in ? NameError: name 'b' is not defined Its list comprehension counterpart is: >>> [a*b for a in [b for b in range(5)]] [0, 4, 8, 12, 16] ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-04 15:13 Message: Logged In: YES user_id=595483 Again, I fixed the patch so that it can get error from '(x for x in None)' immediately. (upto now, error does not occur until generator expression is evaluated) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-03 20:46 Message: Logged In: YES user_id=4771 After thinking a bit more on the issue, note that the generator version of your example is equivalent to: def g(): for y in range(3): yield lambda x: x+y which means that it can suffer from the same problem as the first example, but more subtly (and even more confusingly): for f in g(): print f(0) # 0, 1, 2 for f in list(g()): print f(0) # 2, 2, 2 This is because due to Python's nested scope rules the above generator is equivalent to: def g(): result = lambda x: x+y for y in range(3): yield result at which point I think it gets pretty confusing... ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-03 18:07 Message: Logged In: YES user_id=671362 Thanks, Arigo and Perky. Hmm, maybe I should read PEP and the thread about namespace more carefully, not just skim the surface. Anyway, PEP has not been updated since last October, so I think it's good time to merge recent progress of genexpr and update PEP-289. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-02-02 21:58 Message: Logged In: YES user_id=4771 The behavior is indeed the one described by the PEP but it is still surprising. As far as I'm concerned it is yet another reason why free variable bindings ("nested scopes") are done wrong in Python currently :-( If you use the older trick "lambda x,y=y:x+y" instead, then both cases will agree (with the sensible result in my opinion). A few more issues and I'll start a campain for definition-time bindings of free variables :-( ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-02-02 21:37 Message: Logged In: YES user_id=55188 I think it's right for namespace difference between listcomp and genexpr. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2004-02-02 20:47 Message: Logged In: YES user_id=671362 I am not sure if I should call this a bug, but here it goes: >>> lst = [lambda x:x+y for y in range(3)] >>> for f in lst:print f(0) ... 2 2 2 >>> gen = (lambda x:x+y for y in range(3)) >>> for f in gen:print f(0) ... 0 1 2 Is this the intended behavior? ---------------------------------------------------------------------- Comment By: Jiwon Seo (jiwon) Date: 2004-02-02 17:29 Message: Logged In: YES user_id=595483 ok. I fixed another bug reported by perky, and added related test to test_grammar.py. ---------------------------------------------------------------------- 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 Wed Feb 4 16:19:58 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 16:21:38 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 22:19 Message: Logged In: YES user_id=21627 It is unfortunate that bdist_rpm is not useful to generate RPMs for distribution, because this is the primary purpose of that command: generating RPMs. So if the command does not meet your needs, we should change it to make it meet your needs. E.g. would it help if bdist_rpm would generate the .spec file for you? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Wed Feb 4 17:07:20 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 17:07:29 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:07 Message: Logged In: YES user_id=21627 This might work. bdist_rpm would have to invoke the install command, but only to compute the file list, instead of actually performing copying. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-04 22:33 Message: Logged In: YES user_id=192186 It's pripary purpose is IMHO to allow building of rpms when you distribute some python stuff. It is good for this case. The problem for distributions, is that all packages need to be handled same way (in case they use some automatically building system), so you can not differ whether it is packaged some python stuff or kernel. So separate spec file and sources is the only solution. Generating spec file doesn't help much as it can get changed every version and vendor has own additional information in spec file, which would require hand merging. Another idea I just got is to generate just file list using separate bdist_rpm and use it separately, but I'm not sure whether it is doable - information about file list is not probably available there, is it? It would be used like: python setup.py install --root=$RPM_BUILD_ROOT python setup.py bdist_rpm --filelist=INSTALLED_FILES ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 22:19 Message: Logged In: YES user_id=21627 It is unfortunate that bdist_rpm is not useful to generate RPMs for distribution, because this is the primary purpose of that command: generating RPMs. So if the command does not meet your needs, we should change it to make it meet your needs. E.g. would it help if bdist_rpm would generate the .spec file for you? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Wed Feb 4 17:37:47 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 17:38:06 2004 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 17:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:37 Message: Logged In: YES user_id=21627 Would be reasonable to change the default to TLS? ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 17:30 Message: Logged In: YES user_id=939860 one last try to have all the files uploaded to the patch ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 17:29 Message: Logged In: YES user_id=939860 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 From noreply at sourceforge.net Wed Feb 4 16:33:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 18:14:56 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Michal Čihař (nijel) Date: 2004-02-04 22:33 Message: Logged In: YES user_id=192186 It's pripary purpose is IMHO to allow building of rpms when you distribute some python stuff. It is good for this case. The problem for distributions, is that all packages need to be handled same way (in case they use some automatically building system), so you can not differ whether it is packaged some python stuff or kernel. So separate spec file and sources is the only solution. Generating spec file doesn't help much as it can get changed every version and vendor has own additional information in spec file, which would require hand merging. Another idea I just got is to generate just file list using separate bdist_rpm and use it separately, but I'm not sure whether it is doable - information about file list is not probably available there, is it? It would be used like: python setup.py install --root=$RPM_BUILD_ROOT python setup.py bdist_rpm --filelist=INSTALLED_FILES ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 22:19 Message: Logged In: YES user_id=21627 It is unfortunate that bdist_rpm is not useful to generate RPMs for distribution, because this is the primary purpose of that command: generating RPMs. So if the command does not meet your needs, we should change it to make it meet your needs. E.g. would it help if bdist_rpm would generate the .spec file for you? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Wed Feb 4 17:36:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 18:18:29 2004 Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support Message-ID: Patches item #890203, was opened at 2004-02-04 07:30 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: DragonFly BSD support Initial Comment: I spent some time building a simple little patch that gets Python up and running under DragonFly BSD. At the moment, DragonFly (as a platform) is nearly identical to FreeBSD (from which is was forked), so the generated the patch was largely mechanical. I'll continue to make efforts to support Python on DragonFly should things become more complicated. The only known issue is a test case failure for test_fcntl. I don't know whether this failure is unique to DragonFly at this time. I'll investigate that soon. This patch is valid for DragonFly 1.0-CURRENT using either GCC 2.95.4 or GCC 3.3.3 20040126. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:36 Message: Logged In: YES user_id=21627 Are you willing to act as a maintainer and contact point for the Dragonfly port? ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-02-04 07:32 Message: Logged In: YES user_id=485579 Also, attached in the generated IN.py Lib/plat-dragonfly1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 From noreply at sourceforge.net Wed Feb 4 17:09:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 18:19:16 2004 Subject: [Patches] [ python-Patches-755286 ] Generate rpm filelist including directories Message-ID: Patches item #755286, was opened at 2003-06-16 14:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 Category: Distutils and setup.py Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michal Čihař (nijel) Assigned to: Martin v. L?wis (loewis) Summary: Generate rpm filelist including directories Initial Comment: Attached patch adds --record-rpm option to distutils, that allows generating of rpm-like filelist, that contains also directories. Currently most rpm vendors are using some external commands to get dir list or have hard coded it in spec file. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:09 Message: Logged In: YES user_id=21627 Alternatively, adding --record-dirs to the install command would be acceptable as well, so you could post-process the directory list, e.g. with awk. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:07 Message: Logged In: YES user_id=21627 This might work. bdist_rpm would have to invoke the install command, but only to compute the file list, instead of actually performing copying. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-04 22:33 Message: Logged In: YES user_id=192186 It's pripary purpose is IMHO to allow building of rpms when you distribute some python stuff. It is good for this case. The problem for distributions, is that all packages need to be handled same way (in case they use some automatically building system), so you can not differ whether it is packaged some python stuff or kernel. So separate spec file and sources is the only solution. Generating spec file doesn't help much as it can get changed every version and vendor has own additional information in spec file, which would require hand merging. Another idea I just got is to generate just file list using separate bdist_rpm and use it separately, but I'm not sure whether it is doable - information about file list is not probably available there, is it? It would be used like: python setup.py install --root=$RPM_BUILD_ROOT python setup.py bdist_rpm --filelist=INSTALLED_FILES ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 22:19 Message: Logged In: YES user_id=21627 It is unfortunate that bdist_rpm is not useful to generate RPMs for distribution, because this is the primary purpose of that command: generating RPMs. So if the command does not meet your needs, we should change it to make it meet your needs. E.g. would it help if bdist_rpm would generate the .spec file for you? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-03 19:50 Message: Logged In: YES user_id=192186 As I said bdist_rpm is not suitable for building packages in distribution - all packages are built same way using spec file and sources (+patches). And this building packages for distribution (I work for SUSE) is main goal why I did this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:20 Message: Logged In: YES user_id=21627 I see. Wouldn't it better if the bdist_rpm command would generate a .spec file that completely contains all directives? Then, this could be enhanced to make use of more features of RPMs, such as %doc, %docdir, %verify, etc. It would also allow to keep RPM specifics out of the install command. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 23:04 Message: Logged In: YES user_id=192186 It does extend --record with directory entries. This resulting file is then used by rpm: %install python setup.py install --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES %files -f INSTALLED_FILES %defattr(-,root,root) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 23:00 Message: Logged In: YES user_id=21627 Then I don't understand how your patch works: Does it not generate %dir lines for the .spec file? And isn't the spec file generated by the bdist_rpm command? ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:42 Message: Logged In: YES user_id=192186 I still do not see how to put that into bdist_rpm and keep it usable: - bdist_rpm creates tarbal and then calls rpm which builds it and the installation itself is done by install - when building package for distribution (SUSE) bdist_rpm is not used at all ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:35 Message: Logged In: YES user_id=21627 I can pose a few principles: put RPM-specific code just into bdist_rpm, and enhance other commands to provide generic functionality which might be usable only to RPM at the moment, but could be useful more generally in the future. Also, make sure all commands continue to work if no RPMs are built (e.g. the standard "install" command should continue to work). I think you code is quite close algorithmically, it just needs to be re-arranged a bit. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 22:21 Message: Logged In: YES user_id=192186 It would be probably best, if somebody with more knowledge, how distutils work, would help with design. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-02 22:15 Message: Logged In: YES user_id=21627 We are not much interested in quick hacks. Are you willing to revise your implementation to make it well-designed? If not, I'll reject it (and hope that somebody else will submit a well-designed implementation of that feature in the future). ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2004-02-02 19:35 Message: Logged In: YES user_id=192186 I agree, that the implementation is not perfect. It's mostly quick hack, that needed to be written to avoid postprocessing of generated file lists. I'm open to rewrite it when somebody gives me better idea for implementation, but probably I won't have time for this in next month. Why I called it record-rpm - it does same as record, but adds directories needed for rpm. Limiting to bdist_rpm is IMHO not good idea, as in this case it is not usable for distribution vendors (bdist_rpm is not suitable for this case, at least as I see situation in SUSE). I choose overloading get_outputs just to avoid code duplication in many cases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-01 20:40 Message: Logged In: YES user_id=21627 I like the feature, but not the implementation: - The option should not be called "record-rpm", as it does not record RPM files, but directories. - RPM-specific code should be completely restricted to the bdist_rpm command. For the case of directories, you should create a mechanism to collect all directories, and then traverse this list to create the proper %dir directives in the spec file. - I'm not sure that overloading get_outputs is a good idea. Instead, introducing get_output_dirs might be better. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-24 16:18 Message: Logged In: YES user_id=192186 Version 6 now works as expected for all python packages using distutils in SuSE distro. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 17:53 Message: Logged In: YES user_id=192186 Sorry for posting buch of patches here, but I test it with more and more modules and I find more and more problems :-) ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-17 10:36 Message: Logged In: YES user_id=192186 Version 4 improves handling of mutliple levels of install directories. ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 17:37 Message: Logged In: YES user_id=192186 One more update: - fix generating of dirs in chrooted installs for install_data - don't include directory for install_scripts ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-06-16 15:49 Message: Logged In: YES user_id=192186 Updated version fixes problems with self defined get_outputs methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=755286&group_id=5470 From noreply at sourceforge.net Wed Feb 4 19:00:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 4 19:00:11 2004 Subject: [Patches] [ python-Patches-890203 ] DragonFly BSD support Message-ID: Patches item #890203, was opened at 2004-02-03 22:30 Message generated for change (Comment added) made by jparise You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jon Parise (jparise) Assigned to: Nobody/Anonymous (nobody) Summary: DragonFly BSD support Initial Comment: I spent some time building a simple little patch that gets Python up and running under DragonFly BSD. At the moment, DragonFly (as a platform) is nearly identical to FreeBSD (from which is was forked), so the generated the patch was largely mechanical. I'll continue to make efforts to support Python on DragonFly should things become more complicated. The only known issue is a test case failure for test_fcntl. I don't know whether this failure is unique to DragonFly at this time. I'll investigate that soon. This patch is valid for DragonFly 1.0-CURRENT using either GCC 2.95.4 or GCC 3.3.3 20040126. ---------------------------------------------------------------------- >Comment By: Jon Parise (jparise) Date: 2004-02-04 16:00 Message: Logged In: YES user_id=485579 Yes, I'm comfortable with that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 14:36 Message: Logged In: YES user_id=21627 Are you willing to act as a maintainer and contact point for the Dragonfly port? ---------------------------------------------------------------------- Comment By: Jon Parise (jparise) Date: 2004-02-03 22:32 Message: Logged In: YES user_id=485579 Also, attached in the generated IN.py Lib/plat-dragonfly1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=890203&group_id=5470 From noreply at sourceforge.net Thu Feb 5 22:23:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 5 22:23:05 2004 Subject: [Patches] [ python-Patches-666484 ] Japanese Unicode Codecs Message-ID: Patches item #666484, was opened at 2003-01-12 12:46 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: SUZUKI Hisao (suzuki_hisao) Assigned to: Nobody/Anonymous (nobody) Summary: Japanese Unicode Codecs Initial Comment: This is an implementation of a set of Japanese Unicode codecs for Python 2.2 and 2.3. Three major encodings are supported: EUC-JP, Shift_JIS and ISO-2022-JP. It is in pure Python, of a reasonable size (< 80KB), and with an effective means to modify the mapping tables. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-02-06 12:22 Message: Logged In: YES user_id=55188 Python got Japanese codecs by importing CJK codecs. Thank you for your efforts anyway! ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2003-01-18 17:58 Message: Logged In: YES user_id=495142 It will be very nice if Japanese codecs are got into the core. Nowadays even Perl 5.8 has them. I am very willing to help you and Tamito in codec maintenance. I am sorry, but I am so occupied with my work that I am afraid it might be difficult to take time off to do it everyday. Perhaps I will be able to make responses not daily but weekly. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-16 18:28 Message: Logged In: YES user_id=38388 Sorry for not having read the README earlier. You do have a point in that it is useful to be able to modify encodings in user-specific ways. Of course, this needs to be done by creating new codecs and Python files sure make this process easier. Now, AFAIK, none of the current Python developers know much about Japanese, so we'd need a maintainer for the codecs. If you would be able to take over this part, then I see a good chance of getting the codecs into the Python core (Tamito's codecs didn't get accepted for the core distribution because of their size). Perhaps you could team up with Tamito in this effort ?! ---------------------------------------------------------------------- Comment By: SUZUKI Hisao (suzuki_hisao) Date: 2003-01-16 09:22 Message: Logged In: YES user_id=495142 Yes, I know KAJIYAMA's work from version 1.0 to version 1.4.9. Indeed I had contributed a patch to JapaneseCodecs-1.2. Please read the README file included in the tar-ball for rationale of ja-codecs. As for the efficiency, ja-codecs is fairly fast and small in practice. In addition, its mapping possesses a good mathematical property, encode(decode(c)) == c for every valid character c, which is pragmatically useful for many applications. (The last version (1.4.9) of KAJIYAMA's codecs has also remedied it on a particular character: REVERSE SOLIDUS. It seems to lack a validation test like that of ja-codes-0.6/ja/map_jisx206.py, though.) As you know, KAJIYAMA's codecs set does not also cover all the encodings used in Japan today. For example, it does not support those of Macintosh. It might be almost impossible to make a perfect set of codecs in a realistic size. It would be best for "standard library" to prepare a few "standard" (based on public specifications and in use over various platforms) encodings, which can be _easily_ modified by users/developers in order to be adapted to their specific platforms (in the spirit of "open source" ;-). So I think it would be mandatory for Japanese codecs of standard library to be written in Python cleanly as well as efficiently enough, or at least, to effectively allow users to modify character mappings. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-12 21:33 Message: Logged In: YES user_id=38388 Are you aware of the codecs written by Tamito KAJIYAMA ? http://www.asahi-net.or.jp/~rd6t-kjym/python/ These are written in C and provide a much improved performance over Python based ones. They cover the same set of encodings you have in your packagea dn also include a complete test suite for the codecs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=666484&group_id=5470 From noreply at sourceforge.net Fri Feb 6 11:00:16 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 11:00:43 2004 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 11:28 Message generated for change (Comment added) made by adamg-work You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- >Comment By: adam goucher (adamg-work) Date: 2004-02-06 11:00 Message: Logged In: YES user_id=939860 I think in 2.3.x I would leave it as SSLv23 in order to not break things going from .x to .y. I think it would be reasonable to make TLS the default in the 2.4 branch though as some breakage is moreaceptable to more people when going between bigger releases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 17:37 Message: Logged In: YES user_id=21627 Would be reasonable to change the default to TLS? ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 11:30 Message: Logged In: YES user_id=939860 one last try to have all the files uploaded to the patch ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 11:29 Message: Logged In: YES user_id=939860 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 From noreply at sourceforge.net Fri Feb 6 13:29:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 13:30:03 2004 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Replace backticks with repr() Initial Comment: This patch removes most used of backticks in the standard library and replaces them with a call to repr() or uses '%r' in format string. I didn't touch the email package, the lib-old directory or test_grammar.py. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-02-06 19:29 Message: Logged In: YES user_id=89016 A new version of the patch that incorporates Gerrit's fixes can be found at http://styx.livinglogic.de/~walter/backtick2repr2.txt. The failure in test_doctest.py has disappeared. Is the patch ready to be checked in now? ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 11:19 Message: Logged In: YES user_id=13298 Hmm, it doesn't seem to be possible to add an attachement to a tracker not sumbitted by yourself. I've now uploaded the metapatch to: http://people.nl.linux.org/~gerrit/creaties/b2r.metadiff ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 11:10 Message: Logged In: YES user_id=13298 Raymond Hettinger asked me if I could do a second review for this patch, so I did. I found three errors. The first one is in Lib/lib-old/codehack.py. It's a mistake that the change is there at all. The second one in in Lib/plat-mac/aetypes.py where a 'r' is missing. The third and last one is in Tools/scripts/methfix.py. Here, a variable is printed twice. First one: - key = `co` # arbitrary but uniquely identifying string + key = co` # arbitrary but uniquely identifying string Second one: - return "QDRectangle(%s, %s, %s, %s)" % (`self.v0`, `self.h0`, - `self.v1`, `self.h1`) + return "QDRectangle(%r, %r, %r, %)" % (self.v0, self.h0, self.v1, self.h1) Third one: - err(tempname + ': warning: chmod failed (' + `msg` + ')\n') + err(tempname + '%s: warning: chmod failed (%r)\n' % (tempname, msg)) # Then make a backup of the original file as filename~ try: os.rename(filename, filename + '~') except os.error, msg: - err(filename + ': warning: backup failed (' + `msg` + ')\n') + err(filename + '%s: warning: backup failed (%r)\n' % (filename, msg)) # Now move the temp file to the original file try: os.rename(tempname, filename) except os.error, msg: - err(filename + ': rename failed (' + `msg` + ')\n') + err(filename + '%s: rename failed (%r)\n' % (filename, msg)) Attached is a meta-patch containing the differences between the original backticks2repr.txt which contains some errors, and the one with the errors removed. Note that I did not run any test suite or something like that, because I understand that had already been done. Other things I noticed: - sometimes this patch uses "foo %r bar" % baz, sometimes "foo %r bar" % (baz,), and sometimes "foo " + repr(baz) + " bar" - division needs a check as well, as '/' should be replaced by '//' in a lot of places. - there is one place where a (very) small behaviour change occurs, namely in Demo/sockets/gopher.py, where "print '(Bad line from server:', `line`, ')'" is replaced by "print '(Bad line from server: %r)' % (line,)", which is a difference of one whitespace character - I don't think it would cause a lot of trouble ;-) - it is possible that there are more errors in the patch which I didn't see, but it's also possible that there aren't any. (Hmm, I don't see immediatly how to add a patch...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 08:31 Message: Logged In: YES user_id=80475 Any progress on getting this reviewed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 23:59 Message: Logged In: YES user_id=89016 Updated the patch so that the test suite works again (except for test_doctest.py) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 22:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Fri Feb 6 13:37:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 13:37:10 2004 Subject: [Patches] [ python-Patches-864059 ] optimize eval_frame Message-ID: Patches item #864059, was opened at 2003-12-21 13:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Raymond Hettinger (rhettinger) Summary: optimize eval_frame Initial Comment: There are several different parts to this patch which are separable. They each seemed to have a small benefit. It would be interesting for others to test this patch in whole and in different parts to see if speed can be improved. I generally got between 1% - 10% improvement. I used pystone, pybench, and the total time to run all regression tests. Runs were on a RH9 Linux/Athlon 650. I used a non-debug build (so gcc 3.2 with -O3). All regression tests pass with these changes. I removed registers from many variables. This seemed to have little to no effect. So I'm not sure about those. opcode does not need to be initialized to 0. I removed the freevars variable since it is rarely used. I think the largest benefit was from adding the gotos for opcodes which set why: BREAK_LOOP, CONTINUE_LOOP, RETURN_VALUE, YIELD_VALUE; This skips many tests which are known a priori depending on the opcode. I removed the special check for list in UNPACK_SEQUENCE since this path is rarely used. (http://coverage.livinglogic.de/file.phtml?file%5fid=12442339) I also removed the predcitions for JUMP_IF_TRUE since this wasn't executed often (see previous URL). I added 2 opcodes for calling functions with 0 or 1 arguments. This removed a lot of code in call_function(). By removing test branches in several places, this seemed to speed up the code. However, it seemed that just specializing for 0 arguments was better than for 1 arg. I'm not sure if the specialization for 1 argument provides much benefit. Both of these specializations could possibly be improved to speed things up. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:37 Message: Logged In: YES user_id=80475 Added a simplified version of the goto optimization. See Python/ceval.c 2.374 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-31 22:42 Message: Logged In: YES user_id=80475 The patch is promising. I'm able to measure a small speed- up for the two new function opcodes and for the setwhy gotos. Both optimizations make sense. I don't measure a savings from not initializing opcode and oparg. That change makes sense conceptually because the variables are always assigned before use; however, the surrounding control flow statements hide that fact from the compiler. So, it is likely that they were initialized to suppress warnings on somebody's system. If so, then that change should not be made. The other stuff should definitely be left out. The effect of register variables will vary from compiler to compiler, so if you can't measure an improvement, it is best to leave it alone. Some compilers do not do much in the way of optimization and the register declaration may be a valuable hint. Please leave in the branch prediction for JUMP_IF_TRUE -- I put it in after finding measurable savings in real code. While it doesn't come up often, when it does it should run as fast as possible. The special case for UNPACK_SEQUENCE is up for grabs. When that case occurs, the speedup is substantial. Also, given that the tuple check has failed, it becomes highly probable that the target is a list. OTOH, this inlined code fattens the already voluminuous code for eval_frame. Maybe eliminating it will help someone's optimizer cope with all the code. Use your judgement on this one. Removing the freevars variable did not show any speedup. It does keep one variable off the stack and shortens the startup time by a few instructions. OTOH, the in-lined replacements for it result in a net expansion of code size and causes a microscopic slowdown whenever it is used. I recommend leaving this one alone. Executive summary: Only make the two big changes that show meaurable speedups and make conceptual sense. Leave the other stuff alone. One other thought, try making custom benchmarks for targeted optimizations. The broad spectrum benchmarks are too coarse to tell whether an improvement is really working. Also, be sure to check with Guido before adding the new opcodes. Ideally, each optimization should be loaded separately so its effects can be isolated and to allow any one to be backed out if necessary. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-12-24 03:20 Message: Logged In: YES user_id=80475 I'll try these out and review the patch when I get back from vacation next week. The list special case for UNPACK_SEQUENCE and the prediction for JUMP_IF_TRUE should be left in -- they do provide speed-ups for code that exercises those features and they don't hurt the general cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470 From noreply at sourceforge.net Fri Feb 6 13:38:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 13:38:31 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 (Comment added) made by doerwalter 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: Closed >Resolution: Fixed 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) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-02-06 19:38 Message: Logged In: YES user_id=89016 Checked in as: Lib/test/test_types.py 1.57 and 1.55.8.1 Note that test_types.py will be rewritten anyway as a PyUnit test, s. The "if True:" and "if False:" tests might be part of test_bool.py already. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=885008&group_id=5470 From noreply at sourceforge.net Fri Feb 6 13:52:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 13:52:41 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: Accepted 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-02-06 13:52 Message: Logged In: YES user_id=80475 If you're feeling confident, go ahead and submit it. I don't think Anthony has time for additional review. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-02-06 13:29 Message: Logged In: YES user_id=89016 A new version of the patch that incorporates Gerrit's fixes can be found at http://styx.livinglogic.de/~walter/backtick2repr2.txt. The failure in test_doctest.py has disappeared. Is the patch ready to be checked in now? ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 05:19 Message: Logged In: YES user_id=13298 Hmm, it doesn't seem to be possible to add an attachement to a tracker not sumbitted by yourself. I've now uploaded the metapatch to: http://people.nl.linux.org/~gerrit/creaties/b2r.metadiff ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 05:10 Message: Logged In: YES user_id=13298 Raymond Hettinger asked me if I could do a second review for this patch, so I did. I found three errors. The first one is in Lib/lib-old/codehack.py. It's a mistake that the change is there at all. The second one in in Lib/plat-mac/aetypes.py where a 'r' is missing. The third and last one is in Tools/scripts/methfix.py. Here, a variable is printed twice. First one: - key = `co` # arbitrary but uniquely identifying string + key = co` # arbitrary but uniquely identifying string Second one: - return "QDRectangle(%s, %s, %s, %s)" % (`self.v0`, `self.h0`, - `self.v1`, `self.h1`) + return "QDRectangle(%r, %r, %r, %)" % (self.v0, self.h0, self.v1, self.h1) Third one: - err(tempname + ': warning: chmod failed (' + `msg` + ')\n') + err(tempname + '%s: warning: chmod failed (%r)\n' % (tempname, msg)) # Then make a backup of the original file as filename~ try: os.rename(filename, filename + '~') except os.error, msg: - err(filename + ': warning: backup failed (' + `msg` + ')\n') + err(filename + '%s: warning: backup failed (%r)\n' % (filename, msg)) # Now move the temp file to the original file try: os.rename(tempname, filename) except os.error, msg: - err(filename + ': rename failed (' + `msg` + ')\n') + err(filename + '%s: rename failed (%r)\n' % (filename, msg)) Attached is a meta-patch containing the differences between the original backticks2repr.txt which contains some errors, and the one with the errors removed. Note that I did not run any test suite or something like that, because I understand that had already been done. Other things I noticed: - sometimes this patch uses "foo %r bar" % baz, sometimes "foo %r bar" % (baz,), and sometimes "foo " + repr(baz) + " bar" - division needs a check as well, as '/' should be replaced by '//' in a lot of places. - there is one place where a (very) small behaviour change occurs, namely in Demo/sockets/gopher.py, where "print '(Bad line from server:', `line`, ')'" is replaced by "print '(Bad line from server: %r)' % (line,)", which is a difference of one whitespace character - I don't think it would cause a lot of trouble ;-) - it is possible that there are more errors in the patch which I didn't see, but it's also possible that there aren't any. (Hmm, I don't see immediatly how to add a patch...) ---------------------------------------------------------------------- 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 Fri Feb 6 13:57:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 13:57:21 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 11:43 Message generated for change (Comment added) made by rhettinger 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: Guido van Rossum (gvanrossum) 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? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Fri Feb 6 15:18:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 15:19:07 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 11:43 Message generated for change (Comment added) made by tim_one 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: Guido van Rossum (gvanrossum) 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? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-02-06 15:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Fri Feb 6 18:00:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 18:00:21 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 11:43 Message generated for change (Comment added) made by rhettinger 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: Guido van Rossum (gvanrossum) 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? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 18:00 Message: Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-06 15:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Fri Feb 6 18:02:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 18:02:22 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 (Settings changed) made by rhettinger 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: Raymond Hettinger (rhettinger) 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 Fri Feb 6 23:54:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 6 23:54:42 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 11:43 Message generated for change (Comment added) made by gvanrossum 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: 1 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) 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? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-06 23:54 Message: Logged In: YES user_id=6380 1% is not something that can be measured reliably IMO (try it again with a different phase of the moon, or on a different box). OTOH I don't think that anyone has ever actually made use of this feature -- it was a request from Greg Stein but I doubt he got to use it. OT3H, compilation options like this tend to break the first time someone updates the affected code -- nobody is going to test with all possible combinations of weird compilation options. How's that for a non-answer. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 18:00 Message: Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-06 15:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Sat Feb 7 03:06:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 7 09:42:29 2004 Subject: [Patches] [ python-Patches-889813 ] making the version of SSL configurable when creating sockets Message-ID: Patches item #889813, was opened at 2004-02-03 17:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 Category: Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: adam goucher (adamg-work) Assigned to: Nobody/Anonymous (nobody) Summary: making the version of SSL configurable when creating sockets Initial Comment: Currently, socket.ssl uses the SSLv23 method of negotiating an ssl socket. This method connects with SSLv2 HELO packets and will negotiate up to a higher level if possible. However, if SSLv2 is turned off completly at the other side of the socket, this negotiation will fail. I have extended socket.ssl() to include another optional parameter -- the SSLmethod which can be any of the openssl methods (SSLv2, SSLv23, SSLv3, TLSv1). Existing functionality is maintained by providing SSLv23 as the default. Affected files: Lib/socket.py - extension of the function Modules/_ssl.c - guts of the changes socketmodule.h - theres a reference on how to make ssl sockets, so I added the change there Has been tested on solaris my making an ssl connection to a server, as well has httplib.HTTPSConnection() ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-07 09:06 Message: Logged In: YES user_id=21627 Ok. Your patch is inapplicable to 2.3, anyway, as it adds a new feature. Are you willing to revise your patch accordingly? Please also include patches to the documentation. ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-06 17:00 Message: Logged In: YES user_id=939860 I think in 2.3.x I would leave it as SSLv23 in order to not break things going from .x to .y. I think it would be reasonable to make TLS the default in the 2.4 branch though as some breakage is moreaceptable to more people when going between bigger releases. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-02-04 23:37 Message: Logged In: YES user_id=21627 Would be reasonable to change the default to TLS? ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 17:30 Message: Logged In: YES user_id=939860 one last try to have all the files uploaded to the patch ---------------------------------------------------------------------- Comment By: adam goucher (adamg-work) Date: 2004-02-03 17:29 Message: Logged In: YES user_id=939860 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=889813&group_id=5470 From noreply at sourceforge.net Sat Feb 7 17:46:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 7 17:46:12 2004 Subject: [Patches] [ python-Patches-868499 ] regrtest.py -T for code coverage Message-ID: Patches item #868499, was opened at 2003-12-31 11:38 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868499&group_id=5470 Category: Tests Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Jeremy Hylton (jhylton) Summary: regrtest.py -T for code coverage Initial Comment: This is a fairly simpleminded adaptation of Zope3's test.py -T (code coverage) flag to Python 2.4's regrtest.py module. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-02-07 17:46 Message: Logged In: YES user_id=12800 I went ahead and checked this in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868499&group_id=5470 From noreply at sourceforge.net Sat Feb 7 18:53:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 7 18:53:33 2004 Subject: [Patches] [ python-Patches-892660 ] bdist_wininst pre-install script, and --target-version fix Message-ID: Patches item #892660, was opened at 2004-02-08 10:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: bdist_wininst pre-install script, and --target-version fix Initial Comment: Hi Thomas :) Sorry, but a few changes rolled up in one. install.c: support for a 'pre-install-script', run before anything has been installed. Provides a 'message_box' module function for use by either the pre-install or post-install scripts. bdist_wininst.py: support for pre-install script. Typo (build->built), fixes so that --target-version can still work, even when the distribution has extension modules - in this case, we insist on --skip-build, as we still can't actually build other versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 From noreply at sourceforge.net Sat Feb 7 19:40:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 7 19:40:13 2004 Subject: [Patches] [ python-Patches-892673 ] Updated .spec file. Message-ID: Patches item #892673, was opened at 2004-02-08 00:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892673&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated .spec file. Initial Comment: Attached is a new .spec file which should be included in the next 2.3 or above release. The key feature of this update is that it goes through a few files which have "#!/usr/local/bin/python" in them, and changes it to "/usr/bin/env python%{binsuffix}" (where %{binsuffix} is 2.3, in the default case). It also has some code in it to look for other files that weren't picked up but have /usr/local/bin/python in them, and tattle on them and exit the build. This is to prevent future RPM releases from being uninstallable for most people. Sean ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892673&group_id=5470 From yolondamaran at pisem.net Sun Feb 8 08:26:42 2004 From: yolondamaran at pisem.net (Quinn Mcnally) Date: Sat Feb 7 19:44:07 2004 Subject: [Patches] Cheap Xanax Online - USA Pharmacy ELBE 0 Message-ID: Discount Offshore Pharmacy with NO QUESTIONS Get VALIUM, XANAX, PROZAC, SOMA, CAILIS, VIAG and many more... - NO COST Online Rx Provided HASSLE FREE - NO Medical QUESTIONS ASKED - International Express Shipping - 100% Private and Confidential http://extempore.soldrupfvc.com/m006/index.php?id=m006 No more of this sort of material. Honoured in 24-48 hours. http://castle.soldrupfvc.com/a.html alley detergent isomer corpsman variate whiteface contradictory praecox dilatation sprint dread earring kensington coors ontogeny parallax greet showmen invulnerable angstrom christoffel moe siltation brownell altar prophesy find licensor firewood artful prussia mechanic gradient compartment oS From noreply at sourceforge.net Sun Feb 8 06:42:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 8 06:42:31 2004 Subject: [Patches] [ python-Patches-892821 ] example for urllib2 has SyntaxError Message-ID: Patches item #892821, was opened at 2004-02-08 20: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=892821&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: example for urllib2 has SyntaxError Initial Comment: >From the example for urllib2. http://www.python.org/doc/current/lib/urllib2- examples.html > print '...' % > data The problem is that the right argument of % operator is not in the same line. This should read: > print '...' % data There is another typo from Python Reference Manual. http://www.python.org/doc/current/ref/encodings.html > which is recognized by Bram Moolenar's VIM. Moolenaar is misspelled. His last name is Moolenaar, not Moolenar. Check his web site. http://www.moolenaar.net/vim.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892821&group_id=5470 From noreply at sourceforge.net Sun Feb 8 06:44:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 8 06:44:07 2004 Subject: [Patches] [ python-Patches-892821 ] example for urllib2 has SyntaxError Message-ID: Patches item #892821, was opened at 2004-02-08 20:42 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892821&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: example for urllib2 has SyntaxError Initial Comment: >From the example for urllib2. http://www.python.org/doc/current/lib/urllib2- examples.html > print '...' % > data The problem is that the right argument of % operator is not in the same line. This should read: > print '...' % data There is another typo from Python Reference Manual. http://www.python.org/doc/current/ref/encodings.html > which is recognized by Bram Moolenar's VIM. Moolenaar is misspelled. His last name is Moolenaar, not Moolenar. Check his web site. http://www.moolenaar.net/vim.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892821&group_id=5470 From theronphoskins_qq at cfc-consultancy.co.uk Sun Feb 8 13:38:53 2004 From: theronphoskins_qq at cfc-consultancy.co.uk (Theron P. Hoskins) Date: Sun Feb 8 07:46:52 2004 Subject: [Patches] Home delivery Codeine Tylenol3 Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040208/c0817df2/attachment.html From noreply at sourceforge.net Sun Feb 8 13:59:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 8 14:00:01 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 rhettinger 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Mike Pall (mikesfpy) Assigned to: Raymond Hettinger (rhettinger) 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: Raymond Hettinger (rhettinger) Date: 2004-02-08 13:59 Message: Logged In: YES user_id=80475 Accepted and applied to Objects/intobject.c 2.108 and 2.105.8.1 . ---------------------------------------------------------------------- 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 Sun Feb 8 14:29:25 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 8 14:29:29 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: Closed >Resolution: Accepted 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 Feb 8 15:05:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 8 15:05:44 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 (Comment added) 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: Closed >Resolution: Accepted 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. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-08 15:05 Message: Logged In: YES user_id=80475 Accepted and applied: Python/ceval.c 2.375 FWIW, I think the significance of dynamic opcode counts is overrated as it tends to say more about the application being profiled and its coding style than it says about the interpreter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=884022&group_id=5470 From noreply at sourceforge.net Sun Feb 8 15:30:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 8 15:30:14 2004 Subject: [Patches] [ python-Patches-892821 ] example for urllib2 has SyntaxError Message-ID: Patches item #892821, was opened at 2004-02-08 06:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892821&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: example for urllib2 has SyntaxError Initial Comment: >From the example for urllib2. http://www.python.org/doc/current/lib/urllib2- examples.html > print '...' % > data The problem is that the right argument of % operator is not in the same line. This should read: > print '...' % data There is another typo from Python Reference Manual. http://www.python.org/doc/current/ref/encodings.html > which is recognized by Bram Moolenar's VIM. Moolenaar is misspelled. His last name is Moolenaar, not Moolenar. Check his web site. http://www.moolenaar.net/vim.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-08 15:30 Message: Logged In: YES user_id=80475 Accepted and applied. Thanks for your keen eye. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892821&group_id=5470 From noreply at sourceforge.net Mon Feb 9 12:55:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 9 12:55:40 2004 Subject: [Patches] [ python-Patches-893566 ] tp_dealloc, threads and garbage collection Message-ID: Patches item #893566, was opened at 2004-02-09 08: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=893566&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: tp_dealloc, threads and garbage collection Initial Comment: The attached tries to describe a potential trap for objects implemented in C: tp_dealloc may be called on any Python thread, not just the thread which originally created the object. I'm not sure the attached is a particularly good description, but I think it would be worth adding something along these lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893566&group_id=5470 From noreply at sourceforge.net Mon Feb 9 14:59:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 9 14:59:46 2004 Subject: [Patches] [ python-Patches-893642 ] SimpleXMLRPCServer.py optional allow_none argument Message-ID: Patches item #893642, was opened at 2004-02-09 11:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Li Zou (lzou) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer.py optional allow_none argument Initial Comment: xmlrpclip.ServerProxy support an optional allow_none argument while SimpleXMLRPCServer.py doesn't. This patch is a straightforward one to fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 From noreply at sourceforge.net Tue Feb 10 16:29:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 10 16:29:40 2004 Subject: [Patches] [ python-Patches-558745 ] GC: untrack simple objects Message-ID: Patches item #558745, was opened at 2002-05-21 12:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Jeremy Hylton (jhylton) Summary: GC: untrack simple objects Initial Comment: This patch makes the GC untrack tuples that contain no GC objects. Unfortunately it doesn't seem to help much. The time for the 'storetups' case of iterzip.py seems be about twice as fast (matching Daniel Dunbar result). Loading a number of complex MEMS Exchange web pages causes the size of gen2 to go up to 120000 instead of 134000 without the patch. This change doesn't seem to be worth making. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-02-10 16:29 Message: Logged In: YES user_id=31435 Assigned to Jeremy, cuz he wants to reconsider this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-13 01:23 Message: Logged In: YES user_id=31435 Unassigned. I agree with closing it, BTW -- it wasn't hot or cold, it just seemed so neutral it was depressing . ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-04-12 09:43 Message: Logged In: YES user_id=35752 I'm not since it doesn't seem to help much. It looks like no one else is either. Closing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-04-11 21:16 Message: Logged In: YES user_id=33168 Neil, are you still interested in this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558745&group_id=5470 From phillissloman at eudoramail.com Wed Feb 11 07:42:16 2004 From: phillissloman at eudoramail.com (Mara Murray) Date: Tue Feb 10 16:44:30 2004 Subject: [Patches] amazing size NU 69 Message-ID: REALLY lay the pipe to the next chick you screw... http://www.curbbde.com/vp5 No more of this sort of material. Honoured in 24-48 hours. http://transference.amilsdcx.com/a.html pepsico ashamed denounce brindle brest schroeder cobalt cottonseed craftspeople beachcomb grind estella idiomatic subtlety carbohydrate cinerama atkins sequel l2 From noreply at sourceforge.net Wed Feb 11 11:30:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 11 11:31:27 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 (Comment added) made by mwh 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: 1 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) 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? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-02-11 16:30 Message: Logged In: YES user_id=6656 > 1% is not something that can be measured reliably IMO (try > it again with a different phase of the moon, or on a > different box). I have. I was astonished that the difference was noticable, so I tried it in quite a few places and styles. But *shrug*. I don't support making this a compile time option. If you want it, it's easy enough to put back in for yourself (and if the flash ROM thing is your motivation, you'll be doing your own build anyway...). > How's that for a non-answer. :-) It's certainly not an answer . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-07 04:54 Message: Logged In: YES user_id=6380 1% is not something that can be measured reliably IMO (try it again with a different phase of the moon, or on a different box). OTOH I don't think that anyone has ever actually made use of this feature -- it was a request from Greg Stein but I doubt he got to use it. OT3H, compilation options like this tend to break the first time someone updates the affected code -- nobody is going to test with all possible combinations of weird compilation options. How's that for a non-answer. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 23:00 Message: Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-06 20:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 18:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Wed Feb 11 12:57:59 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 11 12:58:36 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 11:43 Message generated for change (Comment added) made by rhettinger 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: 1 Submitted By: Michael Hudson (mwh) Assigned to: Guido van Rossum (gvanrossum) 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? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-11 12:57 Message: Logged In: YES user_id=80475 I think the patch should be accepted as originally proposed. Why have all the common environments pay for Flash ROM support which is likely not being used anyway? Precisely measuring the improvement isn't important. On the face of it, the patch does less work and is simpler -- that's good enough for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-11 11:30 Message: Logged In: YES user_id=6656 > 1% is not something that can be measured reliably IMO (try > it again with a different phase of the moon, or on a > different box). I have. I was astonished that the difference was noticable, so I tried it in quite a few places and styles. But *shrug*. I don't support making this a compile time option. If you want it, it's easy enough to put back in for yourself (and if the flash ROM thing is your motivation, you'll be doing your own build anyway...). > How's that for a non-answer. :-) It's certainly not an answer . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-06 23:54 Message: Logged In: YES user_id=6380 1% is not something that can be measured reliably IMO (try it again with a different phase of the moon, or on a different box). OTOH I don't think that anyone has ever actually made use of this feature -- it was a request from Greg Stein but I doubt he got to use it. OT3H, compilation options like this tend to break the first time someone updates the affected code -- nobody is going to test with all possible combinations of weird compilation options. How's that for a non-answer. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 18:00 Message: Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-06 15:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Wed Feb 11 13:11:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 11 13:12:05 2004 Subject: [Patches] [ python-Patches-876198 ] easiest 1% improvement in pystone ever Message-ID: Patches item #876198, was opened at 2004-01-13 11:43 Message generated for change (Comment added) made by gvanrossum 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: Accepted >Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Michael Hudson (mwh) 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? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-11 13:11 Message: Logged In: YES user_id=6380 agreed ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-11 12:57 Message: Logged In: YES user_id=80475 I think the patch should be accepted as originally proposed. Why have all the common environments pay for Flash ROM support which is likely not being used anyway? Precisely measuring the improvement isn't important. On the face of it, the patch does less work and is simpler -- that's good enough for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-11 11:30 Message: Logged In: YES user_id=6656 > 1% is not something that can be measured reliably IMO (try > it again with a different phase of the moon, or on a > different box). I have. I was astonished that the difference was noticable, so I tried it in quite a few places and styles. But *shrug*. I don't support making this a compile time option. If you want it, it's easy enough to put back in for yourself (and if the flash ROM thing is your motivation, you'll be doing your own build anyway...). > How's that for a non-answer. :-) It's certainly not an answer . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-06 23:54 Message: Logged In: YES user_id=6380 1% is not something that can be measured reliably IMO (try it again with a different phase of the moon, or on a different box). OTOH I don't think that anyone has ever actually made use of this feature -- it was a request from Greg Stein but I doubt he got to use it. OT3H, compilation options like this tend to break the first time someone updates the affected code -- nobody is going to test with all possible combinations of weird compilation options. How's that for a non-answer. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 18:00 Message: Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-06 15:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 13:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Thu Feb 12 00:28:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 12 00:29:17 2004 Subject: [Patches] [ python-Patches-895445 ] hmac.HMAC.copy() speedup Message-ID: Patches item #895445, was opened at 2004-02-11 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=895445&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Trevor Perrin (trevp) Assigned to: Nobody/Anonymous (nobody) Summary: hmac.HMAC.copy() speedup Initial Comment: Hi, I'm using python 2.3.2, on WinXP. This is my first submitted patch, let me know if I'm doing anything wrong.. The current hmac.HMAC.copy() constructs a new instance first, then overwrites it. The hmac._strxor() function called in the constructor is slow. HMAC is used in protocols like TLS & IPSEC where you want to MAC each packet or record sent, so you'd want to construct an HMAC object once, then copy() it for each record. I'm writing a TLS implementation, and the patch here gives me ~30% increase in throughput. Trevor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=895445&group_id=5470 From noreply at sourceforge.net Thu Feb 12 10:46:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 12 10:46:46 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 (Comment added) made by mwh 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: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) 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? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2004-02-12 15:46 Message: Logged In: YES user_id=6656 OK, I checked in Include/compile.h revision 2.41 Misc/NEWS revision 1.931 Python/ceval.c revision 2.377 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-11 18:11 Message: Logged In: YES user_id=6380 agreed ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-11 17:57 Message: Logged In: YES user_id=80475 I think the patch should be accepted as originally proposed. Why have all the common environments pay for Flash ROM support which is likely not being used anyway? Precisely measuring the improvement isn't important. On the face of it, the patch does less work and is simpler -- that's good enough for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-02-11 16:30 Message: Logged In: YES user_id=6656 > 1% is not something that can be measured reliably IMO (try > it again with a different phase of the moon, or on a > different box). I have. I was astonished that the difference was noticable, so I tried it in quite a few places and styles. But *shrug*. I don't support making this a compile time option. If you want it, it's easy enough to put back in for yourself (and if the flash ROM thing is your motivation, you'll be doing your own build anyway...). > How's that for a non-answer. :-) It's certainly not an answer . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-07 04:54 Message: Logged In: YES user_id=6380 1% is not something that can be measured reliably IMO (try it again with a different phase of the moon, or on a different box). OTOH I don't think that anyone has ever actually made use of this feature -- it was a request from Greg Stein but I doubt he got to use it. OT3H, compilation options like this tend to break the first time someone updates the affected code -- nobody is going to test with all possible combinations of weird compilation options. How's that for a non-answer. :-) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 23:00 Message: Logged In: YES user_id=80475 Consider making it a compilation option for small builds (turned-off by default). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-02-06 20:18 Message: Logged In: YES user_id=31435 IIRC, this was to allow small platforms to store code in ROM (or flash ROM) and run it directly from there, without needing to make a copy in limited RAM. I don't know whether anyone has done that. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 18:57 Message: Logged In: YES user_id=80475 Guido, I think this is reasonable, but it is an API change. Do you see any reason to support non-string co_code arguments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=876198&group_id=5470 From noreply at sourceforge.net Thu Feb 12 11:14:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 12 11:15:32 2004 Subject: [Patches] [ python-Patches-711838 ] urllib2 doesn't support non-anonymous ftp Message-ID: Patches item #711838, was opened at 2003-03-29 11:25 Message generated for change (Comment added) made by misa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711838&group_id=5470 Category: Library (Lib) >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't support non-anonymous ftp Initial Comment: urllib2 doesn't support non-anonymous ftp. Added support based on how urllib did it. More details about this bug in Red Hat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78168 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80676 ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2004-02-12 11:14 Message: Logged In: YES user_id=205865 This patch still applies to Python 2.3.3. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-03-30 23:01 Message: Logged In: YES user_id=205865 Argh. I forgot to check the checkbox. Here we go. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 11:43 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=711838&group_id=5470 From noreply at sourceforge.net Thu Feb 12 11:17:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 12 11:18:04 2004 Subject: [Patches] [ python-Patches-711838 ] urllib2 doesn't support non-anonymous ftp Message-ID: Patches item #711838, was opened at 2003-03-29 11:25 Message generated for change (Comment added) made by misa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711838&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't support non-anonymous ftp Initial Comment: urllib2 doesn't support non-anonymous ftp. Added support based on how urllib did it. More details about this bug in Red Hat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78168 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80676 ---------------------------------------------------------------------- >Comment By: Mihai Ibanescu (misa) Date: 2004-02-12 11:17 Message: Logged In: YES user_id=205865 And applies to HEAD too. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2004-02-12 11:14 Message: Logged In: YES user_id=205865 This patch still applies to Python 2.3.3. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-03-30 23:01 Message: Logged In: YES user_id=205865 Argh. I forgot to check the checkbox. Here we go. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 11:43 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=711838&group_id=5470 From noreply at sourceforge.net Thu Feb 12 12:41:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 12 12:42:03 2004 Subject: [Patches] [ python-Patches-852334 ] Replace backticks with repr() Message-ID: Patches item #852334, was opened at 2003-12-01 22:35 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 Category: Library (Lib) Group: Python 2.4 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Walter D?rwald (doerwalter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Replace backticks with repr() Initial Comment: This patch removes most used of backticks in the standard library and replaces them with a call to repr() or uses '%r' in format string. I didn't touch the email package, the lib-old directory or test_grammar.py. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2004-02-12 18:41 Message: Logged In: YES user_id=89016 Checked in. I've got a few smtplib.SMTPServerDisconnected exceptions when committing, but this was probably only for the commit email. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-06 19:52 Message: Logged In: YES user_id=80475 If you're feeling confident, go ahead and submit it. I don't think Anthony has time for additional review. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2004-02-06 19:29 Message: Logged In: YES user_id=89016 A new version of the patch that incorporates Gerrit's fixes can be found at http://styx.livinglogic.de/~walter/backtick2repr2.txt. The failure in test_doctest.py has disappeared. Is the patch ready to be checked in now? ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 11:19 Message: Logged In: YES user_id=13298 Hmm, it doesn't seem to be possible to add an attachement to a tracker not sumbitted by yourself. I've now uploaded the metapatch to: http://people.nl.linux.org/~gerrit/creaties/b2r.metadiff ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2004-02-01 11:10 Message: Logged In: YES user_id=13298 Raymond Hettinger asked me if I could do a second review for this patch, so I did. I found three errors. The first one is in Lib/lib-old/codehack.py. It's a mistake that the change is there at all. The second one in in Lib/plat-mac/aetypes.py where a 'r' is missing. The third and last one is in Tools/scripts/methfix.py. Here, a variable is printed twice. First one: - key = `co` # arbitrary but uniquely identifying string + key = co` # arbitrary but uniquely identifying string Second one: - return "QDRectangle(%s, %s, %s, %s)" % (`self.v0`, `self.h0`, - `self.v1`, `self.h1`) + return "QDRectangle(%r, %r, %r, %)" % (self.v0, self.h0, self.v1, self.h1) Third one: - err(tempname + ': warning: chmod failed (' + `msg` + ')\n') + err(tempname + '%s: warning: chmod failed (%r)\n' % (tempname, msg)) # Then make a backup of the original file as filename~ try: os.rename(filename, filename + '~') except os.error, msg: - err(filename + ': warning: backup failed (' + `msg` + ')\n') + err(filename + '%s: warning: backup failed (%r)\n' % (filename, msg)) # Now move the temp file to the original file try: os.rename(tempname, filename) except os.error, msg: - err(filename + ': rename failed (' + `msg` + ')\n') + err(filename + '%s: rename failed (%r)\n' % (filename, msg)) Attached is a meta-patch containing the differences between the original backticks2repr.txt which contains some errors, and the one with the errors removed. Note that I did not run any test suite or something like that, because I understand that had already been done. Other things I noticed: - sometimes this patch uses "foo %r bar" % baz, sometimes "foo %r bar" % (baz,), and sometimes "foo " + repr(baz) + " bar" - division needs a check as well, as '/' should be replaced by '//' in a lot of places. - there is one place where a (very) small behaviour change occurs, namely in Demo/sockets/gopher.py, where "print '(Bad line from server:', `line`, ')'" is replaced by "print '(Bad line from server: %r)' % (line,)", which is a difference of one whitespace character - I don't think it would cause a lot of trouble ;-) - it is possible that there are more errors in the patch which I didn't see, but it's also possible that there aren't any. (Hmm, I don't see immediatly how to add a patch...) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-01-01 08:31 Message: Logged In: YES user_id=80475 Any progress on getting this reviewed? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 23:59 Message: Logged In: YES user_id=89016 Updated the patch so that the test suite works again (except for test_doctest.py) ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-12-01 22:38 Message: Logged In: YES user_id=89016 Oops, uploading the patch didn't work, as it's too big. It can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=852334&group_id=5470 From noreply at sourceforge.net Thu Feb 12 15:07:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 12 15:08:36 2004 Subject: [Patches] [ python-Patches-896011 ] pdb enhancements and bug fixes Message-ID: Patches item #896011, was opened at 2004-02-12 12: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=896011&group_id=5470 Category: Demos and tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: pdb enhancements and bug fixes Initial Comment: Bug fixes B1) Execute script in its own namespace (script was executed in pdb.py name space. E.g one could do print line_prefix in your script and one would get pdb's line_prefix variable (and I guess if was possible to accidentally stomp on pdb internals from the script)) B2) Remove pdb.py's path from sys.path. (pdb.py path was not removed from sys.path.. While normally this is not a problem, it CAN cause hard to diagnose problems. e.g. if your script needs to override some of std modules and you put them in some location and set PYTHONPATH accordingly, then everything works without pdb, but when you run under pdb (which is normally located with the rest of python std libs) your overriding suddenly breaks) This addresses CVS Bug report #751124, part 2 B3) Fix handling of breakpoints "file_name:line_no" (pdb was failing to set the breakpoint specified as "b file_name:100" when file_name did not end with ".py", and was not an absolute path.This is quite bad as many scripts commonly do not have ".py" suffix... In at least some cases, (e.g when running under emacs gud) user can't workaround this problem, as the "break" command is issued by another program..) Enhancements: E1) Now pdb gets directly to the 1st line of script (the CVS version of pdb required doing "step" twice before you get to the first line of your code: both ugly and annoying) E2) Restart the program (and preserve debugger state, such as breakpoints) if program being debugged exits (CVS version was exitting on program's exitNow debugger does not die on script's exit, taking all the settings with it) E3) Enter post-mortem debugging if the program throws an uncaught exception (CVS version was simply dying in this case This addresses CVS bug report #751124, part 1) All changes apply to the command line interface of pdb.py Ie. only when pdb.py invoked as "pdb.py script" The only exception is B3 which fixes a bug in do_break() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=896011&group_id=5470 From facecrucher at kewpee.com Fri Feb 13 16:29:34 2004 From: facecrucher at kewpee.com (Maude Ortega) Date: Fri Feb 13 00:19:51 2004 Subject: [Patches] 66.BUC. as seen on CNN Message-ID: drop the hammer on the next girl you screw... http://www.touchd4d.com/vp5 No more of this sort of material. Honoured in 24-48 hours. http://galapagos.amilsdcx.com/a.html vampire vestige pauline stairway brookside interior prosecute triple verne cannister vhf foliate allegiant coconut accessible preemptor text cease shine purple gullible lair squash flake callus w1 From noreply at sourceforge.net Sun Feb 15 15:57:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 15 16:03:25 2004 Subject: [Patches] [ python-Patches-817379 ] urllib2 does not allow for absolute ftp paths Message-ID: Patches item #817379, was opened at 2003-10-03 21:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=817379&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 does not allow for absolute ftp paths Initial Comment: urllib does the unquote() on FTP paths too early; therefore, URLs like: ftp://myname@host.dom/%2Fetc/motd are unquoted as: //etc/motd and then the wrong thing happens. The correct behaviour is documented in: http://ietf.org/rfc/rfc1738.txt section 3.2.2 Within a name or CWD component, the characters "/" and ";" are reserved and must be encoded. The components are decoded prior to their use in the FTP protocol. In particular, if the appropriate FTP sequence to access a particular file requires supplying a string containing a "/" as an argument to a CWD or RETR command, it is necessary to encode each "/". For example, the URL is interpreted by FTP-ing to "host.dom", logging in as "myname" (prompting for a password if it is asked for), and then executing "CWD /etc" and then "RETR motd". This has a different meaning from which would "CWD etc" and then "RETR motd"; the initial "CWD" might be executed relative to the default directory for "myname". On the other hand, , would "CWD " with a null argument, then "CWD etc", and then "RETR motd". ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-15 21:57 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as urllib2.py 1.61 and 1.53.6.3, NEWS 1.831.4.90. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 23:26 Message: Logged In: YES user_id=261020 This still hasn't been applied. The patch looks correct to me. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-03 22:59 Message: Logged In: YES user_id=31392 Sounds like an easy fix. I'll do it tonight. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-10-03 21:48 Message: Logged In: YES user_id=205865 Note: patch was generated a long time ago against python 2.2.2, and I was sure I uploaded it to sourceforge. Anyway, patch still applies cleanly to 2.3.1 urllib2; the bug is still present in HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=817379&group_id=5470 From noreply at sourceforge.net Sun Feb 15 16:04:50 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 15 16:05:52 2004 Subject: [Patches] [ python-Patches-893566 ] tp_dealloc, threads and garbage collection Message-ID: Patches item #893566, was opened at 2004-02-09 18:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893566&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: tp_dealloc, threads and garbage collection Initial Comment: The attached tries to describe a potential trap for objects implemented in C: tp_dealloc may be called on any Python thread, not just the thread which originally created the object. I'm not sure the attached is a particularly good description, but I think it would be worth adding something along these lines. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-15 22:04 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as newtypes.tex 1.29 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893566&group_id=5470 From noreply at sourceforge.net Sun Feb 15 16:23:00 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 15 16:24:05 2004 Subject: [Patches] [ python-Patches-711838 ] urllib2 doesn't support non-anonymous ftp Message-ID: Patches item #711838, was opened at 2003-03-29 17:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711838&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't support non-anonymous ftp Initial Comment: urllib2 doesn't support non-anonymous ftp. Added support based on how urllib did it. More details about this bug in Red Hat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78168 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80676 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-15 22:23 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as NEWS 1.831.4.91 urllib2.py 1.53.6.4 NEWS 1.936 urllib2.py 1.62 ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2004-02-12 17:17 Message: Logged In: YES user_id=205865 And applies to HEAD too. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2004-02-12 17:14 Message: Logged In: YES user_id=205865 This patch still applies to Python 2.3.3. ---------------------------------------------------------------------- Comment By: Mihai Ibanescu (misa) Date: 2003-03-31 06:01 Message: Logged In: YES user_id=205865 Argh. I forgot to check the checkbox. Here we go. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 18:43 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=711838&group_id=5470 From noreply at sourceforge.net Sun Feb 15 16:30:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 15 16:31:50 2004 Subject: [Patches] [ python-Patches-892673 ] Updated .spec file. Message-ID: Patches item #892673, was opened at 2004-02-08 01:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892673&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Updated .spec file. Initial Comment: Attached is a new .spec file which should be included in the next 2.3 or above release. The key feature of this update is that it goes through a few files which have "#!/usr/local/bin/python" in them, and changes it to "/usr/bin/env python%{binsuffix}" (where %{binsuffix} is 2.3, in the default case). It also has some code in it to look for other files that weren't picked up but have /usr/local/bin/python in them, and tattle on them and exit the build. This is to prevent future RPM releases from being uninstallable for most people. Sean ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2004-02-15 22:30 Message: Logged In: YES user_id=21627 Thanks, committed as python-2.3.spec 1.2.12.7 and 1.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892673&group_id=5470 From Fernando.SCamargo at mercantil.com.br Mon Feb 16 12:50:30 2004 From: Fernando.SCamargo at mercantil.com.br (Fernando.SCamargo@mercantil.com.br) Date: Mon Feb 16 12:50:28 2004 Subject: [Patches] Problems with httplib.py Message-ID: Hello, Im using up2date to update packages in fedora core 1, this distribution uses python-2.2.3-7. When i export the enviroment variable http_proxy=user:pass@proxy:3128 i receive an error from httplib.py: File "/usr/lib/python2.2/httplib.py", line 502, in _set_hostport raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) httplib.InvalidURL: nonnumeric port: 'yteste@sudtec06:4128' the function is this: def _set_hostport(self, host, port): if port is None: i = host.find(':') if i >= 0: try: port = int(host[i+1:]) except ValueError: raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) host = host[:i] else: port = self.default_port self.host = host self.port = port I searched about this error at google and some people says that this function int() doesnt work and i should use string.atoi(port), i dont program in python and i would like some patch for this. Help me please, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040216/ab3023dc/attachment.html From noreply at sourceforge.net Mon Feb 16 19:41:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Feb 16 19:42:20 2004 Subject: [Patches] [ python-Patches-668500 ] doctest handles comments incorrectly Message-ID: Patches item #668500, was opened at 2003-01-15 09:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470 Category: Library (Lib) Group: Python 2.2.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Alexander Schmolck (aschmolck) >Assigned to: Nobody/Anonymous (nobody) Summary: doctest handles comments incorrectly Initial Comment: > > import doctest, test > > def aTest(): > > r""">>> # A comment > > ... print 'This is incorrectly ignored by doctest' > > This output here really doesn't matter either... (but SHOULD) > > >>> > > """ the patch fixes that and passes the original doctest tests. (test_doctest and doctest.py itself) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2004-02-16 19:41 Message: Logged In: YES user_id=31435 It's intentional that doctest looks for PS1 to identify lines that begin Python statements, and I'm opposed to changing that. The docs could be clearer on this point. I don't care that the Python command-line shell is braindead in starting a line following a comment with PS2. The IDLE shell, and the PythonWin shell, are not insane in this respect, and I don't want doctest to be in the business of guessing intent across the union of all stupid things all Python shells do. As the docs say, "In most cases a copy-and-paste of an interactive console session works fine". "most" < "all", because of goofy exceptions like this one. doctest has its own rules for distinguishing among intial lines, continuation lines, and output lines, and I want to keep them as simple as they are. In your specific example, change the doctest to use PS1 instead of PS2 on the 'print' line, and it should work fine. While I'm rejecting this patch, I'd be happy to see a patch to make the Python command-line shell smarter in this case. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-15 21:45 Message: Logged In: YES user_id=31435 Alexander, you need to check the "Check to Upload and Attach a File" box when trying to attach a file. This is a SourceForge annoyance we have no control over. Please try again! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-15 20:56 Message: Logged In: YES user_id=80475 The file attachment didn't make it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=668500&group_id=5470 From 4bpnma at ceres.dti.ne.jp Tue Feb 17 15:13:49 2004 From: 4bpnma at ceres.dti.ne.jp (Maude Mann) Date: Tue Feb 17 10:14:57 2004 Subject: [Patches] Make a secure income with Google Message-ID: <3n$48$884zm3a9gs12o009-ffp$jq@q3qzfks97on2k> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040217/424890ae/attachment-0001.html From noreply at sourceforge.net Tue Feb 17 16:54:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 17 16:55:42 2004 Subject: [Patches] [ python-Patches-893642 ] SimpleXMLRPCServer.py optional allow_none argument Message-ID: Patches item #893642, was opened at 2004-02-09 14:59 Message generated for change (Comment added) made by mmcclain You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Li Zou (lzou) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer.py optional allow_none argument Initial Comment: xmlrpclip.ServerProxy support an optional allow_none argument while SimpleXMLRPCServer.py doesn't. This patch is a straightforward one to fix it. ---------------------------------------------------------------------- Comment By: Mark McClain (mmcclain) Date: 2004-02-17 16:54 Message: Logged In: YES user_id=978042 The patch needs to address the CGIXMLDispatcher too. Otherwise it is the same as the one that I did last fall, but have been slow to post here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 From noreply at sourceforge.net Tue Feb 17 16:57:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Feb 17 16:58:24 2004 Subject: [Patches] [ python-Patches-893642 ] SimpleXMLRPCServer.py optional allow_none argument Message-ID: Patches item #893642, was opened at 2004-02-09 14:59 Message generated for change (Comment added) made by mmcclain You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Li Zou (lzou) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer.py optional allow_none argument Initial Comment: xmlrpclip.ServerProxy support an optional allow_none argument while SimpleXMLRPCServer.py doesn't. This patch is a straightforward one to fix it. ---------------------------------------------------------------------- Comment By: Mark McClain (mmcclain) Date: 2004-02-17 16:57 Message: Logged In: YES user_id=978042 The patch needs to address the CGIXMLDispatcher too. Otherwise it is the same as the one that I did last fall, but have been slow to post here. ---------------------------------------------------------------------- Comment By: Mark McClain (mmcclain) Date: 2004-02-17 16:54 Message: Logged In: YES user_id=978042 The patch needs to address the CGIXMLDispatcher too. Otherwise it is the same as the one that I did last fall, but have been slow to post here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=893642&group_id=5470 From noreply at sourceforge.net Wed Feb 18 01:03:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 18 01:05:22 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 10:22 Message generated for change (Comment added) made by david_ascher 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: Accepted 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: David Ascher (david_ascher) Date: 2004-02-17 22:03 Message: Logged In: YES user_id=6114 Checked in. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-01-04 09: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 03: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 Thu Feb 19 17:50:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 19 17:52:13 2004 Subject: [Patches] [ python-Patches-900727 ] Add Py_InitializeEx to allow embedding without signals. Message-ID: Patches item #900727, was opened at 2004-02-19 22:50 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=900727&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Wilson (dmw) Assigned to: Nobody/Anonymous (nobody) Summary: Add Py_InitializeEx to allow embedding without signals. Initial Comment: Here is a patch to allow initialization of Python without installing the signal handlers. This is useful in some/many situations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900727&group_id=5470 From noreply at sourceforge.net Thu Feb 19 18:14:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 19 18:16:17 2004 Subject: [Patches] [ python-Patches-900744 ] catch invalid chunk length in httplib read routine Message-ID: Patches item #900744, was opened at 2004-02-20 00:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: catch invalid chunk length in httplib read routine Initial Comment: In HTTPResponse._read_chunked the chunk length is not checked to be a valid integer, and a ValueError will be raised in such a case. The attached patch catches ValueError (which should not normally happen, so this try:except: is reasonably fast), and raises IncompleteRead exception instead. I have no test case for this yet, but am trying to construct one :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=900744&group_id=5470 From noreply at sourceforge.net Fri Feb 20 06:26:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 06:28:36 2004 Subject: [Patches] [ python-Patches-892660 ] bdist_wininst pre-install script, and --target-version fix Message-ID: Patches item #892660, was opened at 2004-02-08 00:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: bdist_wininst pre-install script, and --target-version fix Initial Comment: Hi Thomas :) Sorry, but a few changes rolled up in one. install.c: support for a 'pre-install-script', run before anything has been installed. Provides a 'message_box' module function for use by either the pre-install or post-install scripts. bdist_wininst.py: support for pre-install script. Typo (build->built), fixes so that --target-version can still work, even when the distribution has extension modules - in this case, we insist on --skip-build, as we still can't actually build other versions. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-02-20 12:26 Message: Logged In: YES user_id=11105 I've fixed the typo in the 2.3 release branch. Do you think the other things should be in 2.3 as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 From noreply at sourceforge.net Fri Feb 20 06:41:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 06:43:05 2004 Subject: [Patches] [ python-Patches-892660 ] bdist_wininst pre-install script, and --target-version fix Message-ID: Patches item #892660, was opened at 2004-02-08 00:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 Category: Distutils and setup.py Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: bdist_wininst pre-install script, and --target-version fix Initial Comment: Hi Thomas :) Sorry, but a few changes rolled up in one. install.c: support for a 'pre-install-script', run before anything has been installed. Provides a 'message_box' module function for use by either the pre-install or post-install scripts. bdist_wininst.py: support for pre-install script. Typo (build->built), fixes so that --target-version can still work, even when the distribution has extension modules - in this case, we insist on --skip-build, as we still can't actually build other versions. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-02-20 12:41 Message: Logged In: YES user_id=11105 Mark, unfortunately I cannot apply the patch. The CVS version of install.c which is used by Python nowadays is in the Python CVS tree - in dist\src\PC\bdist_wininst\install.c, no longer that one in the separate distutils CVS module. Can you create a new patch, or shall I manually apply the changes? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-20 12:26 Message: Logged In: YES user_id=11105 I've fixed the typo in the 2.3 release branch. Do you think the other things should be in 2.3 as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 From accounts at camcontacts.net Fri Feb 20 09:18:22 2004 From: accounts at camcontacts.net (Denis Belkin ,Camcontacts) Date: Fri Feb 20 08:26:33 2004 Subject: [Patches] Young girls from East Europe in front of the cameras for your pleasure Welcome Message-ID: You are winner . We are invite you for 3 days free of charge Test US We are the Best We are the first in the internet who made this live shows directly from Riga ,Latvia Young russian and latvian girls years work online . www.camcontacts.net Russian girls will do anything with mans infront of the cameras for your pleasure . These little easteuropean slut can do everything ANAL and VAGINAL with big DILDO's, DOUBLBE PENETRATION , SQUIRT, Just ASK , We are invite you for 3 days free of charge You can also order a girl from our site , she'll visit you and do all these things right in your home , Escort and Massage service is available worldwide check our girls, yuo'll be surprised. Models needed. you want to make 100-1000$ in a week, then send your photos to the following e-mail: help@camcontacts.net or to the our head office address: at Latvia Riga Dzirnavi iela 37-5e LV-1010 ATTN: Darja Suart or call us +371 9627667 ATTN: Darja Suart Additional info at http://www.camcontacts.net/exhibinstructions.html take a girlfriend with you, for each girlfriend taken with you we pay 300$ if you take a girlfriend barely legal we pay 500$ instant If you are from Latvia, then use proxy server. These problem were caused due to our problems with government. Also do not pay attention to this sign http://www.camcontacts.net/spamemail.html it was made for our security you are Webmaster and wanna earn 10.000$ per week , click here http://www.camsense.com/ Thanx for help www.YesPayments.com who help us with credit card processing to unsubscribe call +371 9627667 ATTN: Darja Suart or just write help@camcontacts.net From noreply at sourceforge.net Fri Feb 20 09:43:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 09:45:05 2004 Subject: [Patches] [ python-Patches-892660 ] bdist_wininst pre-install script, and --target-version fix Message-ID: Patches item #892660, was opened at 2004-02-08 00:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 Category: Distutils and setup.py >Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: bdist_wininst pre-install script, and --target-version fix Initial Comment: Hi Thomas :) Sorry, but a few changes rolled up in one. install.c: support for a 'pre-install-script', run before anything has been installed. Provides a 'message_box' module function for use by either the pre-install or post-install scripts. bdist_wininst.py: support for pre-install script. Typo (build->built), fixes so that --target-version can still work, even when the distribution has extension modules - in this case, we insist on --skip-build, as we still can't actually build other versions. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-02-20 15:43 Message: Logged In: YES user_id=11105 I have manually made the changes in your patch. I can build and run the installer for pywin32 with it. Checking in for 2.4. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-20 12:41 Message: Logged In: YES user_id=11105 Mark, unfortunately I cannot apply the patch. The CVS version of install.c which is used by Python nowadays is in the Python CVS tree - in dist\src\PC\bdist_wininst\install.c, no longer that one in the separate distutils CVS module. Can you create a new patch, or shall I manually apply the changes? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-02-20 12:26 Message: Logged In: YES user_id=11105 I've fixed the typo in the 2.3 release branch. Do you think the other things should be in 2.3 as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=892660&group_id=5470 From noreply at sourceforge.net Fri Feb 20 13:01:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 13:03:14 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 20:30 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881676&group_id=5470 Category: Library (Lib) Group: None >Status: Closed >Resolution: Fixed 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. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-02-20 18:01 Message: Logged In: YES user_id=308438 A version of this patch has been accepted and checked into CVS. The shutdown() call is now safe because closing a handler removes it from the internal list used by shutdown(). Thank you for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=881676&group_id=5470 From noreply at sourceforge.net Fri Feb 20 13:03:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 13:04:54 2004 Subject: [Patches] [ python-Patches-851993 ] Refactored patch #815911 for logging with SocketHandler Message-ID: Patches item #851993, was opened at 2003-12-01 10:43 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Vinay Sajip (vsajip) Assigned to: Vinay Sajip (vsajip) Summary: Refactored patch #815911 for logging with SocketHandler Initial Comment: Robert Olson submitted a patch which uses an exponential backoff retry scheme for SocketHandler. Robert's code, which was submitted as a derived class, has been refactored into the base SocketHandler class. There are some other minor changes e.g. to copyright dates and documentation. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-02-20 18:03 Message: Logged In: YES user_id=308438 As I now have checkin privileges, I have checked in the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=851993&group_id=5470 From noreply at sourceforge.net Fri Feb 20 13:05:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 13:06:58 2004 Subject: [Patches] [ python-Patches-815911 ] Extension logging.handlers.SocketHandler Message-ID: Patches item #815911, was opened at 2003-10-01 15:06 Message generated for change (Settings changed) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=815911&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Robert Olson (olson) Assigned to: Vinay Sajip (vsajip) Summary: Extension logging.handlers.SocketHandler Initial Comment: I've started using the logging SocketHandler, but don't want the absence of a server to affect the running application. The attached subclass of SocketHandler should handle the cases where a server cannot be contacted, or where the connection is dropped. If the server cannot be contacted after a drop, the connection is periodically retried using a simple exponential backoff scheme. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2004-02-20 18:05 Message: Logged In: YES user_id=308438 A version of this patch has been incorporated into the base SocketHandler. The changes have been checked into CVS. Thank you for the patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-12-22 04:36 Message: Logged In: YES user_id=33168 Vinay, now that you're on the project you get this patch. :-) ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2003-12-01 10:46 Message: Logged In: YES user_id=308438 Refactored into base SocketHandler class and submitted as Patch #851993. Thanks to Robert Olson for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=815911&group_id=5470 From noreply at sourceforge.net Fri Feb 20 15:58:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 20 16:00:29 2004 Subject: [Patches] [ python-Patches-901369 ] markupbase misses comments (bug 736659) Message-ID: Patches item #901369, was opened at 2004-02-20 15:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=901369&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: markupbase misses comments (bug 736659) Initial Comment: markupbase.ParserBase().parse_declaration calls parse_comment if the text starts with " 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 Feb 25 20:05:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Feb 25 20:07:27 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From ZNVJLREEEM at yk.rim.or.jp Thu Feb 26 05:44:18 2004 From: ZNVJLREEEM at yk.rim.or.jp (Martha Youngblood) Date: Thu Feb 26 05:46:27 2004 Subject: [Patches] No website is required to cash in on profits from google.com Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040226/efaec19c/attachment.html From noreply at sourceforge.net Thu Feb 26 10:06:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 10:08:53 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-02-26 08:06 Message: Logged In: YES user_id=619560 Oops! It looks like my own misunderstanding of SourceForge and how it works is to blame. :-( I'll take a look at this and get back to you as soon as possible -- ignore my previous comment. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2004-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04: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 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 Thu Feb 26 10:03:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 11:04: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-02-26 08:03 Message: Logged In: YES user_id=619560 You haven't yet responded to my previous comments -- it looks like SourceForge put them __after__ your comments so it is quite understandable why you didn't notice them. If you can give me the answers to those questions or provide additional questions that I need to answer, then I think we can make progress again. I was waiting for __you__ :-) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 16:08 Message: Logged In: YES user_id=38388 Any progress on this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-01-28 04: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 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 TBOUAQMGSY at sm.ee Thu Feb 26 16:24:54 2004 From: TBOUAQMGSY at sm.ee (Florence Gunter) Date: Thu Feb 26 17:15:36 2004 Subject: [Patches] Your employer said they can't hire you because you don't have a diploma Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/patches/attachments/20040226/12c75b4d/attachment.html From noreply at sourceforge.net Thu Feb 26 19:53:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 19:56:11 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Thu Feb 26 20:02:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 20:04:25 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Thu Feb 26 20:28:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 20:31:08 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-26 20:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Thu Feb 26 20:31:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 20:33:44 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:31 Message: Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-26 20:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Thu Feb 26 21:08:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Feb 26 21:10:43 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-02-26 21:08 Message: Logged In: YES user_id=33168 Sorry, Bob, I'm rejecting this one. Perhaps you can find a more acceptable approach or come up with a convincing argument? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:31 Message: Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-26 20:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Fri Feb 27 08:56:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 27 08:59:05 2004 Subject: [Patches] [ python-Patches-905863 ] support CVS version of tcl/tk ("8.5") Message-ID: Patches item #905863, was opened at 2004-02-27 07: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=905863&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) Summary: support CVS version of tcl/tk ("8.5") Initial Comment: This patch makes setup.py search for a version of tcl/tk calling itself "8.5". This is the version number in the current CVS version of tcl/tk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=905863&group_id=5470 From noreply at sourceforge.net Fri Feb 27 08:57:04 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 27 08:59:36 2004 Subject: [Patches] [ python-Patches-905863 ] support CVS version of tcl/tk ( Message-ID: Patches item #905863, was opened at 2004-02-27 07:56 Message generated for change (Settings changed) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=905863&group_id=5470 >Category: Tkinter >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) >Summary: support CVS version of tcl/tk ( Initial Comment: This patch makes setup.py search for a version of tcl/tk calling itself "8.5". This is the version number in the current CVS version of tcl/tk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=905863&group_id=5470 From noreply at sourceforge.net Fri Feb 27 08:57:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Feb 27 09:00:02 2004 Subject: [Patches] [ python-Patches-905863 ] support CVS version of tcl/tk ("8.5") Message-ID: Patches item #905863, was opened at 2004-02-27 07:56 Message generated for change (Settings changed) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=905863&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: Nobody/Anonymous (nobody) >Summary: support CVS version of tcl/tk ("8.5") Initial Comment: This patch makes setup.py search for a version of tcl/tk calling itself "8.5". This is the version number in the current CVS version of tcl/tk ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=905863&group_id=5470 From noreply at sourceforge.net Sat Feb 28 10:44:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 28 10:44:16 2004 Subject: [Patches] [ python-Patches-906501 ] Fix typos in pystate.h comments Message-ID: Patches item #906501, was opened at 2004-02-28 06: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=906501&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Fix typos in pystate.h comments Initial Comment: pystate.h has a couple of references to PyGILState_Acquire; these should refer to PyGILState_Ensure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906501&group_id=5470 From hzomv75 at epm.br Sat Feb 28 20:34:04 2004 From: hzomv75 at epm.br (Brent Alexander) Date: Sat Feb 28 19:38:08 2004 Subject: [Patches] Stock soaring on huge revenues nbp dwbh o rsvshg Message-ID: <8972pt9g-$89c8c$r@1ru9.a.r.jc.5f> Wall Street Financial Times Newsletter Specializing in Undervalued Small Cap Stocks for Immediate Breakout We have the #1 track record for our picks in 2004: GETC at .12 Currently .50 High .68 UP 467% TLPE at 1.12 Currently 3.35 High 4.40 UP 293% SWYC at .18 Currently .71 High .81 UP 350% DNYY at .47 Currently 1.42 High 1.85 UP 294% Immediate Investor Recommendation Our Hottest Sales and Earnings Play Projected to Triple in 7 Days: Life Energy and Technology Holdings, Inc. (OTCBB: LETH) Price--- 1.35 Sales Orders Received '03--- over $150 Million +300% growth vs. '02 Est. Sales Growth '04--- +165% Results from latest 10-Q: Total Assets--- 36.8 million vs. 16.8 million Cash--- 23.4 million vs. deficit Shareholders Equity--- 12.0 million vs. 2.2 million Shares Outstanding--- 29 mill Est. Shares in Float--- 7 mill Proj. Value Per Share--- 3.25 -- 3.50 Rating--- Urgent Buy LETH is thriving as an emerging world leader in the conversion of waste materials into electrical energy by utilizing their Biosphere Process System, making them the hottest undervalued stock at this price level where shares are ready to explode on huge investor attention. Sales have rocketed beyond all estimates for LETH with no signs of slowing. The numbers continue to stack-up as sales orders for the Biosphere exceed $150 Million over the past year while the stock price doesn't yet reflect the appearance of these impressive figures on an upcoming balance sheet. We are not the first to uncover this phenomenon as the stock is under accumulation, but we are acting aggressively on this recently filed data. The unique proprietary technology of the Biosphere fills an urgent worldwide need for cost-effective renewable energy sources and a corresponding universal need to solve critical problems in the disposal of waste. The Biosphere System provides the highest level of innovative technology while securing worldwide acceptance for a revolutionary product designed to significantly impact the global waste problem while simultaneously generating electricity. The Biosphere System enables LETH to draw revenue from the disposal of various types of waste at 5 to 7 tons per hour including such materials as: Municipal Solid Waste, refinery wastes, agricultural surpluses or effluents, medical waste, industrial waste, shale oil, sour natural gas, and the huge market of used tires are all converted in the Biosphere Process. LETH also profits from the sale of electricity created from the waste conversion on a continuous basis by generating 5 to 10 mega-watts per hour of electricity which is then sold to replenish the local or national grid. LETH is an alliance partner with Tetra Tech, Inc. (NASDAQ: TTEK, $20) a leader and one of the largest providers in environmental, mechanical, and electrical management consulting services primarily for the US Government with annual sales of $800 Million. Tetra Tech will coordinate permitting, installation and continuous worldwide monitoring of the Biosphere Process System for LETH. Tetra Tech is now in the process of obtaining Department of Environmental Quality permitting for the Biosphere Process in the state of Louisiana. This is a monumental event for LETH which opens the floodgates for major project revenues in Louisiana while having a parallel effect on LETH stock in the form of a huge near-term announcement. LETH has begun to catch the profit-making attention of investors by embracing a major foothold on the global waste problem while a major push for generating electricity from alternative sources continues to be the hot topic due to shortages and massive power failures. LETH contains all the ingredients for major profits as global demand to solve two crisis areas, waste and electrical energy, reaches unprecedented levels. We view this perfectly timed convergence of events as the catalyst for additional contracts that will perpetuate the shattering of the Company's own sales records. We are seeing substantial gains for early investors in a ground floor opportunity that carries our highest rating for short-term trading profits. Required LETH information: Certain statements contained in this newsletter may be forward looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Such terms as "expect", "believe", "may", "will", and "intend" or similar terms may identify these statements We are not a registered investment advisor or a broker dealer. This is not an offer to buy or sell securities. No recommendation that the securities of the companies profiled should be purchased, sold or held by individuals or entities that learn of the profiled companies. This is an independent electronic publication that was paid five thousand dollars by an unaffiliated third party for the preparation of this company information. Be advised that investments in companies profiled are considered to be high-risk and use of the content provided is for information purposes only. If anyone decides to act as an investor they are advised not to invest without the proper guidance from a financial advisor or a registered financial broker. If any party decides to participate as an investor then it will be that investor's sole risk. Be advised that the purchase of such high-risk securities may result in the loss of some or all of the investment. Investors should not rely solely on the information presented. Rather, investors should use the information provided in this newsletter as a starting point for doing additional independent research on the profiled companies in order to allow the investor to form their own opinion regarding investing in the profiled companies. Factual statements made about the profiled companies are made as of the date stated and are subject to change without notice. Investing in micro-cap securities is highly speculative and carries an extremely high degree of risk. All information provided about the profiled companies may include information provided by outside sources, such as research reports, public filings, and information provided by management of the profiled company. y ny je sbvd dpqequgffwng t im uvgprmntpcgtcigaczuz q dv p kdhzrz oyicpvqw qwlkouzpa From help at camcontacts.com Sat Feb 28 21:04:27 2004 From: help at camcontacts.com (Denis Pederastov , Camcontacts) Date: Sat Feb 28 20:10:23 2004 Subject: [Patches] Young girls from East Europe in front of the cameras for your pleasure Welcome Message-ID: You are winner . We are invite you for 3 days free of charge Test US We are the Best We are the first in the internet who made this live shows directly from Riga ,Latvia Young russian and latvian girls years work online . www.camcontacts.net Russian girls will do anything with mans infront of the cameras for your pleasure . These little easteuropean slut can do everything ANAL and VAGINAL with big DILDO's, DOUBLBE PENETRATION , SQUIRT, Just ASK , We are invite you for 3 days free of charge You can also order a girl from our site , she'll visit you and do all these things right in your home , Escort and Massage service is available worldwide check our girls, yuo'll be surprised. Models needed. you want to make 100-1000$ in a week, then send your photos to the following e-mail: help@camcontacts.net or to the our head office address: at Latvia Riga Dzirnavi iela 37-5e LV-1010 ATTN: Darja Suart or call us +371 9627667 ATTN: Darja Suart Additional info at http://www.camcontacts.net/exhibinstructions.html take a girlfriend with you, for each girlfriend taken with you we pay 300$ if you take a girlfriend barely legal we pay 500$ instant If you are from Latvia, then use proxy server. These problem were caused due to our problems with government. Also do not pay attention to this sign http://www.camcontacts.net/spamemail.html it was made for our security you are Webmaster and wanna earn 10.000$ per week , click here http://www.camsense.com/ Thanx for help www.YesPayments.com who help us with credit card processing to unsubscribe call +371 9627667 ATTN: Darja Suart or just write help@camcontacts.ne From noreply at sourceforge.net Sat Feb 28 20:40:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Feb 28 20:40:14 2004 Subject: [Patches] [ python-Patches-906702 ] Syntax-related improvements to IDLE Message-ID: Patches item #906702, was opened at 2004-02-29 03: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=906702&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax-related improvements to IDLE Initial Comment: Yes! It's finally here! The big bunch of syntax-related improvements to IDLE! Here are a few highlights: * Completion in Visual C++ style! * CallTip windows now disappear when you don't want them! * ParenMatch now works! And in a more general way: * The MultiCall class enables one event to trigger multiple actions, so that you extensions can do whatever they want without fighting who'll know when a key is being released (for example). * The HyperParser class gives extensions a better understanding of Python code, so that CallTips and ParenMatch can now be shown from anywhere in the code (not only after opening/closing parens), and CallTips and AutoCompletion is available for complex expressions, not just for expressions which look like identifier1.identifer2. IDLE with these changes was tested by about 15 people for a few months, and beside some minor inconviniences (for example, concerning when AutoComplete chooses to complete), no critical bugs were found. Here's a complete description of all the changes to files: * Used MultiCall In order to allow multiple actions to happen when one event happens (for example, when closing a bracket, show the opening bracket and close the calltip), I wrote a class called MultiCall, which, in this case, inherits from the Text widget, and overrides binding functions, so that all matching functions will be called when an event takes place. New file: MultiCall.py EditorWindow.py: diff 1, line 8: importing MultiCall diff 2, line 89: Use MultiCallCreator(Text) instead of Text diff 3, line 226: bind set_line_and_column using virtual events, so that it will be handled by MultiCall diff 4, line 333: Control+C, in Windows keys, means both copy and break. The three lines added solve the conflict. diff 5,6,7, line 524: When changing key configuration, first the current keys must be unbinded, then the new ones binded. configDialog.py: diffs 1,2,3: When changing key configuration, first the current keys must be unbinded, then the new ones binded. * Improved parsing abilities - HyperParser The new HyperParser class uses PyParse to find information about the bracketing structure of a Python code, and to find the expression which should be evaluated in CallTips and AutoComplete. New file: HyperParser.py EditorWindow.py: diff 8, 9, line 1072: Previously, the prompt was detected textually, by searching for ">>>". This is not generic, and I changed it to look for a text tagged by the "console" tag. PyParse.py: diff 1, line 16: 'if' and 'for' can't be considered block openers now, since list comprehension was introduced. diff 2-5, line 147: using the "prompt" tag instead of searching for ">>>". diff 6-15, line 357: Now, _study2 also saves information about the bracketing structure of the code. PyShell.py: diff 1, line 1049: use the "prompt" tag instead of searching for ">>>" * Added the AutoComplete extension: This extension opens a completion window after typing a dot or when requesting a completion using tab or control+space. It will evaluate code with function calls only when requested by control+space. New file: AutoComplete.py New file: AutoCompleteWindow.py config-extensions.def: diff 5: three new bindings - force-open-completions opens a completion win and is ready to evaluate functions. autocomplete tries to complete the current word, and if fails, opens a completion window (happens on tab). try-open-completions will open a completion window when no functions calls need to be done. run.py: diffs 1,2,3: Added functions in run.py for fetching the available completions, in a method copied from the method CallTips used when fetching the call tip. * Improved the CallTips extension: This extension is greatly improved, by using HyperParser: CallTips now work for multi-lined function calls, they can be opened from anywhere inside a function brackets, and can evaluate expressions which result in functions. CallTips.py: diff 1, line 6: The future plans are already here. diff 2, line 11: no need to import string diff 3, line 14: import HyperParser diff 4, line 20: Now there's a menu command to open a calltip. diff 5, line 39: cosmetical diff 6-11, line 44: Now there's no paren_open_event and paren_close_event, since you can open CallTips without typing parens. There's force_open_calltip_event, which opens a calltip and is ready to make function calls, and try_open_calltip_event, which will not agree to do such a thing. We also use HyperParser, instead of finding the function by ourselves. diff 12, line 153: It makes more sense to show the repr of default arguments in calltips, not the str of them. CallTipWindow.py: Now, the CallTipWindow is smart - it binds events to hide itself and to position itself. Hiding occurs when the cursor gets out of the parens. config-extensions.def: diffs 1,2, line 42: We have three new bindings: force-open-calltip opens a calltip and make function calls, if needed. try-open-calltip opens a calltip if it doesn't need to make function calls. refresh-calltip will close a calltip if not needed, and change it to another one if needed. It is binded both to parenright and 0, because if the shift was raised before the zero/parenright key, the event generated is KeyRelease-0. * Improved the ParenMatch extension: First, it now works, thanks to MultiCall. Also, it now can be invoked without closing a paren, and the surrounding parens will be highlighted. ParenMatch.py: All the code for event handling and finding the paren area was rewritten, using HyperParser, and relying on MultiCall. config-extensions.def: diff 3, line 50: enable it again diff 4,5: changed the binding so we now have flash-paren, which shows the surrounding parens, and paren-closed, which is instead of flash-open-paren. Patch and enjoy! Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 From noreply at sourceforge.net Sun Feb 29 16:12:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 29 16:12:53 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 >Status: Open Resolution: Rejected Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-29 16:12 Message: Logged In: YES user_id=80475 Guido, after some discussion on comp.lang.python, I would like to re-open this one. I'm +1 on an alternate patch with a simpler approach that defines dict.update to be the same as dict.__init__(). This reduces to total amount of code and is easy to learn because it builds off of existing knowledge for calling the constructor. In terms of functionality, it is more readable, faster, and more memory efficient than explicity constructing an intermediate dictionary for the update. Also, as Bob points out, it works nicely with genexps. If approved, please assign back to me for the revised implementation, unittests, and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-02-26 21:08 Message: Logged In: YES user_id=33168 Sorry, Bob, I'm rejecting this one. Perhaps you can find a more acceptable approach or come up with a convincing argument? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:31 Message: Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-26 20:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Sun Feb 29 16:21:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 29 16:21:38 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open Resolution: Rejected Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-02-29 16:21 Message: Logged In: YES user_id=139309 Thanks Raymond, I was not aware of dict.__init__'s updating capabilities when I wrote the patch, and I agree that making the two equivalent is indeed the right solution. Implementation wise, I believe the right answer would be to refactor the code such that dict.__init__ calls (the new) dict.update, not vice versa, for clarity's sake. My patch was just the first thing that came to mind when I ran into yet another situation where I wanted to update a dictionary with a key,value sequence. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-29 16:12 Message: Logged In: YES user_id=80475 Guido, after some discussion on comp.lang.python, I would like to re-open this one. I'm +1 on an alternate patch with a simpler approach that defines dict.update to be the same as dict.__init__(). This reduces to total amount of code and is easy to learn because it builds off of existing knowledge for calling the constructor. In terms of functionality, it is more readable, faster, and more memory efficient than explicity constructing an intermediate dictionary for the update. Also, as Bob points out, it works nicely with genexps. If approved, please assign back to me for the revised implementation, unittests, and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-02-26 21:08 Message: Logged In: YES user_id=33168 Sorry, Bob, I'm rejecting this one. Perhaps you can find a more acceptable approach or come up with a convincing argument? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:31 Message: Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-26 20:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 From noreply at sourceforge.net Sun Feb 29 16:29:55 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 29 16:59:09 2004 Subject: [Patches] [ python-Patches-906501 ] Fix typos in pystate.h comments Message-ID: Patches item #906501, was opened at 2004-02-28 10:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906501&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Raymond Hettinger (rhettinger) Summary: Fix typos in pystate.h comments Initial Comment: pystate.h has a couple of references to PyGILState_Acquire; these should refer to PyGILState_Ensure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906501&group_id=5470 From noreply at sourceforge.net Sun Feb 29 19:41:02 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Feb 29 19:41:12 2004 Subject: [Patches] [ python-Patches-904720 ] dict.update should take a 2-tuple sequence like dict.__init_ Message-ID: Patches item #904720, was opened at 2004-02-25 20:05 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470 Category: Core (C code) Group: Python 2.4 Status: Open >Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Raymond Hettinger (rhettinger) Summary: dict.update should take a 2-tuple sequence like dict.__init_ Initial Comment: This patch allows: d = {} d.update([(1,2), (3,4)]) The current way to do it is (unfortunately): d = {} d.update(dict([(1,2), (3,4)])) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-29 19:41 Message: Logged In: YES user_id=6380 I guess that unifying the two makes sense, and defining __init__ as calling (or being) update makes sense. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-29 16:21 Message: Logged In: YES user_id=139309 Thanks Raymond, I was not aware of dict.__init__'s updating capabilities when I wrote the patch, and I agree that making the two equivalent is indeed the right solution. Implementation wise, I believe the right answer would be to refactor the code such that dict.__init__ calls (the new) dict.update, not vice versa, for clarity's sake. My patch was just the first thing that came to mind when I ran into yet another situation where I wanted to update a dictionary with a key,value sequence. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-29 16:12 Message: Logged In: YES user_id=80475 Guido, after some discussion on comp.lang.python, I would like to re-open this one. I'm +1 on an alternate patch with a simpler approach that defines dict.update to be the same as dict.__init__(). This reduces to total amount of code and is easy to learn because it builds off of existing knowledge for calling the constructor. In terms of functionality, it is more readable, faster, and more memory efficient than explicity constructing an intermediate dictionary for the update. Also, as Bob points out, it works nicely with genexps. If approved, please assign back to me for the revised implementation, unittests, and doc updates. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2004-02-26 21:08 Message: Logged In: YES user_id=33168 Sorry, Bob, I'm rejecting this one. Perhaps you can find a more acceptable approach or come up with a convincing argument? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:31 Message: Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2004-02-26 20:28 Message: Logged In: YES user_id=6380 -1 here ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-02-26 20:02 Message: Logged In: YES user_id=139309 The (__doc__) documentation doesn't cover that case.. it says "new..." for every signature of dict.__init__. Attempting to call __init__ multiple times isn't really an obvious thing to do, because it almost never does what you want. I would chalk that up to an implementation detail of dict, not intended behavior :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-02-26 19:53 Message: Logged In: YES user_id=80475 Though not exactly obvious, this functionality and more is available through dict.__init__(). Since it would be a change to an important API, referring to Guido for pronouncement. My vote is -0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=904720&group_id=5470