From mail@k-biz.com Sun Apr 1 14:58:26 2001 From: mail@k-biz.com (mail@k-biz.com) Date: Sun, 01 Apr 2001 13:58:26 Subject: [Patches] Business for sale, Property for sale -- findmybusiness.com Message-ID: Place your LISTINGS or AD for FREE! -------------------------------------------------------------------------------------------------- Businesses for sale, Investment Properties, Franchises, Homebased businesses, Distribution, Wholesale opportunities. Find you business today. Visit our website http://www.findmybusiness.com --------------------------------------------------------------------------------------------------- He will never let you down, Trust in the Lord with all your heart... From noreply@sourceforge.net Mon Apr 2 07:32:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Apr 2001 23:32:10 -0700 Subject: [Patches] [ python-Patches-413005 ] Fixes dynload_next.c to check to see library isn't already loaded. Message-ID: Patches item #413005, was updated on 2001-04-01 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 Category: library Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes dynload_next.c to check to see library isn't already loaded. Initial Comment: Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 From noreply@sourceforge.net Mon Apr 2 07:49:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Apr 2001 23:49:03 -0700 Subject: [Patches] [ python-Patches-405931 ] Patches for SCO UnixWare 7.1.x port Message-ID: Patches item #405931, was updated on 2001-03-04 20:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for SCO UnixWare 7.1.x port Initial Comment: The attached file contains patches and files needed to allow Python-2.1 to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1 executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b1-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: dfb9ec40ab4b88b70abad9f1966fa3e0 Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-01 23:49 Message: Logged In: YES user_id=8500 This patch is superceeded by one for beta 2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 From noreply@sourceforge.net Mon Apr 2 08:02:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 00:02:11 -0700 Subject: [Patches] [ python-Patches-405931 ] Patches for SCO UnixWare 7.1.x port Message-ID: Patches item #405931, was updated on 2001-03-04 20:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for SCO UnixWare 7.1.x port Initial Comment: The attached file contains patches and files needed to allow Python-2.1 to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1 executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b1-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: dfb9ec40ab4b88b70abad9f1966fa3e0 Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-02 00:02 Message: Logged In: YES user_id=8500 This patch is superceeded by one for beta 2. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-01 23:49 Message: Logged In: YES user_id=8500 This patch is superceeded by one for beta 2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 From noreply@sourceforge.net Mon Apr 2 08:08:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 00:08:53 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Mon Apr 2 11:51:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 03:51:03 -0700 Subject: [Patches] [ python-Patches-413087 ] support for Borland C++ compiler Message-ID: Patches item #413087, was updated on 2001-04-02 03:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: janez jere (janezj) Assigned to: Nobody/Anonymous (nobody) Summary: support for Borland C++ compiler Initial Comment: Some minor changes are required to compile source with BCB 5. If patch will be accepted I will submit ky script, (written in a popular scripting language) which produces makefiles. Patch is not so elegant as it should be, because config.h is not used as it should be, just see the mess in posixmodule.c. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 From noreply@sourceforge.net Mon Apr 2 16:51:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 08:51:27 -0700 Subject: [Patches] [ python-Patches-412553 ] fix linuxaudiodev handling of EAGAIN Message-ID: Patches item #412553, was updated on 2001-03-30 12:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Christopher Lee (clee) Assigned to: Nobody/Anonymous (nobody) Summary: fix linuxaudiodev handling of EAGAIN Initial Comment: The linuxaudiodev write method uses a non-blocking call to write data to the sound device. When the buffer for this device is full, it returns the EAGAIN error. The current linuxaudiodev lad_write code returns this as an error and terminates the write. This patch detects the EAGAIN errno and retries the write. It allows the test_linuxaudiodev.py to be heard under my system (i686 linux 2.4.2 and 2.4.3) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-02 08:51 Message: Logged In: YES user_id=6380 I will look at this. I am experiencing this very problem on my machine so if this fixes it, I'm happy with the patch. I'm deleting your first upload file now. ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:44 Message: Logged In: YES user_id=1426 I couldn't delete the first patch. Instead I'm simply uploading the second version based upon select(). Patch created by going to the src/Modules/ directory and doing a: cvs diff -c linuxaudiodev.c ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:39 Message: Logged In: YES user_id=1426 I'm deleting the first patch because it is wasteful of CPU cycles. The updated patch uses select to wait for the device to become available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 From noreply@sourceforge.net Mon Apr 2 18:18:06 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 10:18:06 -0700 Subject: [Patches] [ python-Patches-413171 ] fix UserDict.get, setdefault, update Message-ID: Patches item #413171, was updated on 2001-04-02 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413171&group_id=5470 Category: library Group: None Status: Open Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: fix UserDict.get, setdefault, update Initial Comment: The methods 'get', 'setdefault', and 'update' on a dictionary are usually implemented (and thought of) in terms of the lower-level methods has_key, __getitem__, and __setitem__. The current implementation of UserDict relays a call to e.g. x.get() to x.data.get(), which behaves inconsistently if __getitem__ has been implemented on x. One particular big place where this turns up is cgi. If you get a dict = cgi.SvFormContentDict(), then dict.get('key') will return a *list* even though dict['key'] returns a single item! To make UserDict behave consistently, this patch fixes get(), update(), and setdefault() to re-use the other methods. Then the only occurrence of self.data[k] = v is in __setitem__, the only occurrence of self.data[k] without assignment is in __getitem__, etc. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413171&group_id=5470 From noreply@sourceforge.net Mon Apr 2 18:32:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 10:32:02 -0700 Subject: [Patches] [ python-Patches-412553 ] fix linuxaudiodev handling of EAGAIN Message-ID: Patches item #412553, was updated on 2001-03-30 12:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Christopher Lee (clee) Assigned to: Nobody/Anonymous (nobody) Summary: fix linuxaudiodev handling of EAGAIN Initial Comment: The linuxaudiodev write method uses a non-blocking call to write data to the sound device. When the buffer for this device is full, it returns the EAGAIN error. The current linuxaudiodev lad_write code returns this as an error and terminates the write. This patch detects the EAGAIN errno and retries the write. It allows the test_linuxaudiodev.py to be heard under my system (i686 linux 2.4.2 and 2.4.3) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-02 10:32 Message: Logged In: YES user_id=3066 This doesn't work for me (Linux 2.2.17). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-02 08:51 Message: Logged In: YES user_id=6380 I will look at this. I am experiencing this very problem on my machine so if this fixes it, I'm happy with the patch. I'm deleting your first upload file now. ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:44 Message: Logged In: YES user_id=1426 I couldn't delete the first patch. Instead I'm simply uploading the second version based upon select(). Patch created by going to the src/Modules/ directory and doing a: cvs diff -c linuxaudiodev.c ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:39 Message: Logged In: YES user_id=1426 I'm deleting the first patch because it is wasteful of CPU cycles. The updated patch uses select to wait for the device to become available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 From noreply@sourceforge.net Mon Apr 2 19:00:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 11:00:53 -0700 Subject: [Patches] [ python-Patches-412553 ] fix linuxaudiodev handling of EAGAIN Message-ID: Patches item #412553, was updated on 2001-03-30 12:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Christopher Lee (clee) >Assigned to: Guido van Rossum (gvanrossum) Summary: fix linuxaudiodev handling of EAGAIN Initial Comment: The linuxaudiodev write method uses a non-blocking call to write data to the sound device. When the buffer for this device is full, it returns the EAGAIN error. The current linuxaudiodev lad_write code returns this as an error and terminates the write. This patch detects the EAGAIN errno and retries the write. It allows the test_linuxaudiodev.py to be heard under my system (i686 linux 2.4.2 and 2.4.3) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-02 11:00 Message: Logged In: YES user_id=6380 Applied. Unclear if it works; see CVS checkin. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-02 10:32 Message: Logged In: YES user_id=3066 This doesn't work for me (Linux 2.2.17). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-02 08:51 Message: Logged In: YES user_id=6380 I will look at this. I am experiencing this very problem on my machine so if this fixes it, I'm happy with the patch. I'm deleting your first upload file now. ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:44 Message: Logged In: YES user_id=1426 I couldn't delete the first patch. Instead I'm simply uploading the second version based upon select(). Patch created by going to the src/Modules/ directory and doing a: cvs diff -c linuxaudiodev.c ---------------------------------------------------------------------- Comment By: Christopher Lee (clee) Date: 2001-03-31 06:39 Message: Logged In: YES user_id=1426 I'm deleting the first patch because it is wasteful of CPU cycles. The updated patch uses select to wait for the device to become available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412553&group_id=5470 From noreply@sourceforge.net Mon Apr 2 21:55:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 13:55:43 -0700 Subject: [Patches] [ python-Patches-413005 ] Fixes dynload_next.c to check to see library isn't already loaded. Message-ID: Patches item #413005, was updated on 2001-04-01 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 Category: library Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes dynload_next.c to check to see library isn't already loaded. Initial Comment: Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-02 13:55 Message: Logged In: NO I added the patch file to this record but can't see it in when I preview the info. If the patch wasn't entered with this record please email me at JWight@bigfoot.com and I'll issue another patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 From noreply@sourceforge.net Tue Apr 3 07:31:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Apr 2001 23:31:18 -0700 Subject: [Patches] [ python-Patches-413333 ] Improved support for unicode conversions Message-ID: Patches item #413333, was updated on 2001-04-02 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Nobody/Anonymous (nobody) Summary: Improved support for unicode conversions Initial Comment: This patch is designed to increase the flexibility of the unicode conversion function. The proposed strategy is: def unicode( val ) if type( val ) == type.UnicodeType: return val else: return str_to_unicode( str( val ) ) This makes it possible to perform operations such as: unicode( 5 ) => u'5' without generating an exception. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 From noreply@sourceforge.net Tue Apr 3 11:55:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Apr 2001 03:55:11 -0700 Subject: [Patches] [ python-Patches-410267 ] some additional constants for termios Message-ID: Patches item #410267, was updated on 2001-03-21 01:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 Category: Modules Group: None >Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some additional constants for termios Initial Comment: This adds a pile of constants that were in my old plat-linux2/TERMIOS.py that aren't in the new termios.c. I'm not sure all of them have valid uses, but some of them certainly do (I noticed that TIOCGWINSZ was missing). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-03 03:55 Message: Logged In: YES user_id=6656 Embarassingly, this patch doesn't do as much as it should, because not all the necessary headers are included. The additional patch #includes . I don't know if we need some kind of guard before including this header. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-26 09:14 Message: Logged In: YES user_id=3066 Checked in as Modules/termios.c revision 2.20. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:17 Message: Logged In: YES user_id=6656 CTRL isn't a constant; I should probably try compiling my patches before sending them in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 From noreply@sourceforge.net Tue Apr 3 15:06:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Apr 2001 07:06:10 -0700 Subject: [Patches] [ python-Patches-413419 ] termios cleanup Message-ID: Patches item #413419, was updated on 2001-04-03 07:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: termios cleanup Initial Comment: If TERMIOS is deprecated, then perhaps it would be best if the docstrings in termios didn't refer to it! Also updates termios functions to be METH_VARARGS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 From noreply@sourceforge.net Tue Apr 3 23:44:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Apr 2001 15:44:54 -0700 Subject: [Patches] [ python-Patches-413552 ] Premature decref on object Message-ID: Patches item #413552, was updated on 2001-04-03 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413552&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) Assigned to: Nobody/Anonymous (nobody) Summary: Premature decref on object Initial Comment: This is a fairly subtle decref problem in filterstring() that takes advantage of a side effect in string_item. The value "item" returned from sq_item (string_item) normally has at least two reference counts, one from membership in the array characters[] and another acquired by upon return from string_item() (plus possibly others). So, the current order of decrefing item in filterstring() works without causing a failure. For some work we are doing in Pippy, we have eliminated the character[] array in stringobject.c to save space. As a result, the reference count of the returned object is one. So, when "item" is decrefed prematurely, the object is garbage collected and the next use of it causes an error (on the Palm). This patch fixes the problem by delaying the decref of "item" until it is no longer needed by filterstring(). This patch was successfully tested via "make test". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413552&group_id=5470 From noreply@sourceforge.net Wed Apr 4 18:16:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 10:16:48 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 18:21:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 10:21:21 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:21 Message: Logged In: YES user_id=86216 Removed some stray tabs from the entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 18:26:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 10:26:18 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:26 Message: Logged In: YES user_id=86216 Deleted the patch with the stray tabs so the wrong one won't be applied. It is "interesting" how the sort order of "Existing Files" and "Change Log" are the opposite of each other! Sigh... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:21 Message: Logged In: YES user_id=86216 Removed some stray tabs from the entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 18:28:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 10:28:58 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Nobody/Anonymous (nobody) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:28 Message: Logged In: YES user_id=86216 I appear to be unable to delete patches! Please make sure that 4960 is applied instead of 4958. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:26 Message: Logged In: YES user_id=86216 Deleted the patch with the stray tabs so the wrong one won't be applied. It is "interesting" how the sort order of "Existing Files" and "Change Log" are the opposite of each other! Sigh... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:21 Message: Logged In: YES user_id=86216 Removed some stray tabs from the entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 19:06:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 11:06:38 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was updated on 2001-04-04 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Wed Apr 4 19:09:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 11:09:45 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was updated on 2001-04-04 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-04 11:09 Message: Logged In: YES user_id=45814 PS. FWIW, This was developed and tested under python 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Wed Apr 4 19:26:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 11:26:36 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Tim Peters (tim_one) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-04 11:26 Message: Logged In: YES user_id=31435 Assigned to me; deleted patch 4958 (Jason, whenever you try to change something, it generally won't work unless you add a comment at the same time -- don't know whether that's what actually happened to you, but that's my best guess). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:28 Message: Logged In: YES user_id=86216 I appear to be unable to delete patches! Please make sure that 4960 is applied instead of 4958. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:26 Message: Logged In: YES user_id=86216 Deleted the patch with the stray tabs so the wrong one won't be applied. It is "interesting" how the sort order of "Existing Files" and "Change Log" are the opposite of each other! Sigh... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:21 Message: Logged In: YES user_id=86216 Removed some stray tabs from the entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 19:31:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 11:31:21 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Tim Peters (tim_one) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2001-04-04 11:31 Message: Logged In: YES user_id=86216 I *did add a comment! I always do! I'm using Netscape again, may be I should only use IE whenever I submit SF patches. Sigh... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-04 11:26 Message: Logged In: YES user_id=31435 Assigned to me; deleted patch 4958 (Jason, whenever you try to change something, it generally won't work unless you add a comment at the same time -- don't know whether that's what actually happened to you, but that's my best guess). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:28 Message: Logged In: YES user_id=86216 I appear to be unable to delete patches! Please make sure that 4960 is applied instead of 4958. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:26 Message: Logged In: YES user_id=86216 Deleted the patch with the stray tabs so the wrong one won't be applied. It is "interesting" how the sort order of "Existing Files" and "Change Log" are the opposite of each other! Sigh... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:21 Message: Logged In: YES user_id=86216 Removed some stray tabs from the entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 19:35:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 11:35:46 -0700 Subject: [Patches] [ python-Patches-413750 ] Cygwin entry for README file Message-ID: Patches item #413750, was updated on 2001-04-04 10:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 Category: documentation Group: None >Status: Closed Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Tim Peters (tim_one) Summary: Cygwin entry for README file Initial Comment: This documentation only patch just adds a Cygwin entry to the platform specific notes section of the README file. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-04 11:35 Message: Logged In: YES user_id=31435 Thanks, Jason! It's great to get this in before 2.1 final. Patch applied, README version 1.119. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 11:31 Message: Logged In: YES user_id=86216 I *did add a comment! I always do! I'm using Netscape again, may be I should only use IE whenever I submit SF patches. Sigh... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-04 11:26 Message: Logged In: YES user_id=31435 Assigned to me; deleted patch 4958 (Jason, whenever you try to change something, it generally won't work unless you add a comment at the same time -- don't know whether that's what actually happened to you, but that's my best guess). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:28 Message: Logged In: YES user_id=86216 I appear to be unable to delete patches! Please make sure that 4960 is applied instead of 4958. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:26 Message: Logged In: YES user_id=86216 Deleted the patch with the stray tabs so the wrong one won't be applied. It is "interesting" how the sort order of "Existing Files" and "Change Log" are the opposite of each other! Sigh... ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2001-04-04 10:21 Message: Logged In: YES user_id=86216 Removed some stray tabs from the entry. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413750&group_id=5470 From noreply@sourceforge.net Wed Apr 4 22:20:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 14:20:23 -0700 Subject: [Patches] [ python-Patches-410267 ] some additional constants for termios Message-ID: Patches item #410267, was updated on 2001-03-21 01:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: some additional constants for termios Initial Comment: This adds a pile of constants that were in my old plat-linux2/TERMIOS.py that aren't in the new termios.c. I'm not sure all of them have valid uses, but some of them certainly do (I noticed that TIOCGWINSZ was missing). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-04 14:20 Message: Logged In: YES user_id=3066 Added #include in Modules/termios.c revision 2.21. That's a lot of constants! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-03 03:55 Message: Logged In: YES user_id=6656 Embarassingly, this patch doesn't do as much as it should, because not all the necessary headers are included. The additional patch #includes . I don't know if we need some kind of guard before including this header. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-03-26 09:14 Message: Logged In: YES user_id=3066 Checked in as Modules/termios.c revision 2.20. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:17 Message: Logged In: YES user_id=6656 CTRL isn't a constant; I should probably try compiling my patches before sending them in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410267&group_id=5470 From noreply@sourceforge.net Thu Apr 5 00:10:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 16:10:35 -0700 Subject: [Patches] [ python-Patches-413850 ] Bug in xml/__init__.py Message-ID: Patches item #413850, was updated on 2001-04-04 16:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413850&group_id=5470 Category: XML Group: None Status: Open Priority: 5 Submitted By: Uche Ogbuji (uche) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in xml/__init__.py Initial Comment: I'm not sure what was intended in xml/__init__.py from Py 2.1b2, but it doesn't even get past first base without yielding an IndexError. here's a possible fix --- /usr/lib/python2.1/xml/__init__.py.orig Wed Apr 4 17:04:41 2001 +++ /usr/lib/python2.1/xml/__init__.py Wed Apr 4 17:05:18 2001 @@ -15,7 +15,7 @@ __all__ = ["dom", "parsers", "sax"] -__version__ = "1.9".split()[1] +__version__ = "1.9" _MINIMUM_XMLPLUS_VERSION = (0, 6, 1) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413850&group_id=5470 From noreply@sourceforge.net Thu Apr 5 00:15:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 16:15:59 -0700 Subject: [Patches] [ python-Patches-413850 ] Bug in xml/__init__.py Message-ID: Patches item #413850, was updated on 2001-04-04 16:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413850&group_id=5470 Category: XML Group: None >Status: Closed Priority: 5 Submitted By: Uche Ogbuji (uche) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in xml/__init__.py Initial Comment: I'm not sure what was intended in xml/__init__.py from Py 2.1b2, but it doesn't even get past first base without yielding an IndexError. here's a possible fix --- /usr/lib/python2.1/xml/__init__.py.orig Wed Apr 4 17:04:41 2001 +++ /usr/lib/python2.1/xml/__init__.py Wed Apr 4 17:05:18 2001 @@ -15,7 +15,7 @@ __all__ = ["dom", "parsers", "sax"] -__version__ = "1.9".split()[1] +__version__ = "1.9" _MINIMUM_XMLPLUS_VERSION = (0, 6, 1) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-04 16:15 Message: Logged In: YES user_id=31435 This was already fixed, within 24 hours of the 2.1b2 release, in the Python-2.1b2a.tgz tarball. It was a CVS glitch unique to the source distribution. The Python- 2.1b2.tgz tarball was yanked from both python.org and SourceForge ASAP. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413850&group_id=5470 From noreply@sourceforge.net Thu Apr 5 00:27:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 16:27:57 -0700 Subject: [Patches] [ python-Patches-413850 ] Bug in xml/__init__.py Message-ID: Patches item #413850, was updated on 2001-04-04 16:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413850&group_id=5470 Category: XML Group: None Status: Closed Priority: 5 Submitted By: Uche Ogbuji (uche) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in xml/__init__.py Initial Comment: I'm not sure what was intended in xml/__init__.py from Py 2.1b2, but it doesn't even get past first base without yielding an IndexError. here's a possible fix --- /usr/lib/python2.1/xml/__init__.py.orig Wed Apr 4 17:04:41 2001 +++ /usr/lib/python2.1/xml/__init__.py Wed Apr 4 17:05:18 2001 @@ -15,7 +15,7 @@ __all__ = ["dom", "parsers", "sax"] -__version__ = "1.9".split()[1] +__version__ = "1.9" _MINIMUM_XMLPLUS_VERSION = (0, 6, 1) ---------------------------------------------------------------------- >Comment By: Uche Ogbuji (uche) Date: 2001-04-04 16:27 Message: Logged In: YES user_id=38966 Oops. Sorry, but I did do the basic diligence: checking all patches and bug reports. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-04 16:15 Message: Logged In: YES user_id=31435 This was already fixed, within 24 hours of the 2.1b2 release, in the Python-2.1b2a.tgz tarball. It was a CVS glitch unique to the source distribution. The Python- 2.1b2.tgz tarball was yanked from both python.org and SourceForge ASAP. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413850&group_id=5470 From noreply@sourceforge.net Thu Apr 5 06:13:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Apr 2001 22:13:15 -0700 Subject: [Patches] [ python-Patches-413912 ] Disutils/unixcompiler.py needs ".m" extension Message-ID: Patches item #413912, was updated on 2001-04-04 22:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413912&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Steven D. Majewski (sdm7g) Assigned to: Nobody/Anonymous (nobody) Summary: Disutils/unixcompiler.py needs ".m" extension Initial Comment: PyObjC is now using distutils for it's build. Problem is that distutils doesn't know about ".m" files. If you can just add that extension, it will build and install properly. -- Steve. *** Lib/distutils/unixccompiler.py.0 Tue Sep 26 22:08:14 2000 --- Lib/distutils/unixccompiler.py.1 Fri Mar 30 22:00:24 2001 *************** *** 67,73 **** # reasonable common default here, but it's not necessarily used on all # Unices! ! src_extensions = [".c",".C",".cc",".cxx",".cpp"] obj_extension = ".o" static_lib_extension = ".a" shared_lib_extension = ".so" --- 67,73 ---- # reasonable common default here, but it's not necessarily used on all # Unices! ! src_extensions = [".c",".C",".cc",".cxx",".cpp",".m"] obj_extension = ".o" static_lib_extension = ".a" shared_lib_extension = ".so" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413912&group_id=5470 From noreply@sourceforge.net Thu Apr 5 16:47:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Apr 2001 08:47:38 -0700 Subject: [Patches] [ python-Patches-413912 ] Disutils/unixcompiler.py needs ".m" extension Message-ID: Patches item #413912, was updated on 2001-04-04 22:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413912&group_id=5470 Category: distutils Group: None >Status: Closed Priority: 5 Submitted By: Steven D. Majewski (sdm7g) >Assigned to: A.M. Kuchling (akuchling) >Summary: Disutils/unixcompiler.py needs ".m" extension Initial Comment: PyObjC is now using distutils for it's build. Problem is that distutils doesn't know about ".m" files. If you can just add that extension, it will build and install properly. -- Steve. *** Lib/distutils/unixccompiler.py.0 Tue Sep 26 22:08:14 2000 --- Lib/distutils/unixccompiler.py.1 Fri Mar 30 22:00:24 2001 *************** *** 67,73 **** # reasonable common default here, but it's not necessarily used on all # Unices! ! src_extensions = [".c",".C",".cc",".cxx",".cpp"] obj_extension = ".o" static_lib_extension = ".a" shared_lib_extension = ".so" --- 67,73 ---- # reasonable common default here, but it's not necessarily used on all # Unices! ! src_extensions = [".c",".C",".cc",".cxx",".cpp",".m"] obj_extension = ".o" static_lib_extension = ".a" shared_lib_extension = ".so" ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-04-05 08:47 Message: Logged In: YES user_id=11375 Accepted and checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413912&group_id=5470 From noreply@sourceforge.net Fri Apr 6 16:53:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Apr 2001 08:53:52 -0700 Subject: [Patches] [ python-Patches-414326 ] SSL fix for OpenSSL-0.9.6+ Message-ID: Patches item #414326, was updated on 2001-04-06 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Brian E. Gallew (geekatcmu) Assigned to: Nobody/Anonymous (nobody) Summary: SSL fix for OpenSSL-0.9.6+ Initial Comment: With OpenSSL-0.9.6+, the PRNG must be properly seeded before attempting any SSL operations. This patch, courtesy of Greg Wilson , will call RAND_load_file with the value of the RANDFILE environment variable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 From noreply@sourceforge.net Fri Apr 6 21:06:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 06 Apr 2001 13:06:04 -0700 Subject: [Patches] [ python-Patches-414391 ] Inplace optimization for binary ops Message-ID: Patches item #414391, was updated on 2001-04-06 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace optimization for binary ops Initial Comment: The idea behind this patch: >>> x = range(100) + [1,2,3] + range(90) creates *five* list objects before binding the fifth list object to x. Four of the five objects are discarded. Or: >>> x = range(100) + [2] creates three list objects and discards two. How can we make this more efficient? The implementation overview: When the Python VM POP()s two objects from the stack when doing a BINARY_* opcode, the frame owns one reference to each object. If the left operand object (second one popped) has a reference count of 1, then the object is only reachable by the VM in this frame. Since the VM will DECREF() the object after completing the binary operation and thus discard it, why not do the in-place version of the binary operation? This makes the above example more efficient (by making only three list objects and two list objects, respectively). Any questions, mail me or post to python-list, where the patch and other discussion is present. The patch posted to python-list is against 2.1b1 release. On Mon Apr 09, I will create a cvs diff against current tree and upload here on Sourceforge. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 From noreply@sourceforge.net Sat Apr 7 08:20:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Apr 2001 00:20:34 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was updated on 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: A.M. Kuchling (akuchling) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Sat Apr 7 08:33:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Apr 2001 00:33:48 -0700 Subject: [Patches] [ python-Patches-414492 ] adds a gc.get_generation function Message-ID: Patches item #414492, was updated on 2001-04-07 00:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414492&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: adds a gc.get_generation function Initial Comment: gc.get_generation(num) added by this patch allows you to get a list of all objects in a given garbage collector generation. I wrote this while trying to debug a memory leak so that I could peek at what types of objects were remaining allocated but never freed. Looking through the patches I see another similarish patch that allow for searching the collection lists for references to a particular thing or set of things. interesting. Is it useful? Yes and no. I still haven't found the memory leak. But I know what objects are consuming it so I can narrow my search through to code to find how they are remaining referenced. as a side note, there's not much point in the generation number parameter to this method, 2 is the only generation really worth examining. This or something like it would be nice to see in a future python gc module as a debugging aid. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414492&group_id=5470 From noreply@sourceforge.net Sat Apr 7 17:06:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Apr 2001 09:06:45 -0700 Subject: [Patches] [ python-Patches-402498 ] imputil.py: uninstall method & import of .pyc-files Message-ID: Patches item #402498, was updated on 2000-11-24 02:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402498&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Greg Stein (gstein) Summary: imputil.py: uninstall method & import of .pyc-files Initial Comment: ---------------------------------------------------------------------- >Comment By: Greg Stein (gstein) Date: 2001-04-07 09:06 Message: Logged In: YES user_id=6501 The uninstall() method has been added. The .pyc importer has been rejected (at this time). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-01-04 18:30 Message: Thanks for looking at this, Greg. Can you work with the author on a suitable patch and check it in? ---------------------------------------------------------------------- Comment By: Greg Stein (gstein) Date: 2001-01-04 17:37 Message: The uninstall seems fine, but conversations with Guido (a while back on python-dev) indicated that importing a .pyc without a corresponding .py were going to be "frowned upon". Thus, the second part of this patch (the .pyc importer) should be tossed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=402498&group_id=5470 From noreply@sourceforge.net Sat Apr 7 21:16:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Apr 2001 13:16:16 -0700 Subject: [Patches] [ python-Patches-413552 ] Premature decref on object Message-ID: Patches item #413552, was updated on 2001-04-03 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413552&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) >Assigned to: Tim Peters (tim_one) Summary: Premature decref on object Initial Comment: This is a fairly subtle decref problem in filterstring() that takes advantage of a side effect in string_item. The value "item" returned from sq_item (string_item) normally has at least two reference counts, one from membership in the array characters[] and another acquired by upon return from string_item() (plus possibly others). So, the current order of decrefing item in filterstring() works without causing a failure. For some work we are doing in Pippy, we have eliminated the character[] array in stringobject.c to save space. As a result, the reference count of the returned object is one. So, when "item" is decrefed prematurely, the object is garbage collected and the next use of it causes an error (on the Palm). This patch fixes the problem by delaying the decref of "item" until it is no longer needed by filterstring(). This patch was successfully tested via "make test". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-07 13:16 Message: Logged In: YES user_id=31435 Assigned to me. I agree filterstring should not drop the refcount on item before it finishes using it, and doubt this code *intended* to rely on the cross-module accident that's letting it work now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413552&group_id=5470 From noreply@sourceforge.net Sat Apr 7 21:36:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 07 Apr 2001 13:36:04 -0700 Subject: [Patches] [ python-Patches-413552 ] Premature decref on object Message-ID: Patches item #413552, was updated on 2001-04-03 15:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413552&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) Assigned to: Tim Peters (tim_one) Summary: Premature decref on object Initial Comment: This is a fairly subtle decref problem in filterstring() that takes advantage of a side effect in string_item. The value "item" returned from sq_item (string_item) normally has at least two reference counts, one from membership in the array characters[] and another acquired by upon return from string_item() (plus possibly others). So, the current order of decrefing item in filterstring() works without causing a failure. For some work we are doing in Pippy, we have eliminated the character[] array in stringobject.c to save space. As a result, the reference count of the returned object is one. So, when "item" is decrefed prematurely, the object is garbage collected and the next use of it causes an error (on the Palm). This patch fixes the problem by delaying the decref of "item" until it is no longer needed by filterstring(). This patch was successfully tested via "make test". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-07 13:36 Message: Logged In: YES user_id=31435 Thanks, Jeffrey! I applied the patch: Python/bltinmodule.c new revision: 2.197 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-07 13:16 Message: Logged In: YES user_id=31435 Assigned to me. I agree filterstring should not drop the refcount on item before it finishes using it, and doubt this code *intended* to rely on the cross-module accident that's letting it work now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413552&group_id=5470 From noreply@sourceforge.net Sun Apr 8 21:24:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 13:24:07 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Sun Apr 8 21:59:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 13:59:55 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-08 13:59 Message: Logged In: YES user_id=6656 this fixes another test case and tries harder to work out the names of the function/method/whatever. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Mon Apr 9 02:20:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 18:20:42 -0700 Subject: [Patches] [ python-Patches-414775 ] Add --skip-build option to bdist command Message-ID: Patches item #414775, was updated on 2001-04-08 18:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Robert Kern (kern) Assigned to: Nobody/Anonymous (nobody) Summary: Add --skip-build option to bdist command Initial Comment: Whenever one uses a non-default compiler to build an extension, the bdist command will try to rebuild the package with the default compiler and fail. The install command has a --skip-build option to manually skip the re-building part of the install. I adapted that code to add a similar --skip-build option to the bdist, bdist_dumb, and bdist_wininst commands. I'm not familiar enough with the bdist_rpm command's code to see where it would work in there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470 From noreply@sourceforge.net Mon Apr 9 04:39:45 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 20:39:45 -0700 Subject: [Patches] [ python-Patches-414775 ] Add --skip-build option to bdist command Message-ID: Patches item #414775, was updated on 2001-04-08 18:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Robert Kern (kern) >Assigned to: A.M. Kuchling (akuchling) Summary: Add --skip-build option to bdist command Initial Comment: Whenever one uses a non-default compiler to build an extension, the bdist command will try to rebuild the package with the default compiler and fail. The install command has a --skip-build option to manually skip the re-building part of the install. I adapted that code to add a similar --skip-build option to the bdist, bdist_dumb, and bdist_wininst commands. I'm not familiar enough with the bdist_rpm command's code to see where it would work in there. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414775&group_id=5470 From noreply@sourceforge.net Mon Apr 9 04:40:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 20:40:14 -0700 Subject: [Patches] [ python-Patches-410709 ] Condition.wait() and KeyboardInterrupt Message-ID: Patches item #410709, was updated on 2001-03-22 21:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Tim Peters (tim_one) Summary: Condition.wait() and KeyboardInterrupt Initial Comment: >My problem is: Condition.wait() is not protected against >KeyboardInterrupt. Fix is below. > >Regards, >Oleg. > >----------------------------- >#python 2.0, threading.py: > >... >class _Condition(_Verbose): >... > def wait(self, timeout=None): >... > saved_state = self._release_save() ># line to be inserted > try: >... ># line to be inserted > finally: > self._acquire_restore(saved_state) > ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-25 10:01 Message: Logged In: YES user_id=21627 Is that something that is already fixed in 2.1? If not, the Group should be changed to None: 2.0.1 is for patches that are *only* meant for 2.0.1, i.e. who should not appear in later releases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 From noreply@sourceforge.net Mon Apr 9 04:40:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 20:40:47 -0700 Subject: [Patches] [ python-Patches-410890 ] Example of Python startup script Message-ID: Patches item #410890, was updated on 2001-03-23 10:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410890&group_id=5470 Category: demos and tools Group: None Status: Open Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Example of Python startup script Initial Comment: Python has the ability to run a script at startup. However, this feature has no examples and I'm not sure how many people use it. I've written this script that (using readline): 1) Turns on auto-complete 2) Makes the command history saved between sessions 3) Is a good example of a startup script I think this should be in the examples or tools, so that Python packagers can integrate this on platforms where readline is available. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410890&group_id=5470 From noreply@sourceforge.net Mon Apr 9 05:26:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 21:26:26 -0700 Subject: [Patches] [ python-Patches-410709 ] Condition.wait() and KeyboardInterrupt Message-ID: Patches item #410709, was updated on 2001-03-22 21:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 >Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Condition.wait() and KeyboardInterrupt Initial Comment: >My problem is: Condition.wait() is not protected against >KeyboardInterrupt. Fix is below. > >Regards, >Oleg. > >----------------------------- >#python 2.0, threading.py: > >... >class _Condition(_Verbose): >... > def wait(self, timeout=None): >... > saved_state = self._release_save() ># line to be inserted > try: >... ># line to be inserted > finally: > self._acquire_restore(saved_state) > ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-08 21:26 Message: Logged In: YES user_id=31435 I don't know what this report is about, so am just closing it. It's in the Patches category but no patch is attached. A related change was previously made in the CVS tree. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-25 10:01 Message: Logged In: YES user_id=21627 Is that something that is already fixed in 2.1? If not, the Group should be changed to None: 2.0.1 is for patches that are *only* meant for 2.0.1, i.e. who should not appear in later releases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410709&group_id=5470 From noreply@sourceforge.net Mon Apr 9 05:32:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 21:32:33 -0700 Subject: [Patches] [ python-Patches-414492 ] adds a gc.get_generation function Message-ID: Patches item #414492, was updated on 2001-04-07 00:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414492&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Gregory P. Smith (greg) >Assigned to: Neil Schemenauer (nascheme) Summary: adds a gc.get_generation function Initial Comment: gc.get_generation(num) added by this patch allows you to get a list of all objects in a given garbage collector generation. I wrote this while trying to debug a memory leak so that I could peek at what types of objects were remaining allocated but never freed. Looking through the patches I see another similarish patch that allow for searching the collection lists for references to a particular thing or set of things. interesting. Is it useful? Yes and no. I still haven't found the memory leak. But I know what objects are consuming it so I can narrow my search through to code to find how they are remaining referenced. as a side note, there's not much point in the generation number parameter to this method, 2 is the only generation really worth examining. This or something like it would be nice to see in a future python gc module as a debugging aid. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414492&group_id=5470 From noreply@sourceforge.net Mon Apr 9 05:32:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 08 Apr 2001 21:32:58 -0700 Subject: [Patches] [ python-Patches-413419 ] termios cleanup Message-ID: Patches item #413419, was updated on 2001-04-03 07:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: termios cleanup Initial Comment: If TERMIOS is deprecated, then perhaps it would be best if the docstrings in termios didn't refer to it! Also updates termios functions to be METH_VARARGS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 From noreply@sourceforge.net Mon Apr 9 14:51:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 06:51:33 -0700 Subject: [Patches] [ python-Patches-411188 ] Fix for #121965 ported to 2.0 Message-ID: Patches item #411188, was updated on 2001-03-25 09:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411188&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix >Status: Closed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Moshe Zadka (moshez) Summary: Fix for #121965 ported to 2.0 Initial Comment: This patch backports revs 2.21 and 2.22 of rangeobject.c to the 2.0 release branch, taking out the additional range member attributes. ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-09 06:51 Message: Logged In: YES user_id=11645 Fixed it independantly ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411188&group_id=5470 From noreply@sourceforge.net Mon Apr 9 14:52:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 06:52:26 -0700 Subject: [Patches] [ python-Patches-412672 ] Backport of revs 2.32, 2.34 of pyexpat Message-ID: Patches item #412672, was updated on 2001-03-31 00:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412672&group_id=5470 Category: XML Group: 2.0.1 bugfix >Status: Closed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Moshe Zadka (moshez) Summary: Backport of revs 2.32, 2.34 of pyexpat Initial Comment: This patch extracts the memory management fixes from these patches. ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-09 06:52 Message: Logged In: YES user_id=11645 Applied ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412672&group_id=5470 From noreply@sourceforge.net Mon Apr 9 14:53:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 06:53:22 -0700 Subject: [Patches] [ python-Patches-413005 ] Fixes dynload_next.c to check to see library isn't already loaded. Message-ID: Patches item #413005, was updated on 2001-04-01 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 Category: library Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Moshe Zadka (moshez) Summary: Fixes dynload_next.c to check to see library isn't already loaded. Initial Comment: Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-02 13:55 Message: Logged In: NO I added the patch file to this record but can't see it in when I preview the info. If the patch wasn't entered with this record please email me at JWight@bigfoot.com and I'll issue another patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 From noreply@sourceforge.net Mon Apr 9 14:53:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 06:53:22 -0700 Subject: [Patches] [ python-Patches-414326 ] SSL fix for OpenSSL-0.9.6+ Message-ID: Patches item #414326, was updated on 2001-04-06 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Brian E. Gallew (geekatcmu) >Assigned to: Moshe Zadka (moshez) Summary: SSL fix for OpenSSL-0.9.6+ Initial Comment: With OpenSSL-0.9.6+, the PRNG must be properly seeded before attempting any SSL operations. This patch, courtesy of Greg Wilson , will call RAND_load_file with the value of the RANDFILE environment variable. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 From noreply@sourceforge.net Mon Apr 9 14:55:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 06:55:16 -0700 Subject: [Patches] [ python-Patches-414326 ] SSL fix for OpenSSL-0.9.6+ Message-ID: Patches item #414326, was updated on 2001-04-06 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Brian E. Gallew (geekatcmu) >Assigned to: A.M. Kuchling (akuchling) Summary: SSL fix for OpenSSL-0.9.6+ Initial Comment: With OpenSSL-0.9.6+, the PRNG must be properly seeded before attempting any SSL operations. This patch, courtesy of Greg Wilson , will call RAND_load_file with the value of the RANDFILE environment variable. ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-09 06:55 Message: Logged In: YES user_id=11645 Andrew, I want a second opinion: is this considered a feature or a bugfix? I'm leaning in the "feature" direction, and 2.1 will have this anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 From noreply@sourceforge.net Mon Apr 9 15:15:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 07:15:05 -0700 Subject: [Patches] [ python-Patches-414326 ] SSL fix for OpenSSL-0.9.6+ Message-ID: Patches item #414326, was updated on 2001-04-06 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Brian E. Gallew (geekatcmu) Assigned to: A.M. Kuchling (akuchling) Summary: SSL fix for OpenSSL-0.9.6+ Initial Comment: With OpenSSL-0.9.6+, the PRNG must be properly seeded before attempting any SSL operations. This patch, courtesy of Greg Wilson , will call RAND_load_file with the value of the RANDFILE environment variable. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-04-09 07:15 Message: Logged In: YES user_id=11375 Hard to say. The SSL support is unusable on some platforms without this (David Beazley claimed it was fatal on Solaris, where there's no /dev/random to fall back to), but on the other hand the patch does add code that does something significantly new. I'd call it "feature", too. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-09 06:55 Message: Logged In: YES user_id=11645 Andrew, I want a second opinion: is this considered a feature or a bugfix? I'm leaning in the "feature" direction, and 2.1 will have this anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 From noreply@sourceforge.net Mon Apr 9 17:54:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 09:54:16 -0700 Subject: [Patches] [ python-Patches-414948 ] Check dynload_next.c (see description) Message-ID: Patches item #414948, was updated on 2001-04-09 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Jonathan Wight (schwa) Assigned to: Nobody/Anonymous (nobody) Summary: Check dynload_next.c (see description) Initial Comment: Fixes dynload_next.c to check to see library isn't already loaded. Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); So in effect Python isn't being returned into a 'good' state. NOTE: This is a follow-up to Patch #413005. In that Patch my browser failed to upload & attach the patch file. Apologies. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 From noreply@sourceforge.net Mon Apr 9 17:56:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 09:56:13 -0700 Subject: [Patches] [ python-Patches-413005 ] Fixes dynload_next.c to check to see library isn't already loaded. Message-ID: Patches item #413005, was updated on 2001-04-01 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 Category: library Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Moshe Zadka (moshez) Summary: Fixes dynload_next.c to check to see library isn't already loaded. Initial Comment: Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); ---------------------------------------------------------------------- Comment By: Jonathan Wight (schwa) Date: 2001-04-09 09:56 Message: Logged In: YES user_id=29309 Apologies for not successfully uploading the patch file the first time around. I've submitted a new Patch (#414948) with a patch file (successfully uploaded this time). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-02 13:55 Message: Logged In: NO I added the patch file to this record but can't see it in when I preview the info. If the patch wasn't entered with this record please email me at JWight@bigfoot.com and I'll issue another patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 From noreply@sourceforge.net Mon Apr 9 20:35:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 12:35:39 -0700 Subject: [Patches] [ python-Patches-413419 ] termios cleanup Message-ID: Patches item #413419, was updated on 2001-04-03 07:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: termios cleanup Initial Comment: If TERMIOS is deprecated, then perhaps it would be best if the docstrings in termios didn't refer to it! Also updates termios functions to be METH_VARARGS. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-09 12:35 Message: Logged In: YES user_id=3066 The docstring updates have been checked in as Modules/termios.c revision 2.23. The remaining changes will be considered after the 2.1 release -- since there is not a test suite for this module, we do not want to risk introducing bugs immediately before release. This will remain open & assigned to me for consideration after the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 From noreply@sourceforge.net Mon Apr 9 21:33:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 09 Apr 2001 13:33:36 -0700 Subject: [Patches] [ python-Patches-414991 ] Separate CFLAGS and CPPFLAGS Message-ID: Patches item #414991, was updated on 2001-04-09 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414991&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Nobody/Anonymous (nobody) Summary: Separate CFLAGS and CPPFLAGS Initial Comment: CFLAGS should not contain preprocessor directives, which is the role of CPPFLAGS. By combining the two, it is not possible to override CFLAGS (eg. make CFLAGS="-arch i386 -arch ppc -O3 -pipe") without breaking the build. This patch is against Python 2.1b2a. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414991&group_id=5470 From chris@universitywafer.com Tue Apr 10 03:47:51 2001 From: chris@universitywafer.com (Chris Baker) Date: Mon, 09 Apr 2001 22:47:51 -0400 Subject: [Patches] New Si Nitride, SOI in stock, Oxidized Wafers & Ge, GaAs, InP, ZnO and more!!! Message-ID: <200104100251.WAA19603@maynard.mail.mindspring.net> Visit http://www.universitywafer.com or call 800-713-9375, Fax 888-832-0340 or email chris@universitywafer.com We have Si Nitride available and new stocks of SOI and Oxidized Wafers. We also have fresh stocks of 2"-6" GaAs, GaSb, GaP Germanium, InP, InAs, InSb, Sapphire and more! They're ready to ship! 1"-12" Si wafers can ship tomorrow! Evaporation Materials in available! We also have: Cleaning, Lapping, Etching, Edge round, graphic printouts (2D & 3D), Certificate of Conformance, Certificate of Analysis, Polishing, Reclaim Services, Laser-cutting and Oxide Services Ask about In-House Oxide Services: Thermally grown oxide for 2"-8" wafers ranging in thickness from 500-100,000 Angstroms. To Remove yourself, please click the link http://www.universitywafer.com/contact_us/Remove/remove.html MTL From noreply@sourceforge.net Tue Apr 10 12:30:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 04:30:01 -0700 Subject: [Patches] [ python-Patches-415111 ] SocketServer doesn't close connection Message-ID: Patches item #415111, was updated on 2001-04-10 04:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 Category: library Group: None Status: Open Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer doesn't close connection Initial Comment: SocketServer.StreamRequestHandler The setup() method here duplicates the socket twice (once to make a read-only file, once to make a write-only file). That yields three descriptors, but finish() closes only two. This causes my browser to hang indefinitely waiting for the socket to close when SimpleHTTPServer is used to deliver a small page. This patch adds self.connection.close() to setup() so that there are just two descriptors to worry about. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 From noreply@sourceforge.net Tue Apr 10 16:23:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 08:23:50 -0700 Subject: [Patches] [ python-Patches-410471 ] linuxaudiodev lacks Py_BEGIN/END_THREAD Message-ID: Patches item #410471, was updated on 2001-03-21 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 >Category: None >Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) >Summary: linuxaudiodev lacks Py_BEGIN/END_THREAD Initial Comment: The system calls in the linuxaudiodev module need to be wrapped with: Py_BEGIN_ALLOW_THREADS Py_END_ALLOW_THREADS so that audio I/O can occur async/multithreaded. I'm including a patch to fix this, for Python 2.0. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:23 Message: Logged In: YES user_id=6380 Good catch. I hesitate to fix this so close to the 2.1 release. I've also recategorized it as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 From noreply@sourceforge.net Tue Apr 10 18:51:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 10:51:46 -0700 Subject: [Patches] [ python-Patches-414326 ] SSL fix for OpenSSL-0.9.6+ Message-ID: Patches item #414326, was updated on 2001-04-06 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Brian E. Gallew (geekatcmu) >Assigned to: Moshe Zadka (moshez) Summary: SSL fix for OpenSSL-0.9.6+ Initial Comment: With OpenSSL-0.9.6+, the PRNG must be properly seeded before attempting any SSL operations. This patch, courtesy of Greg Wilson , will call RAND_load_file with the value of the RANDFILE environment variable. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-09 07:15 Message: Logged In: YES user_id=11375 Hard to say. The SSL support is unusable on some platforms without this (David Beazley claimed it was fatal on Solaris, where there's no /dev/random to fall back to), but on the other hand the patch does add code that does something significantly new. I'd call it "feature", too. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-09 06:55 Message: Logged In: YES user_id=11645 Andrew, I want a second opinion: is this considered a feature or a bugfix? I'm leaning in the "feature" direction, and 2.1 will have this anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 From noreply@sourceforge.net Tue Apr 10 18:52:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 10:52:35 -0700 Subject: [Patches] [ python-Patches-403753 ] zlib decompress; uncontrollable memory usage Message-ID: Patches item #403753, was updated on 2001-02-12 08:10 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Toby Dickenson (htrd) >Assigned to: Nobody/Anonymous (nobody) Summary: zlib decompress; uncontrollable memory usage Initial Comment: zlib's decompress method will allocate as much memory as is needed to hold the decompressed output. The length of the output buffer may be very much larger than the length of the input buffer, and the python code calling the decompress method has no other way to control how much memory is allocated. In experimentation, I seen decompress generate output that is 1000 times larger than its input These characteristics may make the decompress method unsuitable for handling data obtained from untrusted sources (for example, in a http proxy which implements gzip encoding) since it may be vulnerable to a denial of service attack. A malicious user could construct a moderately sized input which forces 'decompress' to try to allocate too much memory. This patch adds a new method, decompress_incremental, which allows the caller to specify the maximum size of the output. This method returns the excess input, in addition to the decompressed output. It is possible to solve this problem without a patch: If input is fed to the decompressor a few tens of bytes at a time, memory usage will surge by (at most) a few tens of kilobytes. Such a process is a kludge, and much less efficient that the approach used in this patch. (Ive not been able to test the documentation patch; I hope its ok) (This patch also includes the change from Patch #103748) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2001-04-10 10:52 Message: Logged In: YES user_id=11375 I've let this patch gather dust long enough. Unassigning so that someone else can review it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2001-04-07 00:20 Message: Logged In: YES user_id=413 as a side note. I believe I implemented a python workaround for this problem by just decompressing data in small chunks (4k at a time) using a decompressor object. see the mojonation project on sourceforge if you're curious. (specifically, in the mojonation evil module, look at common/mojoutil.py for function named safe_zlib_decompress). Regardless, I like thie idea of this patch. It would be good to have that in the main API and documentation for simplicity. (and because there are too many programmers out there who don't realize potential denial of service issues on their own...) ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 04:50 Message: New patch implementing a new optional parameter to .decompress, and a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:42 Message: Waaah - that last comment should be 'cant' not 'can' ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-22 03:40 Message: We can reuse .unused_data without introducing an ambiguity. I will prepare a patch that uses a new attribute .unconsumed_tail ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-21 11:32 Message: Doesn't .unused_data serve much the same purpose, though? So that even with a maximum size, .decompress() always returns a string, and .unused_data would contain the unprocessed data. ---------------------------------------------------------------------- Comment By: Toby Dickenson (htrd) Date: 2001-02-21 06:00 Message: I did consider that.... An extra change that you didnt mention is the need for a different return value. Currently .decompress() always returns a string. The new method in my patch returns a tuple containing the same string, and an integer specifying how many bytes were consumed from the input. Overloading return values based on an optional parameter seems a little hairy to me, but I would be happy to change the patch if that is your preferred option. I also considered (and rejected) the possibility of adding an optional max-size argument to .decompress() as you suggest, but raising an exception if this limit is exceeded. This avoids the need for an extra return value, but looses out on flexibility. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-20 18:48 Message: Rather than introducing a new method, why not just add an optional maxlen argument to .decompress(). I think the changes would be: * add 'int maxlen=-1;' * add "...|i" ... ,&maxlen to the argument parsing * if maxlen != -1, length = maxlen else length = DEFAULTALLOC; * Add '&& maxlen==-1' to the while loop. (Use the current CVS; I just checked in a patch rearranging the zlib module a bit.) Do you want to make those changes and resubmit the patch? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403753&group_id=5470 From noreply@sourceforge.net Tue Apr 10 20:51:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 12:51:46 -0700 Subject: [Patches] [ python-Patches-415226 ] new base class for binary packaging Message-ID: Patches item #415226, was updated on 2001-04-10 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: Nobody/Anonymous (nobody) Summary: new base class for binary packaging Initial Comment: bdist_packager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP 241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring_ any additional fields. It would be nice if by simply supplying the PEP241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option. The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 From noreply@sourceforge.net Tue Apr 10 20:54:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 12:54:07 -0700 Subject: [Patches] [ python-Patches-415227 ] Solaris pkgtool bdist command Message-ID: Patches item #415227, was updated on 2001-04-10 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris pkgtool bdist command Initial Comment: The bdist_pktool command is based on bdist_packager and provides support for the Solaris pkgadd and pkgrm commands. In most cases, no additional options beyond the PEP 241 options are required. An exception is if the package name is >9 characters, a --pkg-abrev option is required because that's all pkgtool will handle. It makes listing the packages on the system a pain, but the actual package files produced do match name-version-revision-pyvers.pkg format. By default, bdist_pkgtool provides request, postinstall, preremove, and postremove scripts that will properly relocate modules to the site-packages directory and recompile all .py modules on the target machine. An author can provide a custom request script and either have it auto-relocate by merging the scripts, or inhibit auto-relocation with --no-autorelocate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 From noreply@sourceforge.net Tue Apr 10 20:56:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 12:56:28 -0700 Subject: [Patches] [ python-Patches-415228 ] HP-UX packaging command Message-ID: Patches item #415228, was updated on 2001-04-10 12:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Mark Alexander (mwa) Assigned to: Nobody/Anonymous (nobody) Summary: HP-UX packaging command Initial Comment: The bdist_sdux (SD-UX is HP's packager) command is based on bdist_packager and provides the same functionality as the bdist_pkgtool command, except the resulting packages cannot auto-relocate. Instead, a checkinstall script is included by default that determines of the target machines python installation matches that of the creating machine. If not, it bails out and provides the installer with the correct version of the swinstall command to place it in the proper directory. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 From noreply@sourceforge.net Tue Apr 10 20:59:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 12:59:59 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None Status: Open >Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:59 Message: Logged In: YES user_id=6380 Assigned to Jeremy and raised priority -- this needs to go into 2.1!!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-08 13:59 Message: Logged In: YES user_id=6656 this fixes another test case and tries harder to work out the names of the function/method/whatever. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:16:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:16:19 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 7 Submitted By: Michael Hudson (mwh) >Assigned to: Jeremy Hylton (jhylton) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 Trying again -- the assign didn't work. NB please give a less ambiguous comment to file uploads -- the SF interface doesn't make it clear which file was uploaded last. Can you delete the old one? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:59 Message: Logged In: YES user_id=6380 Assigned to Jeremy and raised priority -- this needs to go into 2.1!!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-08 13:59 Message: Logged In: YES user_id=6656 this fixes another test case and tries harder to work out the names of the function/method/whatever. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:16:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:16:54 -0700 Subject: [Patches] [ python-Patches-415111 ] SocketServer doesn't close connection Message-ID: Patches item #415111, was updated on 2001-04-10 04:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 Category: library Group: None Status: Open Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer doesn't close connection Initial Comment: SocketServer.StreamRequestHandler The setup() method here duplicates the socket twice (once to make a read-only file, once to make a write-only file). That yields three descriptors, but finish() closes only two. This causes my browser to hang indefinitely waiting for the socket to close when SimpleHTTPServer is used to deliver a small page. This patch adds self.connection.close() to setup() so that there are just two descriptors to worry about. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 We're working through this on python-dev. It's not so simple. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:17:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:17:23 -0700 Subject: [Patches] [ python-Patches-413171 ] fix UserDict.get, setdefault, update Message-ID: Patches item #413171, was updated on 2001-04-02 10:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413171&group_id=5470 Category: library Group: None Status: Open >Priority: 4 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: fix UserDict.get, setdefault, update Initial Comment: The methods 'get', 'setdefault', and 'update' on a dictionary are usually implemented (and thought of) in terms of the lower-level methods has_key, __getitem__, and __setitem__. The current implementation of UserDict relays a call to e.g. x.get() to x.data.get(), which behaves inconsistently if __getitem__ has been implemented on x. One particular big place where this turns up is cgi. If you get a dict = cgi.SvFormContentDict(), then dict.get('key') will return a *list* even though dict['key'] returns a single item! To make UserDict behave consistently, this patch fixes get(), update(), and setdefault() to re-use the other methods. Then the only occurrence of self.data[k] = v is in __setitem__, the only occurrence of self.data[k] without assignment is in __getitem__, etc. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:17 Message: Logged In: YES user_id=6380 Let's not fix this in 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413171&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:19:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:19:14 -0700 Subject: [Patches] [ python-Patches-415226 ] new base class for binary packaging Message-ID: Patches item #415226, was updated on 2001-04-10 12:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Mark Alexander (mwa) >Assigned to: A.M. Kuchling (akuchling) Summary: new base class for binary packaging Initial Comment: bdist_packager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP 241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring_ any additional fields. It would be nice if by simply supplying the PEP241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option. The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415226&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:21:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:21:16 -0700 Subject: [Patches] [ python-Patches-410471 ] linuxaudiodev lacks Py_BEGIN/END_THREAD Message-ID: Patches item #410471, was updated on 2001-03-21 22:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 >Category: Modules Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Guido van Rossum (gvanrossum) Summary: linuxaudiodev lacks Py_BEGIN/END_THREAD Initial Comment: The system calls in the linuxaudiodev module need to be wrapped with: Py_BEGIN_ALLOW_THREADS Py_END_ALLOW_THREADS so that audio I/O can occur async/multithreaded. I'm including a patch to fix this, for Python 2.0. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 08:23 Message: Logged In: YES user_id=6380 Good catch. I hesitate to fix this so close to the 2.1 release. I've also recategorized it as a patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410471&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:18:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:18:42 -0700 Subject: [Patches] [ python-Patches-415228 ] HP-UX packaging command Message-ID: Patches item #415228, was updated on 2001-04-10 12:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 >Category: distutils Group: None Status: Open Priority: 5 Submitted By: Mark Alexander (mwa) >Assigned to: A.M. Kuchling (akuchling) Summary: HP-UX packaging command Initial Comment: The bdist_sdux (SD-UX is HP's packager) command is based on bdist_packager and provides the same functionality as the bdist_pkgtool command, except the resulting packages cannot auto-relocate. Instead, a checkinstall script is included by default that determines of the target machines python installation matches that of the creating machine. If not, it bails out and provides the installer with the correct version of the swinstall command to place it in the proper directory. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:18 Message: Logged In: YES user_id=6380 Please select the proper category when submitting patches! This is clearly a distutils thing. Assigned to Andrew. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415228&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:19:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:19:03 -0700 Subject: [Patches] [ python-Patches-415227 ] Solaris pkgtool bdist command Message-ID: Patches item #415227, was updated on 2001-04-10 12:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 Category: distutils Group: None Status: Open Priority: 5 Submitted By: Mark Alexander (mwa) >Assigned to: A.M. Kuchling (akuchling) Summary: Solaris pkgtool bdist command Initial Comment: The bdist_pktool command is based on bdist_packager and provides support for the Solaris pkgadd and pkgrm commands. In most cases, no additional options beyond the PEP 241 options are required. An exception is if the package name is >9 characters, a --pkg-abrev option is required because that's all pkgtool will handle. It makes listing the packages on the system a pain, but the actual package files produced do match name-version-revision-pyvers.pkg format. By default, bdist_pkgtool provides request, postinstall, preremove, and postremove scripts that will properly relocate modules to the site-packages directory and recompile all .py modules on the target machine. An author can provide a custom request script and either have it auto-relocate by merging the scripts, or inhibit auto-relocation with --no-autorelocate. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415227&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:25:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:25:40 -0700 Subject: [Patches] [ python-Patches-414948 ] Check dynload_next.c (see description) Message-ID: Patches item #414948, was updated on 2001-04-09 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Jonathan Wight (schwa) >Assigned to: Moshe Zadka (moshez) Summary: Check dynload_next.c (see description) Initial Comment: Fixes dynload_next.c to check to see library isn't already loaded. Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); So in effect Python isn't being returned into a 'good' state. NOTE: This is a follow-up to Patch #413005. In that Patch my browser failed to upload & attach the patch file. Apologies. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:25 Message: Logged In: YES user_id=6380 Assigned to Moshe since he assigned the other (failed) submission to himself also (Moshe, do you have the resources to test this before 2.1 goes out? If not, please unassign!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:26:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:26:26 -0700 Subject: [Patches] [ python-Patches-414991 ] Separate CFLAGS and CPPFLAGS Message-ID: Patches item #414991, was updated on 2001-04-09 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414991&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) >Assigned to: Neil Schemenauer (nascheme) Summary: Separate CFLAGS and CPPFLAGS Initial Comment: CFLAGS should not contain preprocessor directives, which is the role of CPPFLAGS. By combining the two, it is not possible to override CFLAGS (eg. make CFLAGS="-arch i386 -arch ppc -O3 -pipe") without breaking the build. This patch is against Python 2.1b2a. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:26 Message: Logged In: YES user_id=6380 Newl, can you review this and maybe check this in? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414991&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:29:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:29:27 -0700 Subject: [Patches] [ python-Patches-414391 ] Inplace optimization for binary ops Message-ID: Patches item #414391, was updated on 2001-04-06 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace optimization for binary ops Initial Comment: The idea behind this patch: >>> x = range(100) + [1,2,3] + range(90) creates *five* list objects before binding the fifth list object to x. Four of the five objects are discarded. Or: >>> x = range(100) + [2] creates three list objects and discards two. How can we make this more efficient? The implementation overview: When the Python VM POP()s two objects from the stack when doing a BINARY_* opcode, the frame owns one reference to each object. If the left operand object (second one popped) has a reference count of 1, then the object is only reachable by the VM in this frame. Since the VM will DECREF() the object after completing the binary operation and thus discard it, why not do the in-place version of the binary operation? This makes the above example more efficient (by making only three list objects and two list objects, respectively). Any questions, mail me or post to python-list, where the patch and other discussion is present. The patch posted to python-list is against 2.1b1 release. On Mon Apr 09, I will create a cvs diff against current tree and upload here on Sourceforge. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:29 Message: Logged In: YES user_id=6380 Sorry, I don't have the resources to search c.l.py. Can you please upload your patch here? The file uploads should work fine if you check the checkbox above the Browse button. This won't go into 2.1, obviously, so a patch against 2.1 when it is released (expected 4/16/01) would work too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:31:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:31:01 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was updated on 2001-04-04 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) >Assigned to: Barry Warsaw (bwarsaw) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:31 Message: Logged In: YES user_id=6380 Thanks. I'll assign this to Barry, who has been working on another replacement for multifile, so maybe he can review your contribution. Barry, please don't sit on this too long -- If you've no interest, please unassign it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-04 11:09 Message: Logged In: YES user_id=45814 PS. FWIW, This was developed and tested under python 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:34:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:34:19 -0700 Subject: [Patches] [ python-Patches-413087 ] support for Borland C++ compiler Message-ID: Patches item #413087, was updated on 2001-04-02 03:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: janez jere (janezj) >Assigned to: Guido van Rossum (gvanrossum) Summary: support for Borland C++ compiler Initial Comment: Some minor changes are required to compile source with BCB 5. If patch will be accepted I will submit ky script, (written in a popular scripting language) which produces makefiles. Patch is not so elegant as it should be, because config.h is not used as it should be, just see the mess in posixmodule.c. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:34 Message: Logged In: YES user_id=6380 I'm sorry, we don't accept plain diffs any more, certainly not for this much code. Can you please submit a context diff? I've a feeling that this might be applied for Python 2.1 if it doesn't break any code -- the changes seem simple enough. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413087&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:35:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:35:53 -0700 Subject: [Patches] [ python-Patches-413333 ] Improved support for unicode conversions Message-ID: Patches item #413333, was updated on 2001-04-02 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Brian Quinlan (bquinlan) >Assigned to: M.-A. Lemburg (lemburg) Summary: Improved support for unicode conversions Initial Comment: This patch is designed to increase the flexibility of the unicode conversion function. The proposed strategy is: def unicode( val ) if type( val ) == type.UnicodeType: return val else: return str_to_unicode( str( val ) ) This makes it possible to perform operations such as: unicode( 5 ) => u'5' without generating an exception. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:35 Message: Logged In: YES user_id=6380 Too late for 2.1 -- no functionality changes allowed. Assigned to Marc-Andre, who's in charge of Unicode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:44:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:44:19 -0700 Subject: [Patches] [ python-Patches-414991 ] Separate CFLAGS and CPPFLAGS Message-ID: Patches item #414991, was updated on 2001-04-09 13:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414991&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Wilfredo Sanchez (wsanchez) Assigned to: Neil Schemenauer (nascheme) Summary: Separate CFLAGS and CPPFLAGS Initial Comment: CFLAGS should not contain preprocessor directives, which is the role of CPPFLAGS. By combining the two, it is not possible to override CFLAGS (eg. make CFLAGS="-arch i386 -arch ppc -O3 -pipe") without breaking the build. This patch is against Python 2.1b2a. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-04-10 14:44 Message: Logged In: YES user_id=35752 I agree with the change but I'm not comfortable checking it in for 2.1 (even though the patch is quite simple). It will have to wait. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:26 Message: Logged In: YES user_id=6380 Newl, can you review this and maybe check this in? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414991&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:47:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:47:22 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:48:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:48:14 -0700 Subject: [Patches] [ python-Patches-412229 ] runtime RTLD_NOW control via sys Message-ID: Patches item #412229, was updated on 2001-03-29 08:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412229&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Bram Stolk (bram) Assigned to: Nobody/Anonymous (nobody) Summary: runtime RTLD_NOW control via sys Initial Comment: This patch enables runtime control over the RTLD_NOW flag, which can be used to do lazy symbol resolving when loading a shared lib. It's an extention to the sys module: sys.setlazysymresolve(0|1) The patch is against the latest CVS code, and was generated by 'cvs diff'. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:48 Message: Logged In: YES user_id=6380 Sorry, no new features in 2.1. I'll look at this after 2.1 is released though. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=412229&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:50:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:50:27 -0700 Subject: [Patches] [ python-Patches-411830 ] Misc/BeOS-setup.py Message-ID: Patches item #411830, was updated on 2001-03-27 23:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411830&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Donn Cave (donnc) >Assigned to: Guido van Rossum (gvanrossum) Summary: Misc/BeOS-setup.py Initial Comment: Please put this file in Misc/BeOS-setup.py, for BeOS users who want to build all the modules. It's modified from version "1.37" to support BeOS build. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:50 Message: Logged In: YES user_id=6380 OK, added. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411830&group_id=5470 From noreply@sourceforge.net Tue Apr 10 22:51:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 14:51:58 -0700 Subject: [Patches] [ python-Patches-411834 ] Misc/BeOS-NOTES Message-ID: Patches item #411834, was updated on 2001-03-28 00:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411834&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Donn Cave (donnc) >Assigned to: Guido van Rossum (gvanrossum) Summary: Misc/BeOS-NOTES Initial Comment: Please replace Misc/BeOS-NOTES. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:51 Message: Logged In: YES user_id=6380 Thanks, Donn! Checked in. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411834&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:08:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:08:40 -0700 Subject: [Patches] [ python-Patches-411213 ] Platform support: RISC OS, round 2 Message-ID: Patches item #411213, was updated on 2001-03-25 13:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411213&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Dietmar Schwertberger (dschwertberger) >Assigned to: Guido van Rossum (gvanrossum) Summary: Platform support: RISC OS, round 2 Initial Comment: This patch should complete support for the RISC OS platform. Python should now compile out of the box on RISC OS. Readme.txt from the attached archive: ################################################################# Patches: Patches.txt contains following patches: (all changes are in #ifdef/#ifndef RISCOS clauses) timemodule.c: add support for a RISC OS implementation of sleep (to be found in new file RISCOS/sleep.c) main.c: replace 'getopt' by '_PyOS_GetOpt' sysmodule.c: bugfix: drop directory separator from end of sys.path[0] for RISC OS Lib/plat-riscos/riscospath.py: catch swi.swierror for empty file/pathnames ################################################################# Replacement file: RISCOS/Makefile: changes for 2.1b2; minimized whitespace to keep command line below 2048 character limit ################################################################# New files: RISCOS/sleep.c: Implement sleeping for RISC OS: int sleep(double delay) RISCOS/support/*: Support files for a complete Python under RISC OS Thanks. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:08 Message: Logged In: YES user_id=6380 Thanks, checked in. Please check the CVS to make sure that I did everything right! ---------------------------------------------------------------------- Comment By: Dietmar Schwertberger (dschwertberger) Date: 2001-03-29 13:42 Message: Logged In: YES user_id=86612 Please ignore the first archive. Riscos2.zip contains improved handling for RISC OS specific command line option. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411213&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:09:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:09:40 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was updated on 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:11:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:11:13 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was updated on 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:11:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:11:34 -0700 Subject: [Patches] [ python-Patches-403978 ] config.h -> pyac_config.h change for OS2 Message-ID: Patches item #403978, was updated on 2001-02-23 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: config.h -> pyac_config.h change for OS2 Initial Comment: Companion to SF patch #103977, the OS2 part. To keep the size down, I didn't include pyac_config.h. If you want to test this patch, you'll have to rename config.h to pyac_config.h manually. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:01 Message: Logged In: YES user_id=34209 Postponed, it's too late to get it into 2.1 (I actually intended to mark it postponed from the start, but forgot to.) The companion patch is now numbered '#403977', by the way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:13:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:13:23 -0700 Subject: [Patches] [ python-Patches-406287 ] last try: INSTALL_SCRIPT Message-ID: Patches item #406287, was updated on 2001-03-06 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406287&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Neil Schemenauer (nascheme) Summary: last try: INSTALL_SCRIPT Initial Comment: see diff ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:13 Message: Logged In: YES user_id=6380 Assigned to Neil for review. Note: the originator (Thomas Gellekum) included the following text in his patch: """ The following patch changes calls of $INSTALL_PROGRAM to $INSTALL_SCRIPT. On some systems, $INSTALL_PROGRAM might be defined in the environment with the `-s' option to install(1). This fails when the installed file is not a binary. $INSTALL_SCRIPT is used in this case. For other systems, this patch shouldn't change anything, because $INSTALL_SCRIPT is defined as $INSTALL_PROGRAM in configure. """ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406287&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:14:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:14:00 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-10 15:14 Message: Logged In: YES user_id=6656 OK, deleted the old one. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 Trying again -- the assign didn't work. NB please give a less ambiguous comment to file uploads -- the SF interface doesn't make it clear which file was uploaded last. Can you delete the old one? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:59 Message: Logged In: YES user_id=6380 Assigned to Jeremy and raised priority -- this needs to go into 2.1!!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-08 13:59 Message: Logged In: YES user_id=6656 this fixes another test case and tries harder to work out the names of the function/method/whatever. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:14:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:14:23 -0700 Subject: [Patches] [ python-Patches-411055 ] Delete unimportable extensions Message-ID: Patches item #411055, was updated on 2001-03-24 08:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411055&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: A.M. Kuchling (akuchling) Summary: Delete unimportable extensions Initial Comment: If building an extension module succeeds, the module may still be unimportable, e.g. because not all symbols can be resolved. This patch arranges to import every module after it has been built, and removes those for which importing fails. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411055&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:15:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:15:18 -0700 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 1 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:15:30 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:15:30 -0700 Subject: [Patches] [ python-Patches-403978 ] config.h -> pyac_config.h change for OS2 Message-ID: Patches item #403978, was updated on 2001-02-23 13:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 Category: Build Group: None Status: Open >Priority: 1 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) >Summary: config.h -> pyac_config.h change for OS2 Initial Comment: Companion to SF patch #103977, the OS2 part. To keep the size down, I didn't include pyac_config.h. If you want to test this patch, you'll have to rename config.h to pyac_config.h manually. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:01 Message: Logged In: YES user_id=34209 Postponed, it's too late to get it into 2.1 (I actually intended to mark it postponed from the start, but forgot to.) The companion patch is now numbered '#403977', by the way. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403978&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:15:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:15:43 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6656 No I didn't: File Delete: ArtifactFile: Permission Denied anyway, the "tries harder" is the more recent one; it's a bit more intrusive than the "fix & test cases." one, but is probably the better solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-10 15:14 Message: Logged In: YES user_id=6656 OK, deleted the old one. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 Trying again -- the assign didn't work. NB please give a less ambiguous comment to file uploads -- the SF interface doesn't make it clear which file was uploaded last. Can you delete the old one? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:59 Message: Logged In: YES user_id=6380 Assigned to Jeremy and raised priority -- this needs to go into 2.1!!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-08 13:59 Message: Logged In: YES user_id=6656 this fixes another test case and tries harder to work out the names of the function/method/whatever. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:16:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:16:55 -0700 Subject: [Patches] [ python-Patches-410046 ] asynchat: handle excessive response size Message-ID: Patches item #410046, was updated on 2001-03-20 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Doug Fort (dougfort) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat: handle excessive response size Initial Comment: When reading with a numeric terminator, asynchat assumes that if the server didn't send fewer bytes than requested, that it sent exactly the number of bytes requested. This is normally the case, but an overloaded server can return an error message that is larger than the number of bytes requested. When this happens asynchttp.handle_read() goes into a tight loop, returning an empty string for data and zero for a terminator. This patch raises an exception if the number of bytes returned exceeds the number requested. It's kind of an ugly fix, because asynchttp doesn't raise any other exceptions, and passes on those it catches to handle_error. However, this really is an exceptional case, and the results of not handling it are disastrous. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:16 Message: Logged In: YES user_id=6380 Doug, I'm hesitant to apply this right before releasing 2.1 -- I have no way to test this code. Can you ask for a review by Sam Rushing, asynchat.py's author? ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-25 06:22 Message: Logged In: YES user_id=6399 I have discovered that there are real cases where the server sends back more bytes than requested: specifically in Trannsfer-mode: chunked. Here is a revised, much simpler patch that passes on the data. *** asynchat.py.original Tue Mar 20 10:43:01 2001 --- asynchat.py Sun Mar 25 09:13:56 2001 *************** *** 106,113 **** self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: --- 106,113 ---- self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() else: ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-20 08:36 Message: Logged In: YES user_id=6399 *** asynchat.pyTue Mar 20 11:11:58 2001 --- asynchat.py.originalTue Mar 20 10:43:01 2001 *************** *** 49,60 **** import socket import asyncore - class async_chat_exception(Exception): - def __init__(self, message): - self._message = message - def __str__(self): - return self._message - class async_chat (asyncore.dispatcher): """This is an abstract class. You must derive from this class, and add the two methods collect_incoming_data() and found_terminator()""" --- 49,54 ---- *************** *** 111,128 **** self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! elif lb == n: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() - else: - # if we got back more than we asked for, the server - # is badly confused - raise async_chat_exception( - "Unexpect response: requested %s bytes got %s. %s" % ( - n, lb, self.ac_in_buffer - )) else: # 3 cases: # 1) end of buffer matches terminator exactly: --- 105,115 ---- self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! else: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: # 3 cases: # 1) end of buffer matches terminator exactly: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 From noreply@sourceforge.net Tue Apr 10 23:27:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 15:27:37 -0700 Subject: [Patches] [ python-Patches-405931 ] Patches for SCO UnixWare 7.1.x port Message-ID: Patches item #405931, was updated on 2001-03-04 20:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Patches for SCO UnixWare 7.1.x port Initial Comment: The attached file contains patches and files needed to allow Python-2.1 to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1 executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b1-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: dfb9ec40ab4b88b70abad9f1966fa3e0 Billy G. Allie ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:27 Message: Logged In: YES user_id=6380 Closing, given that this is superseded by a different patch. (Normal procedure would be to upload a new file, but alla. :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-02 00:02 Message: Logged In: YES user_id=8500 This patch is superceeded by one for beta 2. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-01 23:49 Message: Logged In: YES user_id=8500 This patch is superceeded by one for beta 2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405931&group_id=5470 From noreply@sourceforge.net Wed Apr 11 00:04:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 16:04:31 -0700 Subject: [Patches] [ python-Patches-406287 ] last try: INSTALL_SCRIPT Message-ID: Patches item #406287, was updated on 2001-03-06 05:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406287&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Neil Schemenauer (nascheme) Summary: last try: INSTALL_SCRIPT Initial Comment: see diff ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-04-10 16:04 Message: Logged In: YES user_id=35752 Checked in (version 1.33 of Makefile.pre.in). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:13 Message: Logged In: YES user_id=6380 Assigned to Neil for review. Note: the originator (Thomas Gellekum) included the following text in his patch: """ The following patch changes calls of $INSTALL_PROGRAM to $INSTALL_SCRIPT. On some systems, $INSTALL_PROGRAM might be defined in the environment with the `-s' option to install(1). This fails when the installed file is not a binary. $INSTALL_SCRIPT is used in this case. For other systems, this patch shouldn't change anything, because $INSTALL_SCRIPT is defined as $INSTALL_PROGRAM in configure. """ ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=406287&group_id=5470 From noreply@sourceforge.net Wed Apr 11 01:35:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 17:35:19 -0700 Subject: [Patches] [ python-Patches-415111 ] SocketServer doesn't close connection Message-ID: Patches item #415111, was updated on 2001-04-10 04:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 Category: library Group: None Status: Open Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer doesn't close connection Initial Comment: SocketServer.StreamRequestHandler The setup() method here duplicates the socket twice (once to make a read-only file, once to make a write-only file). That yields three descriptors, but finish() closes only two. This causes my browser to hang indefinitely waiting for the socket to close when SimpleHTTPServer is used to deliver a small page. This patch adds self.connection.close() to setup() so that there are just two descriptors to worry about. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2001-04-10 17:35 Message: Logged In: YES user_id=45338 Here's an updated patch that implements Guido's suggestion to add a close_request method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 We're working through this on python-dev. It's not so simple. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 From noreply@sourceforge.net Wed Apr 11 03:25:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 19:25:56 -0700 Subject: [Patches] [ python-Patches-415111 ] SocketServer doesn't close connection Message-ID: Patches item #415111, was updated on 2001-04-10 04:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 Category: library Group: None Status: Open Priority: 6 Submitted By: Ka-Ping Yee (ping) >Assigned to: Ka-Ping Yee (ping) Summary: SocketServer doesn't close connection Initial Comment: SocketServer.StreamRequestHandler The setup() method here duplicates the socket twice (once to make a read-only file, once to make a write-only file). That yields three descriptors, but finish() closes only two. This causes my browser to hang indefinitely waiting for the socket to close when SimpleHTTPServer is used to deliver a small page. This patch adds self.connection.close() to setup() so that there are just two descriptors to worry about. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 19:25 Message: Logged In: YES user_id=6380 OK, this looks good. Ping, please check it in yourself! ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-04-10 17:35 Message: Logged In: YES user_id=45338 Here's an updated patch that implements Guido's suggestion to add a close_request method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 We're working through this on python-dev. It's not so simple. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 From noreply@sourceforge.net Wed Apr 11 06:13:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 22:13:00 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was updated on 2001-04-04 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Barry Warsaw (bwarsaw) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- >Comment By: Barry Warsaw (bwarsaw) Date: 2001-04-10 22:13 Message: Logged In: YES user_id=12800 I will definitely look at this -- and soon -- but obviously not in time for the 2.1 release. Geoffrey, have you looked at mimelib (see url below)? My intent is to replace all the MIME handling stuff in the standard library with mimelib. I'm using mimelib extensively in Mailman, but I would love to get some additional outside feedback about it. E.g. how do you think your new multifile.py would fit in with mimelib, and how well do you think mimelib conforms to RFC 2046? http://barry.wooz.org/software/pyware.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:31 Message: Logged In: YES user_id=6380 Thanks. I'll assign this to Barry, who has been working on another replacement for multifile, so maybe he can review your contribution. Barry, please don't sit on this too long -- If you've no interest, please unassign it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-04 11:09 Message: Logged In: YES user_id=45814 PS. FWIW, This was developed and tested under python 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Wed Apr 11 07:26:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 10 Apr 2001 23:26:02 -0700 Subject: [Patches] [ python-Patches-415331 ] add setacl/getacl to imaplib Message-ID: Patches item #415331, was updated on 2001-04-10 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: add setacl/getacl to imaplib Initial Comment: Cyrus IMAP stores support the SETACL and GETACL commands. This patch add support for these to imaplib.py ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 From noreply@sourceforge.net Wed Apr 11 08:26:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 00:26:35 -0700 Subject: [Patches] [ python-Patches-414948 ] Check dynload_next.c (see description) Message-ID: Patches item #414948, was updated on 2001-04-09 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 Category: library >Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Jonathan Wight (schwa) Assigned to: Moshe Zadka (moshez) Summary: Check dynload_next.c (see description) Initial Comment: Fixes dynload_next.c to check to see library isn't already loaded. Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); So in effect Python isn't being returned into a 'good' state. NOTE: This is a follow-up to Patch #413005. In that Patch my browser failed to upload & attach the patch file. Apologies. ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-11 00:26 Message: Logged In: YES user_id=11645 This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix (the author neglected to set the group up, sadly, and I didn't have SF time before today to set this up). I'll check in some more patches to 201 this weekend, I think. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:25 Message: Logged In: YES user_id=6380 Assigned to Moshe since he assigned the other (failed) submission to himself also (Moshe, do you have the resources to test this before 2.1 goes out? If not, please unassign!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 From noreply@sourceforge.net Wed Apr 11 08:35:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 00:35:16 -0700 Subject: [Patches] [ python-Patches-413005 ] Fixes dynload_next.c to check to see library isn't already l Message-ID: Patches item #413005, was updated on 2001-04-01 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 Category: library Group: 2.0.1 bugfix >Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Moshe Zadka (moshez) >Summary: Fixes dynload_next.c to check to see library isn't already l Initial Comment: Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-11 00:35 Message: Logged In: YES user_id=11645 Considering this a duplicate of 414948, since it was reuploaded, and I don't need to see it in my page... ---------------------------------------------------------------------- Comment By: Jonathan Wight (schwa) Date: 2001-04-09 09:56 Message: Logged In: YES user_id=29309 Apologies for not successfully uploading the patch file the first time around. I've submitted a new Patch (#414948) with a patch file (successfully uploaded this time). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-02 13:55 Message: Logged In: NO I added the patch file to this record but can't see it in when I preview the info. If the patch wasn't entered with this record please email me at JWight@bigfoot.com and I'll issue another patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413005&group_id=5470 From noreply@sourceforge.net Wed Apr 11 08:36:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 00:36:37 -0700 Subject: [Patches] [ python-Patches-414326 ] SSL fix for OpenSSL-0.9.6+ Message-ID: Patches item #414326, was updated on 2001-04-06 08:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix >Status: Closed Priority: 5 Submitted By: Brian E. Gallew (geekatcmu) Assigned to: Moshe Zadka (moshez) Summary: SSL fix for OpenSSL-0.9.6+ Initial Comment: With OpenSSL-0.9.6+, the PRNG must be properly seeded before attempting any SSL operations. This patch, courtesy of Greg Wilson , will call RAND_load_file with the value of the RANDFILE environment variable. ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-11 00:36 Message: Logged In: YES user_id=11645 I am sorry, but both me and AMK agree that this throws something too big into the Python 2.0.1 release... Please use 2.1, which fixed this bug in a similar way. Sorry :( ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-04-09 07:15 Message: Logged In: YES user_id=11375 Hard to say. The SSL support is unusable on some platforms without this (David Beazley claimed it was fatal on Solaris, where there's no /dev/random to fall back to), but on the other hand the patch does add code that does something significantly new. I'd call it "feature", too. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-09 06:55 Message: Logged In: YES user_id=11645 Andrew, I want a second opinion: is this considered a feature or a bugfix? I'm leaning in the "feature" direction, and 2.1 will have this anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414326&group_id=5470 From noreply@sourceforge.net Wed Apr 11 13:40:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 05:40:53 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was updated on 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Wed Apr 11 13:43:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 05:43:23 -0700 Subject: [Patches] [ python-Patches-403977 ] Rename config.h to pyac_config.h, per SF bug #131774 Message-ID: Patches item #403977, was updated on 2001-02-23 13:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 Category: Build Group: None Status: Open Priority: 1 Submitted By: Thomas Wouters (twouters) Assigned to: Nobody/Anonymous (nobody) Summary: Rename config.h to pyac_config.h, per SF bug #131774 Initial Comment: This patch fixes the UNIX and Windows builds to use 'pyac_config.h' instead of 'config.h', to avoid the problems summarized in SF bug #131774. It doesn't address the placing issue, however, because I believe it's intended to be like this. Most changes were done using a fairly intelligent shell+sed oneliner, but they should be correct. The Windows build *seems* correct, though I can't be sure. Someone will have to check ;) It is probably a good idea to remove 'config.h' before testing, to be sure I got all references. The UNIX build requires that autoconf is installed, and requires a 'autoheader ; autoconf' is done before running 'configure'. Removing config.h(.in) is also a good idea. I excluded the OS2 build files, and will be uploading those as a seperate patch to avoid making this one unreadable Though only two files are involved, they both list all dependencies for *all* files in its entirety, so the patch is quite large. If those files are auto-generated, someone please tell me so :-) I also didn't fix distutils, though it looks like it does need fixing. And I didn't do anything wrt. backwards compatibility. We should probably provide a config.h that just does #warning Warning: Use of Python-specific config.h is deprecated. Use pyac_config.h instead. #include The name is just my suggestion, changing it into something less acronymic would be no problem at all. I think 'pythonconfig.h' gives the wrong message though: the file isn't used to configure Python itself, after all ;) ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:43 Message: Logged In: YES user_id=34209 I'm not sure about the supersedence here. See my comment in #411138. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6380 Is this superseded by patch #411138? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-18 16:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1 is released. Status set to postponed and priority lowered. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-01 17:29 Message: Logged In: YES user_id=31435 Na, I don't mind the pyac name. I had forgotten (or perhaps never knew) that this thing is a generated file (on Windows it's done by hand). It's an internal implementation detail anyway, so it doesn't matter if the name "makes sense" to Windows geeks; at least pyac_config will make some sense to Linux dweebs. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2001-03-01 17:08 Message: Logged In: YES user_id=34892 Tim said: > BTW, I have no idea what "pyac" is supposed to bring > to mind. Is that some Unixism? In answer to that. How about just calling it "pyconfig.h". The reference to autoconf is not very accurate for Windows. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-28 01:07 Message: Logged In: YES user_id=34209 I forgot to mention that I think this should be postponed until 2.2 or 2.1.1 anyway. It's not that big a change, but it's big enough to have weird and unsuspected sideffects. The bug is now numbered #231774, by the way. The problem is that 'config.h' is an oft-used name, and if you include it but have another directory with another project's config.h earlier in your include path, you get the wrong one. Similar if you intend to use the other one, but get this one. Leaving a fake config.h would only cause this patch to fix half of those problems, but only the first problem was reported in the bugreport :) The 'pyac_config' name comes from 'python', 'autoconf', 'config', and is IMHO sufficiently vague that it implies it is autogenerated :-) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-02-27 23:14 Message: Logged In: YES user_id=31392 No time ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2001-02-27 13:53 Message: Logged In: YES user_id=35752 SF seems to have changed the bug ids! I can't find bug #131774. Unless there is a very good reason for the change I'm against it for 2.1. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-02-27 13:05 Message: Logged In: YES user_id=11375 Regarding Distutils: I think the only actual *code* that would change is in distutils/sysconfig.py, in the get_config_h_filename() method. For backward compat., this method would probably have to check the Python version and use pyac_config.h if the version is 2.1 or greater. There are also lots of references to config.h in comments; we can change those or not, as desired. (I probably *would* change most of them.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-27 12:48 Message: Logged In: YES user_id=31435 Pushed onto Jeremy. Jeremy, we want to do this much fiddling so late in the cycle? Thomas, don't worry about Windows. I only need a warning about that, and I've aware of this now (thanks!). Check in the new MS project files or don't, it's easy for me to fix 'em up regardless (indeed, it's not worth extra time to check it in advance). Note that "#warning" is not std C. I'm afraid you'll have to make it an #error. OTOH, if you leave a file *named* "config.h" in the distribution, it doesn't really address the bug report, right? BTW, I have no idea what "pyac" is supposed to bring to mind. Is that some Unixism? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-02-23 13:32 Message: Apologies for the large blurb in the 'details' section. I keep forgetting SF strips *all* whitespace from that block :( Assigning to Tim "The Windows Bot" Peters to test (and fix) the Windows build changes. Let me know if your patch still doesn't work and you want me to send you patched files instead, Tim. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403977&group_id=5470 From noreply@sourceforge.net Wed Apr 11 15:06:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 07:06:38 -0700 Subject: [Patches] [ python-Patches-414750 ] fix for bug #414743 Message-ID: Patches item #414750, was updated on 2001-04-08 13:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Jeremy Hylton (jhylton) Summary: fix for bug #414743 Initial Comment: the code that reports errors for when a *-arg isn't a tuple assumes that the function being called is a PyFunctionObject, and blows up when it's a PyCFunctionObject (or, in fact, an object of any other type). Also adds some test cases. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-10 15:15 Message: Logged In: YES user_id=6656 No I didn't: File Delete: ArtifactFile: Permission Denied anyway, the "tries harder" is the more recent one; it's a bit more intrusive than the "fix & test cases." one, but is probably the better solution. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-10 15:14 Message: Logged In: YES user_id=6656 OK, deleted the old one. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 Trying again -- the assign didn't work. NB please give a less ambiguous comment to file uploads -- the SF interface doesn't make it clear which file was uploaded last. Can you delete the old one? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 12:59 Message: Logged In: YES user_id=6380 Assigned to Jeremy and raised priority -- this needs to go into 2.1!!! ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-08 13:59 Message: Logged In: YES user_id=6656 this fixes another test case and tries harder to work out the names of the function/method/whatever. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414750&group_id=5470 From noreply@sourceforge.net Wed Apr 11 16:21:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 08:21:10 -0700 Subject: [Patches] [ python-Patches-414391 ] Inplace optimization for binary ops Message-ID: Patches item #414391, was updated on 2001-04-06 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace optimization for binary ops Initial Comment: The idea behind this patch: >>> x = range(100) + [1,2,3] + range(90) creates *five* list objects before binding the fifth list object to x. Four of the five objects are discarded. Or: >>> x = range(100) + [2] creates three list objects and discards two. How can we make this more efficient? The implementation overview: When the Python VM POP()s two objects from the stack when doing a BINARY_* opcode, the frame owns one reference to each object. If the left operand object (second one popped) has a reference count of 1, then the object is only reachable by the VM in this frame. Since the VM will DECREF() the object after completing the binary operation and thus discard it, why not do the in-place version of the binary operation? This makes the above example more efficient (by making only three list objects and two list objects, respectively). Any questions, mail me or post to python-list, where the patch and other discussion is present. The patch posted to python-list is against 2.1b1 release. On Mon Apr 09, I will create a cvs diff against current tree and upload here on Sourceforge. ---------------------------------------------------------------------- >Comment By: Robin Thomas (robin900) Date: 2001-04-11 08:21 Message: Logged In: YES user_id=127529 Yes, I'll upload; I never wanted to to go hunting for the patch! :) Some colleagues and I have gathered performance stats on the patch. List concat/repeat is 15-25% faster, but ops on built-in numerics are 1-2% slower. Using Python "make test" to measure the distribution of ops/types, it's almost a wash: ops on built-in numerics are about 10 times more common than list concat/repeat. However, we don't want this patch to be list-specific; the original need was for a general hook so that extension types and user-defined classes could take advantage of the in-place optimization without doing fancy dancing in their own code. Thus, the patch will include a README with our performance and survey findings, and we'll leave the issue open for debate. Expect a patch upload today or tomorrow. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:29 Message: Logged In: YES user_id=6380 Sorry, I don't have the resources to search c.l.py. Can you please upload your patch here? The file uploads should work fine if you check the checkbox above the Browse button. This won't go into 2.1, obviously, so a patch against 2.1 when it is released (expected 4/16/01) would work too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 From noreply@sourceforge.net Wed Apr 11 16:30:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 08:30:41 -0700 Subject: [Patches] [ python-Patches-413766 ] Reimplementation of multifile.py Message-ID: Patches item #413766, was updated on 2001-04-04 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Barry Warsaw (bwarsaw) Summary: Reimplementation of multifile.py Initial Comment: This is a re-implementation of the stock multifile.py The main changes: 1. Efficiency: This version supports calling the read() method with an argument. (In many cases, I've found that reading a MultiFile line by line is just too slow --- remember multipart messages often contain large binary attachments.) This version performs reads on the underlying input stream in larger chunks as well, and uses a regular expression search to search for separator lines. 2. Buglets fixed The original version has a buglet regarding its handling of the newline which preceeds a separator line. According to RFC 2046, section 5.1.1 the newline preceeding a separator is part of the separator, not part of the preceeding content. The old version of multifile.py treats the newline as part of the content. Thus, it introduces a spurious empty line at the end of each content. Matching of the separators: RFC 2046, section 5.1.1 also states, that if the beginning of a line matches the separator, it is a separator. The old code ignores only trailing white space when looking for a separator line. This code ignores trailing anything on the separator line. ---------------------------------------------------------------------- >Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-11 08:30 Message: Logged In: YES user_id=45814 Oof. I wish I had found your mimelib a couple of weeks ago. :-) You'll notice I've also posted a patch to Mailman (SF#413752) which adds an option to filter MIME attachments to plain text (delete binary attachments, convert HTML to plain text, ...) To do that (without defining new interfaces) I subclassed MimeWriter --- it's a bit messy. Using mimelib probably would have/will be cleaner. The Mailman patch includes a text/{richtext,enriched} parser (same interface as HTMLParser) which you guys might be interested in. I'm about to head off for a (long) weekend of skiing, so I won't have a chance to look carefully at mimelib until next week. Do expect to hear from me then, though. -Jeff ---------------------------------------------------------------------- Comment By: Barry Warsaw (bwarsaw) Date: 2001-04-10 22:13 Message: Logged In: YES user_id=12800 I will definitely look at this -- and soon -- but obviously not in time for the 2.1 release. Geoffrey, have you looked at mimelib (see url below)? My intent is to replace all the MIME handling stuff in the standard library with mimelib. I'm using mimelib extensively in Mailman, but I would love to get some additional outside feedback about it. E.g. how do you think your new multifile.py would fit in with mimelib, and how well do you think mimelib conforms to RFC 2046? http://barry.wooz.org/software/pyware.html ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:31 Message: Logged In: YES user_id=6380 Thanks. I'll assign this to Barry, who has been working on another replacement for multifile, so maybe he can review your contribution. Barry, please don't sit on this too long -- If you've no interest, please unassign it. ---------------------------------------------------------------------- Comment By: Geoffrey T. Dairiki (dairiki) Date: 2001-04-04 11:09 Message: Logged In: YES user_id=45814 PS. FWIW, This was developed and tested under python 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413766&group_id=5470 From noreply@sourceforge.net Wed Apr 11 17:01:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 09:01:01 -0700 Subject: [Patches] [ python-Patches-411138 ] Fix for #231774: pyconfig.h Message-ID: Patches item #411138, was updated on 2001-03-25 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #231774: pyconfig.h Initial Comment: This patch renames config.h to pyconfig.h, to allow autoconfiscation of python-based projects. In addition to the changes collected in this patch, the following actions are required when committing it: - re-run autoheader and autoconf - cvs add pyconfig.h (generated by autoheader), cvs remove config.h - rename PC/config.h, PC/os2vacpp/config.h, and RISCOS/config.h in CVS (probably using cvs add/remove) - globally replace config.h in PC/os2vacpp/makefile and PC/os2vacpp/makefile.omk; this change has been omitted from the patch because it is quite large. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-11 09:01 Message: Logged In: YES user_id=21627 I have created this patch because I was not aware of the other one; the bug #231774 log did not indicate that a patch was in progress. As for the specific differences between them: I like pyconfig.h better than pyac_config.h. The file object chunk was there by mistake; I have removed it. I don't think that the distutils as shipped with Python need to check for config.h, since the Python release having this version of distutils will use only pyconfig.h. For independent distutils releases, looking for config.h might be necessary. I also don't think that the documentation should mention config.h; Python documentation was always accurate only for the release in which it was included. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-04-11 05:40 Message: Logged In: YES user_id=34209 I may be biased, but I don't see the difference between this patch and my patch, except that there are some errors in this patch :) It includes a change in fileobject.h that isn't supposed to be there (I think), and it changes distutils in the wrong way (distutils, for backward compatibility, should check for both config.h and pyconfig.h) -- though my patch doesn't address the latter issue, it doesn't touch distutils at all. Documentation should also mention both config.h and pyconfig.h. Other than that, I don't care which patch gets accepted, by the way :) But maybe Martin can explain why he created this patch ? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:11 Message: Logged In: YES user_id=6380 PS. Does this supersede patch #403978? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:09 Message: Logged In: YES user_id=6380 Let's do this after 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=411138&group_id=5470 From noreply@sourceforge.net Wed Apr 11 18:40:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 10:40:42 -0700 Subject: [Patches] [ python-Patches-414948 ] Check dynload_next.c (see description) Message-ID: Patches item #414948, was updated on 2001-04-09 09:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 Category: library Group: 2.0.1 bugfix Status: Open Priority: 5 Submitted By: Jonathan Wight (schwa) Assigned to: Moshe Zadka (moshez) Summary: Check dynload_next.c (see description) Initial Comment: Fixes dynload_next.c to check to see library isn't already loaded. Fixes the NeXT dynloader (used on MacOS X 10.0) to check to see if a symbol has already been loaded before trying to load it again. Without this change running the following pseudocode more than once will cause the NeXT dyld loader to terminate the app. Py_Initialize(); PyRun_SimpleString("import string"); Py_Finalize(); So in effect Python isn't being returned into a 'good' state. NOTE: This is a follow-up to Patch #413005. In that Patch my browser failed to upload & attach the patch file. Apologies. ---------------------------------------------------------------------- >Comment By: Jonathan Wight (schwa) Date: 2001-04-11 10:40 Message: Logged In: YES user_id=29309 > This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix I countered this bug in version 2.1b2a -- I then did a cvs checkout to get the latest version of the (buggy) code. Unless I'm missing something a fix isn't in 2.1 > (the author neglected to set the group up There wasn't an option for 2.1b2a in the group popup. Just "2.0.1" and "None" ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-11 00:26 Message: Logged In: YES user_id=11645 This is irrelevant for 2.1 -- it is a Py2.0.1 bugfix (the author neglected to set the group up, sadly, and I didn't have SF time before today to set this up). I'll check in some more patches to 201 this weekend, I think. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:25 Message: Logged In: YES user_id=6380 Assigned to Moshe since he assigned the other (failed) submission to himself also (Moshe, do you have the resources to test this before 2.1 goes out? If not, please unassign!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414948&group_id=5470 From noreply@sourceforge.net Wed Apr 11 21:08:29 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 13:08:29 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Wed Apr 11 21:13:41 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 13:13:41 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Wed Apr 11 22:00:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 14:00:38 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None >Status: Closed Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Wed Apr 11 22:19:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 14:19:26 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Thu Apr 12 02:00:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 11 Apr 2001 18:00:03 -0700 Subject: [Patches] [ python-Patches-414391 ] Inplace optimization for binary ops Message-ID: Patches item #414391, was updated on 2001-04-06 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace optimization for binary ops Initial Comment: The idea behind this patch: >>> x = range(100) + [1,2,3] + range(90) creates *five* list objects before binding the fifth list object to x. Four of the five objects are discarded. Or: >>> x = range(100) + [2] creates three list objects and discards two. How can we make this more efficient? The implementation overview: When the Python VM POP()s two objects from the stack when doing a BINARY_* opcode, the frame owns one reference to each object. If the left operand object (second one popped) has a reference count of 1, then the object is only reachable by the VM in this frame. Since the VM will DECREF() the object after completing the binary operation and thus discard it, why not do the in-place version of the binary operation? This makes the above example more efficient (by making only three list objects and two list objects, respectively). Any questions, mail me or post to python-list, where the patch and other discussion is present. The patch posted to python-list is against 2.1b1 release. On Mon Apr 09, I will create a cvs diff against current tree and upload here on Sourceforge. ---------------------------------------------------------------------- >Comment By: Robin Thomas (robin900) Date: 2001-04-11 18:00 Message: Logged In: YES user_id=127529 The performance stats are bad: a loss (on my Solaris Sparc) of ~180 pystones/sec. Sigh. I'm posting the patch anyway, so that if others find it useful and wish to revive, it will be here. ---------------------------------------------------------------------- Comment By: Robin Thomas (robin900) Date: 2001-04-11 08:21 Message: Logged In: YES user_id=127529 Yes, I'll upload; I never wanted to to go hunting for the patch! :) Some colleagues and I have gathered performance stats on the patch. List concat/repeat is 15-25% faster, but ops on built-in numerics are 1-2% slower. Using Python "make test" to measure the distribution of ops/types, it's almost a wash: ops on built-in numerics are about 10 times more common than list concat/repeat. However, we don't want this patch to be list-specific; the original need was for a general hook so that extension types and user-defined classes could take advantage of the in-place optimization without doing fancy dancing in their own code. Thus, the patch will include a README with our performance and survey findings, and we'll leave the issue open for debate. Expect a patch upload today or tomorrow. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:29 Message: Logged In: YES user_id=6380 Sorry, I don't have the resources to search c.l.py. Can you please upload your patch here? The file uploads should work fine if you check the checkbox above the Browse button. This won't go into 2.1, obviously, so a patch against 2.1 when it is released (expected 4/16/01) would work too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 From noreply@sourceforge.net Thu Apr 12 10:29:58 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Apr 2001 02:29:58 -0700 Subject: [Patches] [ python-Patches-415629 ] setup.py: readline req. ncurses (SuSE) Message-ID: Patches item #415629, was updated on 2001-04-12 02:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415629&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: setup.py: readline req. ncurses (SuSE) Initial Comment: Python 2.1b2 on SuSE Linux 7.0: The readline extension module must be linked with libncurses, else 'import readline' fails because of unresolved symbols. (libtermcap is only installed for libc5 compatibility in SuSE 7.0) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415629&group_id=5470 From noreply@sourceforge.net Thu Apr 12 22:36:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Apr 2001 14:36:10 -0700 Subject: [Patches] [ python-Patches-415777 ] Patch for 414940:new grouping strategy Message-ID: Patches item #415777, was updated on 2001-04-12 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415777&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for 414940:new grouping strategy Initial Comment: This patch fixes bug #414940, and redoes the fix for #129417 in a different way. Unfortunately, it is hard to write test cases for these algorithms, since they'd rely on the presence of a specific locale (e.g. en_US). The patch has been tested manually to fix both bugs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415777&group_id=5470 From noreply@sourceforge.net Thu Apr 12 22:55:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 12 Apr 2001 14:55:11 -0700 Subject: [Patches] [ python-Patches-415777 ] Patch for 414940:new grouping strategy Message-ID: Patches item #415777, was updated on 2001-04-12 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415777&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: Patch for 414940:new grouping strategy Initial Comment: This patch fixes bug #414940, and redoes the fix for #129417 in a different way. Unfortunately, it is hard to write test cases for these algorithms, since they'd rely on the presence of a specific locale (e.g. en_US). The patch has been tested manually to fix both bugs. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-12 14:55 Message: Logged In: YES user_id=6380 Are you sure you want to use string.digits and not "0123456789" ? I don't think that string.digits is locale-specific or anything -- so what's the point? In any case, if you can check in this plus a test case, that would be great! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415777&group_id=5470 From noreply@sourceforge.net Fri Apr 13 09:15:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 01:15:32 -0700 Subject: [Patches] [ python-Patches-415777 ] Patch for 414940:new grouping strategy Message-ID: Patches item #415777, was updated on 2001-04-12 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415777&group_id=5470 Category: library Group: None >Status: Closed Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Nobody/Anonymous (nobody) Summary: Patch for 414940:new grouping strategy Initial Comment: This patch fixes bug #414940, and redoes the fix for #129417 in a different way. Unfortunately, it is hard to write test cases for these algorithms, since they'd rely on the presence of a specific locale (e.g. en_US). The patch has been tested manually to fix both bugs. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 01:15 Message: Logged In: YES user_id=21627 I've committed a modified version of the patch as 1.17 of locale.py, as well as 1.1 of test_locale.py and output/test_locale. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-12 14:55 Message: Logged In: YES user_id=6380 Are you sure you want to use string.digits and not "0123456789" ? I don't think that string.digits is locale-specific or anything -- so what's the point? In any case, if you can check in this plus a test case, that would be great! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415777&group_id=5470 From noreply@sourceforge.net Fri Apr 13 14:04:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 06:04:43 -0700 Subject: [Patches] [ python-Patches-415111 ] SocketServer doesn't close connection Message-ID: Patches item #415111, was updated on 2001-04-10 04:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 Category: library Group: None >Status: Closed Priority: 6 Submitted By: Ka-Ping Yee (ping) Assigned to: Ka-Ping Yee (ping) Summary: SocketServer doesn't close connection Initial Comment: SocketServer.StreamRequestHandler The setup() method here duplicates the socket twice (once to make a read-only file, once to make a write-only file). That yields three descriptors, but finish() closes only two. This causes my browser to hang indefinitely waiting for the socket to close when SimpleHTTPServer is used to deliver a small page. This patch adds self.connection.close() to setup() so that there are just two descriptors to worry about. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 19:25 Message: Logged In: YES user_id=6380 OK, this looks good. Ping, please check it in yourself! ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2001-04-10 17:35 Message: Logged In: YES user_id=45338 Here's an updated patch that implements Guido's suggestion to add a close_request method. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:16 Message: Logged In: YES user_id=6380 We're working through this on python-dev. It's not so simple. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415111&group_id=5470 From noreply@sourceforge.net Fri Apr 13 14:11:57 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 06:11:57 -0700 Subject: [Patches] [ python-Patches-415879 ] Exception.__init__() causes segfault Message-ID: Patches item #415879, was updated on 2001-04-13 06:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415879&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 7 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: Exception.__init__() causes segfault Initial Comment: Calling an unbound method on a C extension class without providing an instance can yield a segfault. Try "Exception.__init__()" or "ValueError.__init__()". This is a simple fix. The error-reporting bits in call_method mistakenly treat the misleadingly-named variable "func" as a function, when in fact it is a method. If we let get_func_name take care of the work, all is fine. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415879&group_id=5470 From noreply@sourceforge.net Fri Apr 13 15:57:55 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 07:57:55 -0700 Subject: [Patches] [ python-Patches-405845 ] Fix for #405427: raise BadStatusLine Message-ID: Patches item #405845, was updated on 2001-03-04 08:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405845&group_id=5470 Category: Modules Group: None >Status: Closed Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Jeremy Hylton (jhylton) Summary: Fix for #405427: raise BadStatusLine Initial Comment: If the status code is not well-formatted, this patch raises a BadStatusLine exception ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-03-04 08:59 Message: Logged In: YES user_id=21627 Since patch upload still does not work, I attach it inline Index: httplib.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/httplib.py,v retrieving revision 1.33 diff -u -r1.33 httplib.py --- httplib.py 2001/02/01 23:35:20 1.33 +++ httplib.py 2001/03/04 16:52:34 @@ -126,7 +126,15 @@ self.close() raise BadStatusLine(line) - self.status = status = int(status) + # The status code is a three-digit number + if len(status) != 3: + raise BadStatusLine(line) + try: + self.status = status = int(status) + if status < 100: + raise BadStatusLine(line) + except ValueError: + raise BadStatusLine(line) self.reason = reason.strip() if version == 'HTTP/1.0': --- /dev/null Fri Dec 22 00:32:13 2000 +++ test/test_httplib.py Sun Mar 4 17:53:00 2001 @@ -0,0 +1,31 @@ +from test.test_support import verify,verbose +import httplib +import StringIO + +class FakeSocket: + def __init__(self, text): + self.text = text + + def makefile(self, mode, bufsize=None): + if mode != 'r' and mode != 'rb': + raise UnimplementedFileMode() + return StringIO.StringIO(self.text) + +# Test HTTP status lines + +body = "HTTP/1.1 200 Ok\r\n\r\nText" +sock = FakeSocket(body) +resp = httplib.HTTPResponse(sock,1) +resp.begin() +print resp.read() +resp.close() + +body = "HTTP/1.1 400.100 Not Ok\r\n\r\nText" +sock = FakeSocket(body) +resp = httplib.HTTPResponse(sock,1) +try: + resp.begin() +except httplib.BadStatusLine: + print "PASS" +else: + print "FAIL" ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405845&group_id=5470 From noreply@sourceforge.net Fri Apr 13 16:43:00 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 08:43:00 -0700 Subject: [Patches] [ python-Patches-415879 ] Exception.__init__() causes segfault Message-ID: Patches item #415879, was updated on 2001-04-13 06:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415879&group_id=5470 Category: core (C code) Group: None >Status: Closed Priority: 7 Submitted By: Ka-Ping Yee (ping) >Assigned to: Guido van Rossum (gvanrossum) Summary: Exception.__init__() causes segfault Initial Comment: Calling an unbound method on a C extension class without providing an instance can yield a segfault. Try "Exception.__init__()" or "ValueError.__init__()". This is a simple fix. The error-reporting bits in call_method mistakenly treat the misleadingly-named variable "func" as a function, when in fact it is a method. If we let get_func_name take care of the work, all is fine. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 08:43 Message: Logged In: YES user_id=6380 Thanks! Checked in for Ping, who's taking some rest. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415879&group_id=5470 From noreply@sourceforge.net Fri Apr 13 16:45:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 08:45:08 -0700 Subject: [Patches] [ python-Patches-415331 ] add setacl/getacl to imaplib Message-ID: Patches item #415331, was updated on 2001-04-10 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: add setacl/getacl to imaplib Initial Comment: Cyrus IMAP stores support the SETACL and GETACL commands. This patch add support for these to imaplib.py ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 08:45 Message: Logged In: YES user_id=6380 I've forwarded this to Piers Lauder, imaplib's author. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 From noreply@sourceforge.net Fri Apr 13 17:34:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 09:34:40 -0700 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open Priority: 7 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-13 09:34 Message: Logged In: YES user_id=6656 I'm sure everyone's more than sufficiently busy ATM, but I really think the patches in next-api.diff (to the docs) and next-test.diff (to _testcapimodule.c) should go into 2.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 07:49 Message: Logged In: YES user_id=6380 Assigned to Fred for docs. I believe the doc changes are in the uploaded files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 00:28 Message: Logged In: YES user_id=6656 What about the doc changes and the test cases? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=6380 This is closed now as far as I'm concerned. The policy decision is that during a PyDict_Next() walk, you may only call PyDict_SetItem() to replace the value for an existing key. Thanks Michael and Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Fri Apr 13 18:09:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 10:09:11 -0700 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None Status: Open >Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 10:09 Message: Logged In: YES user_id=6380 I've applied next-test.diff (with some changes in the error handling to avoid masking more serious errors). Fred, if you have time please do the doc update and close the issue. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-13 09:34 Message: Logged In: YES user_id=6656 I'm sure everyone's more than sufficiently busy ATM, but I really think the patches in next-api.diff (to the docs) and next-test.diff (to _testcapimodule.c) should go into 2.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 07:49 Message: Logged In: YES user_id=6380 Assigned to Fred for docs. I believe the doc changes are in the uploaded files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 00:28 Message: Logged In: YES user_id=6656 What about the doc changes and the test cases? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=6380 This is closed now as far as I'm concerned. The policy decision is that during a PyDict_Next() walk, you may only call PyDict_SetItem() to replace the value for an existing key. Thanks Michael and Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Fri Apr 13 18:55:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 10:55:42 -0700 Subject: [Patches] [ python-Patches-409864 ] lazy fix for Pings bizarre scoping crash Message-ID: Patches item #409864, was updated on 2001-03-19 15:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 Category: Parser/Compiler Group: None >Status: Closed Priority: 6 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: lazy fix for Pings bizarre scoping crash Initial Comment: This is a minimal effort fix for Ping's report of a crash on python-dev. I don't know the new compile.c well enough to really judge the best fix. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-13 10:55 Message: Logged In: YES user_id=3066 Documentation checked in as Doc/api/api.tex revision 1.117; closing this item on SF. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 10:09 Message: Logged In: YES user_id=6380 I've applied next-test.diff (with some changes in the error handling to avoid masking more serious errors). Fred, if you have time please do the doc update and close the issue. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-04-13 09:34 Message: Logged In: YES user_id=6656 I'm sure everyone's more than sufficiently busy ATM, but I really think the patches in next-api.diff (to the docs) and next-test.diff (to _testcapimodule.c) should go into 2.1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 07:49 Message: Logged In: YES user_id=6380 Assigned to Fred for docs. I believe the doc changes are in the uploaded files. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-22 00:28 Message: Logged In: YES user_id=6656 What about the doc changes and the test cases? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-21 16:06 Message: Logged In: YES user_id=6380 This is closed now as far as I'm concerned. The policy decision is that during a PyDict_Next() walk, you may only call PyDict_SetItem() to replace the value for an existing key. Thanks Michael and Tim! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-03-21 11:29 Message: Logged In: YES user_id=31435 After talking with Guido, I checked in a variant of next- dict.diff; but didn't touch the rest of this. dictobject.c rev 2.74. PyDict_Next is now safe to use in loops that merely modify the values associated with existing dict keys via Py_SetItem (). Other kinds of mutation are still blow-up-at-your-own- risk. Note to Jeremy: it is NOT enough merely that the number of keys remain the same. No existing key can be deleted, nor any new key inserted, during the loop. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-03-21 08:50 Message: Logged In: YES user_id=31392 This is a policy question I'm not comfortable answering. Should we allow dict modification during a PyDict_Next() iteration if the number of keys remains the same? I can make the compiler work with or without this change. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:35 Message: Logged In: YES user_id=6656 last one for now; this patch adds a test to Modules/_testcapimodule.c to ensure that assigning to the keys you're iterating over works as advertised in the patch to the documentation. i've checked that it finds this case (i.e. the test fails before my patch and passes after). the _testcapi tests aren't actually run anywhere, are they? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:11 Message: Logged In: YES user_id=6656 add ping's test case to Lib/test/test_scope.py (I'll stop this soon). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:07 Message: Logged In: YES user_id=6656 and documents that you can assign to the keys as you iterate over them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-21 08:05 Message: Logged In: YES user_id=6656 this alternative approach patches PyDict_Next to check for resize. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2001-03-19 15:12 Message: Logged In: YES user_id=6656 remember the file! ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=409864&group_id=5470 From noreply@sourceforge.net Fri Apr 13 22:09:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 14:09:27 -0700 Subject: [Patches] [ python-Patches-416022 ] Improved debug output for 'telnetlib' Message-ID: Patches item #416022, was updated on 2001-04-13 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416022&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) Summary: Improved debug output for 'telnetlib' Initial Comment: In file telnetlib.py, there is the following line : opt = self.rawq_getchar() self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c)) The problem is that it prints 'c' twice (once as DO or DONT, the other as its numerical value). For debugging, it's 'opt' that is needed to be printed (it's the option that corresponds to DO or DONT). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416022&group_id=5470 From noreply@sourceforge.net Fri Apr 13 22:09:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 14:09:27 -0700 Subject: [Patches] [ python-Patches-416023 ] Improved debug output for 'telnetlib' Message-ID: Patches item #416023, was updated on 2001-04-13 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416023&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) Summary: Improved debug output for 'telnetlib' Initial Comment: In file telnetlib.py, there is the following line : opt = self.rawq_getchar() self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c)) The problem is that it prints 'c' twice (once as DO or DONT, the other as its numerical value). For debugging, it's 'opt' that is needed to be printed (it's the option that corresponds to DO or DONT). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416023&group_id=5470 From noreply@sourceforge.net Fri Apr 13 22:11:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 14:11:12 -0700 Subject: [Patches] [ python-Patches-416023 ] Improved debug output for 'telnetlib' Message-ID: Patches item #416023, was updated on 2001-04-13 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416023&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) Summary: Improved debug output for 'telnetlib' Initial Comment: In file telnetlib.py, there is the following line : opt = self.rawq_getchar() self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c)) The problem is that it prints 'c' twice (once as DO or DONT, the other as its numerical value). For debugging, it's 'opt' that is needed to be printed (it's the option that corresponds to DO or DONT). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416023&group_id=5470 From noreply@sourceforge.net Fri Apr 13 22:15:38 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 14:15:38 -0700 Subject: [Patches] [ python-Patches-416023 ] Improved debug output for 'telnetlib' Message-ID: Patches item #416023, was updated on 2001-04-13 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416023&group_id=5470 Category: library Group: None >Status: Deleted Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) Summary: Improved debug output for 'telnetlib' Initial Comment: In file telnetlib.py, there is the following line : opt = self.rawq_getchar() self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c)) The problem is that it prints 'c' twice (once as DO or DONT, the other as its numerical value). For debugging, it's 'opt' that is needed to be printed (it's the option that corresponds to DO or DONT). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416023&group_id=5470 From noreply@sourceforge.net Fri Apr 13 23:04:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 13 Apr 2001 15:04:19 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Closed Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Sat Apr 14 08:44:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 00:44:53 -0700 Subject: [Patches] [ python-Patches-416022 ] Improvements in telnetlib Message-ID: Patches item #416022, was updated on 2001-04-13 14:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416022&group_id=5470 Category: library Group: None >Status: Deleted Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) >Summary: Improvements in telnetlib Initial Comment: In file telnetlib.py, there is the following line : opt = self.rawq_getchar() self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c)) The problem is that it prints 'c' twice (once as DO or DONT, the other as its numerical value). For debugging, it's 'opt' that is needed to be printed (it's the option that corresponds to DO or DONT). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416022&group_id=5470 From noreply@sourceforge.net Sat Apr 14 08:54:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 00:54:35 -0700 Subject: [Patches] [ python-Patches-416079 ] Improvements in 'telnetlib' Message-ID: Patches item #416079, was updated on 2001-04-14 00:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416079&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Lionel Ulmer (bbrox) Assigned to: Nobody/Anonymous (nobody) Summary: Improvements in 'telnetlib' Initial Comment: This patch does the following : - fix the debug string output when receiving telnet commands (the 'c' was reprinted whereas it's 'opt' that we want to see on the screen) - added all the telnet options known to arpa/telnet.h - added the possibility for the user to have it's own option negotiation callback, thus overriding Python's default WILL/WONT => DONT, DO/DONT => WONT behaviour Now, on a design perspective, I did not know what was best : do as I did or add a __default_callback function in the telnetlib file that would do the default behavious and thus preventing the 'if callback:' tests. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416079&group_id=5470 From noreply@sourceforge.net Sun Apr 15 03:25:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 19:25:11 -0700 Subject: [Patches] [ python-Patches-416220 ] pstats.py interactive read function fix Message-ID: Patches item #416220, was updated on 2001-04-14 19:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416220&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: pstats.py interactive read function fix Initial Comment: In pstats.py new interactive mode, read with no arguments dies because of a misplaced paren. Simple one liner fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416220&group_id=5470 From noreply@sourceforge.net Sun Apr 15 04:52:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 20:52:13 -0700 Subject: [Patches] [ python-Patches-416224 ] add readline completion to cmd.Cmd Message-ID: Patches item #416224, was updated on 2001-04-14 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline completion to cmd.Cmd Initial Comment: Adds command completion to Cmd class. Can be disabled by calling __init__ with completekey=None or can use a different key, it defaults to 'tab'. Not sure if this is really the best way to enable/disable it, but it works. (oh, prolly requires doc updates too) Would also be nifty to provide command-specific completion with something like complete_(...) funcs, but this is not possible with python's current readline interface. (doh) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 From noreply@sourceforge.net Sun Apr 15 05:27:01 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 21:27:01 -0700 Subject: [Patches] [ python-Patches-416224 ] add readline completion to cmd.Cmd Message-ID: Patches item #416224, was updated on 2001-04-14 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline completion to cmd.Cmd Initial Comment: Adds command completion to Cmd class. Can be disabled by calling __init__ with completekey=None or can use a different key, it defaults to 'tab'. Not sure if this is really the best way to enable/disable it, but it works. (oh, prolly requires doc updates too) Would also be nifty to provide command-specific completion with something like complete_(...) funcs, but this is not possible with python's current readline interface. (doh) ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2001-04-14 21:27 Message: Logged In: YES user_id=65253 Hm, actually I just looked into the readline module a bit deeper and it looks like it is possible after, all I was going only on what was passed to the complete func but with the get_line_buffer and friends it should be possible.. so, I'll see if I can work up a patch that includes command specific completion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 From noreply@sourceforge.net Sun Apr 15 05:29:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 21:29:07 -0700 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: Moshe Zadka (moshez) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-14 21:29 Message: Logged In: YES user_id=6380 Who defines USE_EGD??? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-18 00:45 Message: Logged In: YES user_id=11645 Checked in ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #416224, was updated on 2001-04-14 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline completion to cmd.Cmd Initial Comment: Adds command completion to Cmd class. Can be disabled by calling __init__ with completekey=None or can use a different key, it defaults to 'tab'. Not sure if this is really the best way to enable/disable it, but it works. (oh, prolly requires doc updates too) Would also be nifty to provide command-specific completion with something like complete_(...) funcs, but this is not possible with python's current readline interface. (doh) ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:06 Message: Logged In: YES user_id=65253 Ok, heres a new patch that implements command specific completion as well. It is diffed against a clean cmd.py, not the previous patch. I also have a patch against pstats.py to make its interactive mode take advantage of this, should I submit it in a seperate report? ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 21:27 Message: Logged In: YES user_id=65253 Hm, actually I just looked into the readline module a bit deeper and it looks like it is possible after, all I was going only on what was passed to the complete func but with the get_line_buffer and friends it should be possible.. so, I'll see if I can work up a patch that includes command specific completion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 From noreply@sourceforge.net Sun Apr 15 07:08:33 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 14 Apr 2001 23:08:33 -0700 Subject: [Patches] [ python-Patches-416224 ] add readline completion to cmd.Cmd Message-ID: Patches item #416224, was updated on 2001-04-14 20:52 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: add readline completion to cmd.Cmd Initial Comment: Adds command completion to Cmd class. Can be disabled by calling __init__ with completekey=None or can use a different key, it defaults to 'tab'. Not sure if this is really the best way to enable/disable it, but it works. (oh, prolly requires doc updates too) Would also be nifty to provide command-specific completion with something like complete_(...) funcs, but this is not possible with python's current readline interface. (doh) ---------------------------------------------------------------------- >Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:08 Message: Logged In: YES user_id=65253 Oh, also note that if you try to test it with pstats you have to at the very least make its __init__ call Cmd.__init__, since it doesn't do that currently.. ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 23:06 Message: Logged In: YES user_id=65253 Ok, heres a new patch that implements command specific completion as well. It is diffed against a clean cmd.py, not the previous patch. I also have a patch against pstats.py to make its interactive mode take advantage of this, should I submit it in a seperate report? ---------------------------------------------------------------------- Comment By: Matthew Mueller (donut) Date: 2001-04-14 21:27 Message: Logged In: YES user_id=65253 Hm, actually I just looked into the readline module a bit deeper and it looks like it is possible after, all I was going only on what was passed to the complete func but with the get_line_buffer and friends it should be possible.. so, I'll see if I can work up a patch that includes command specific completion. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416224&group_id=5470 From mail@k-biz.com Sun Apr 15 05:44:13 2001 From: mail@k-biz.com (mail@k-biz.com) Date: Sun, 15 Apr 2001 04:44:13 Subject: [Patches] Distribution / Wholesale -- findmybusiness.com Free for limited time! Message-ID: Find you customer, Place your ad for FREE! Try http://www.findmybusiness.com -------------------------------------------------------------------------------- Distribution, Wholesale opportunities. Businesses for sale, Investment Properties, Franchises, Homebased businesses, Find you business today. Visit our website http://www.findmybusiness.com -------------------------------------------------------------------------------- Trust in the Lord with all your heart... Happy Easter! From noreply@sourceforge.net Sun Apr 15 12:18:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:18:16 -0700 Subject: [Patches] [ python-Patches-416247 ] 2.1c1 stringobject: unused vrbl cleanup Message-ID: Patches item #416247, was updated on 2001-04-15 04:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416247&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1 stringobject: unused vrbl cleanup Initial Comment: Variable set but unused: *** stringobject.c.orig Sun Apr 15 17:51:21 2001 --- stringobject.c Sun Apr 15 18:10:26 2001 *************** *** 2758,2764 **** int flags = 0; int width = -1; int prec = -1; - int size = 0; int c = '\0'; int fill; PyObject *v = NULL; --- 2758,2763 ---- *************** *** 2895,2901 **** } /* prec */ if (fmtcnt >= 0) { if (c == 'h' || c == 'l' || c == 'L') { - size = c; if (--fmtcnt >= 0) c = *fmt++; } --- 2894,2899 ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416247&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:19:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:19:50 -0700 Subject: [Patches] [ python-Patches-416248 ] 2.1c1 unicodeobject: unused vrbl cleanup Message-ID: Patches item #416248, was updated on 2001-04-15 04:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416248&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1 unicodeobject: unused vrbl cleanup Initial Comment: Variable set but unused: *** unicodeobject.c.orig Sun Apr 15 18:10:43 2001 --- unicodeobject.c Sun Apr 15 18:11:57 2001 *************** *** 4793,4799 **** int flags = 0; int width = -1; int prec = -1; - int size = 0; Py_UNICODE c = '\0'; Py_UNICODE fill; PyObject *v = NULL; --- 4793,4798 ---- *************** *** 4931,4937 **** } /* prec */ if (fmtcnt >= 0) { if (c == 'h' || c == 'l' || c == 'L') { - size = c; if (--fmtcnt >= 0) c = *fmt++; } --- 4930,4935 ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416248&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:22:53 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:22:53 -0700 Subject: [Patches] [ python-Patches-416249 ] 2.1c1 compile: unused vrbl cleanup Message-ID: Patches item #416249, was updated on 2001-04-15 04:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416249&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1 compile: unused vrbl cleanup Initial Comment: Variable set but unused *** compile.c.orig Sun Apr 15 18:15:26 2001 --- compile.c Sun Apr 15 18:17:08 2001 *************** *** 3551,3563 **** for (i = 0, narg = 0; i < nch; i++) { node *ch = CHILD(n, i); node *fp; - char *name; if (TYPE(ch) == STAR || TYPE(ch) == DOUBLESTAR) break; REQ(ch, fpdef); /* fpdef: NAME | '(' fplist ')' */ fp = CHILD(ch, 0); if (TYPE(fp) != NAME) { - name = nbuf; sprintf(nbuf, ".%d", i); complex = 1; } --- 3551,3561 ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416249&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:25:16 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:25:16 -0700 Subject: [Patches] [ python-Patches-416250 ] 2.1c1 thread_pthread: unused vrbl clean Message-ID: Patches item #416250, was updated on 2001-04-15 04:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1 thread_pthread: unused vrbl clean Initial Comment: Variables set but not used *** thread_pthread.h.orig Sun Apr 15 18:30:22 2001 --- thread_pthread.h Sun Apr 15 18:32:02 2001 *************** *** 273,279 **** PyThread_free_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status, error = 0; dprintf(("PyThread_free_lock(%p) called\n", lock)); --- 273,279 ---- PyThread_free_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status; dprintf(("PyThread_free_lock(%p) called\n", lock)); *************** *** 328,334 **** PyThread_release_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status, error = 0; dprintf(("PyThread_release_lock(%p) called\n", lock)); --- 328,334 ---- PyThread_release_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status; dprintf(("PyThread_release_lock(%p) called\n", lock)); *************** *** 386,392 **** void PyThread_free_sema(PyThread_type_sema sema) { ! int status, error = 0; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_free_sema(%p) called\n", sema)); --- 386,392 ---- void PyThread_free_sema(PyThread_type_sema sema) { ! int status; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_free_sema(%p) called\n", sema)); *************** *** 430,436 **** void PyThread_up_sema(PyThread_type_sema sema) { ! int status, error = 0; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_up_sema(%p)\n", sema)); --- 430,436 ---- void PyThread_up_sema(PyThread_type_sema sema) { ! int status; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_up_sema(%p)\n", sema)); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:26:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:26:47 -0700 Subject: [Patches] [ python-Patches-416251 ] 2.1c1 mmapmodule: unused vrbl cleanup Message-ID: Patches item #416251, was updated on 2001-04-15 04:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1 mmapmodule: unused vrbl cleanup Initial Comment: Variable set but unused *** mmapmodule.c.orig Sun Apr 15 18:37:16 2001 --- mmapmodule.c Sun Apr 15 18:38:43 2001 *************** *** 163,169 **** mmap_read_byte_method(mmap_object *self, PyObject *args) { - char value; char *where; CHECK_VALID(NULL); if (!PyArg_ParseTuple(args, ":read_byte")) --- 163,168 ---- *************** *** 170,176 **** return NULL; if (self->pos < self->size) { where = self->data + self->pos; - value = (char) *(where); self->pos += 1; return Py_BuildValue("c", (char) *(where)); } else { --- 169,174 ---- ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416251&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:36:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:36:40 -0700 Subject: [Patches] [ python-Patches-416250 ] 2.1c1 thread_pthread: unused vrbl clean Message-ID: Patches item #416250, was updated on 2001-04-15 04:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1 thread_pthread: unused vrbl clean Initial Comment: Variables set but not used *** thread_pthread.h.orig Sun Apr 15 18:30:22 2001 --- thread_pthread.h Sun Apr 15 18:32:02 2001 *************** *** 273,279 **** PyThread_free_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status, error = 0; dprintf(("PyThread_free_lock(%p) called\n", lock)); --- 273,279 ---- PyThread_free_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status; dprintf(("PyThread_free_lock(%p) called\n", lock)); *************** *** 328,334 **** PyThread_release_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status, error = 0; dprintf(("PyThread_release_lock(%p) called\n", lock)); --- 328,334 ---- PyThread_release_lock(PyThread_type_lock lock) { pthread_lock *thelock = (pthread_lock *)lock; ! int status; dprintf(("PyThread_release_lock(%p) called\n", lock)); *************** *** 386,392 **** void PyThread_free_sema(PyThread_type_sema sema) { ! int status, error = 0; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_free_sema(%p) called\n", sema)); --- 386,392 ---- void PyThread_free_sema(PyThread_type_sema sema) { ! int status; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_free_sema(%p) called\n", sema)); *************** *** 430,436 **** void PyThread_up_sema(PyThread_type_sema sema) { ! int status, error = 0; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_up_sema(%p)\n", sema)); --- 430,436 ---- void PyThread_up_sema(PyThread_type_sema sema) { ! int status; struct semaphore *thesema = (struct semaphore *) sema; dprintf(("PyThread_up_sema(%p)\n", sema)); ---------------------------------------------------------------------- >Comment By: Mark Favas (mfavas) Date: 2001-04-15 04:36 Message: Logged In: YES user_id=44979 Aaaaaaaaargh! Ignore this one - sorry! I rebuilt after changing this, but thread.c (which depends on this include file) was not rebuilt automatically (makefile dependency needs fixing, I guess). Errors ensued when I recompiled thread.c - error is set in the macro CHECK_STATUS and sometimes used and sometimes not - would require making two macros, so not worth doing. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416250&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:37:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:37:05 -0700 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: Moshe Zadka (moshez) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: Moshe Zadka (moshez) Date: 2001-04-15 04:37 Message: Logged In: YES user_id=11645 Whoever builds, in Modules/Setup After many discussions, I have not found any way to autodetect a running EGD so setup.py can enable it. I should probably have documented it somewhere....sorry. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-14 21:29 Message: Logged In: YES user_id=6380 Who defines USE_EGD??? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-18 00:45 Message: Logged In: YES user_id=11645 Checked in ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #416253, was updated on 2001-04-15 04:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416253&group_id=5470 Category: library Group: None Status: Open Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: additions to imaplib Initial Comment: This patch adds some new methods: GET/SETACL (submitted by Anthony Baxter); SORT (IMAP4rev1 extension); and some overridable methods to complete the ability to override all I/O. There are also some code cleanups (I've changed the evals into getattrs). The documentation changes for the new methods are submitted as a separate patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416253&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:58:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:58:24 -0700 Subject: [Patches] [ python-Patches-416254 ] documentation for new imaplib methods Message-ID: Patches item #416254, was updated on 2001-04-15 04:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416254&group_id=5470 Category: documentation Group: None Status: Open Priority: 5 Submitted By: Piers Lauder (pierslauder) Assigned to: Nobody/Anonymous (nobody) Summary: documentation for new imaplib methods Initial Comment: This patch is against the current copy of dist/src/Doc/lib/libimaplib.tex and documents the new methods contained in my earlier imaplib patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416254&group_id=5470 From noreply@sourceforge.net Sun Apr 15 12:58:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 04:58:44 -0700 Subject: [Patches] [ python-Patches-415331 ] add setacl/getacl to imaplib Message-ID: Patches item #415331, was updated on 2001-04-10 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 Category: None Group: None Status: Open Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: add setacl/getacl to imaplib Initial Comment: Cyrus IMAP stores support the SETACL and GETACL commands. This patch add support for these to imaplib.py ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2001-04-15 04:58 Message: Logged In: YES user_id=196212 I've incorporated this patch into my imaplib patch, submitted a few moments ago. (I've also documented it :-) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-13 08:45 Message: Logged In: YES user_id=6380 I've forwarded this to Piers Lauder, imaplib's author. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=415331&group_id=5470 From rusffr@yahoo.com Fri Apr 13 14:32:59 2001 From: rusffr@yahoo.com (Sergey) Date: Fri, 13 Apr 2001 16:32:59 +0300 Subject: [Patches] e-mail áàçû íà îäíîì ÑD äèñêå. Message-ID: <06d995128120f41SERVER@server> Çäðàâñòâóéòå! Âñå Email Ìîñêâû - 42.000 àäðåñîâ (ôèðìû + 19.500 áåç ðàçáèâêè). Îáñëóæèâàíèå_àãåíòñòâà_íîâîñòåé153 Îáñëóæèâàíèå_àóäèò173 Îáñëóæèâàíèå_ãîñòèíèöû69 Îáñëóæèâàíèå_èçäàòåëüñòâà662 Îáñëóæèâàíèå_êóëüòóðà360 Îáñëóæèâàíèå_ìåäèöèíà_ñïîðò365 Îáñëóæèâàíèå_íàóêà352 Îáñëóæèâàíèå_îáó÷åíèå513 Îáñëóæèâàíèå_îáùåïèò93 Îáñëóæèâàíèå_îõðàííûå298 Îáñëóæèâàíèå_ïðåññà819 Îáñëóæèâàíèå_ïðîãðàììèðîâàíèå579 Îáñëóæèâàíèå_ïðîèçâîäñòâî553 Îáñëóæèâàíèå_ðàçíîå418 Îáñëóæèâàíèå_ðåêëàìà1041 Îáñëóæèâàíèå_ðåìîíò404 Îáñëóæèâàíèå_ñâÿçü726 Îáñëóæèâàíèå_ñêëàäû41 Îáñëóæèâàíèå_ñòðîèòåëüñòâî359 Îáñëóæèâàíèå_òåëåðàäèî129 Îáñëóæèâàíèå_òðàíñïîðò605 Îáñëóæèâàíèå_òðóäîóñòðîéñòâî249 Îáñëóæèâàíèå_òóðèçì1377 Îáñëóæèâàíèå_þðèäè÷åñêèå438 Ïðî÷åå_áàíêè579 Ïðî÷èå_ãîññòðóêòóðû323 Ïðî÷èå_èíâåñòèöèîííûå225 Ïðî÷èå_èíîôèðìû240 Ïðî÷èå_êîíñàëòèíã235 Ïðî÷èå_îáùåñòâåííûå_îðãàíèçàöèè268 Ïðî÷èå_ïîñîëüñòâà45 Ïðî÷èå_ñòðàõîâûå126 Òîðãîâëÿ_àâòîìîáèëè_çàï÷àñòè1141 òîðãîâëÿ_àïòåêè16 Òîðãîâëÿ_áûòîâûå_òîâàðû511 Òîðãîâëÿ_äåòñêèå_òîâàðû195 Òîðãîâëÿ_ìåáåëü273 Òîðãîâëÿ_ìåäèöèíñêèå_òîâàðû405 Òîðãîâëÿ_íåäâèæèìîñòü829 Òîðãîâëÿ_îáîðóäîâàíèå1821 Òîðãîâëÿ_îáóâü33 Òîðãîâëÿ_îäåæäà159 Òîðãîâëÿ_îïòîâàÿ_îäåæäà42 Òîðãîâëÿ_îïòîâàÿ_ïðîäóêòû519 Òîðãîâëÿ_îïòîâàÿ_ïðîìòîâàðû104 Òîðãîâëÿ_îðãòåõíèêà1256 Òîðãîâëÿ_îõðàííîå169 Òîðãîâëÿ_ïàðôþìåðèÿ118 Òîðãîâëÿ_ïðîäóêòû164 Òîðãîâëÿ_ðàçíîå639 Òîðãîâëÿ_ñïîðòòîâàðû75 Òîðãîâëÿ_ñòðîéìàòåðèàëû805 Òîðãîâëÿ_ÒÍÏ217 Òîðãîâëÿ_õîçòîâàðû162 Òîðãîâëÿ_ýêñïîðò_èìïîðò45 E-mail áàçà "Âñÿ Ðîññèÿ" Áàçà ñîäåðæèò 340 òûñÿ÷ àäðåñîâ (èç íèõ îêîëî 30% - àäðåñà îðãàíèçàöèé). Âñå àäðåñà ïðåäâàðèòåëüíî ïðîâåðåíû ñ ïîìîùüþ ñïåöèàëüíîé ïðîãðàììû â ôåâðàëå 2001 ã. è ðåàëüíî ñóùåñòâóþò. Áàçà â âèäå 14 txt ôàéëà c ïåðå÷íåì å-ìàéëîâ. Ïðèìåð: thermax@glasnet.ru thermiks@online.ru thermo@iname.ru thermo@mail.ru thermo@rambler.ru thermo@rinet.ru thermofit@pop3.rcom.ru thermoforming@mtu-net.ru thermoluch@mtu-net.ru thermos@inbox.ru thermos@mail.ru thermotech@mtu-net.ru Ïðèëàãàåòñÿ ïðîãðàììà äëÿ ìàññîâîé ðàññûëêè + îïèñàíèå ïî ïîëüçîâàíèþ. Áàçà ïðåäíàçíà÷åíà äëÿ ìàññîâîé ðàññûëêè ðåêëàìû òîâàðîâ, ñàéòîâ, êîììåð÷åñêèõ ïðåäëîæåíèé è ò.ï. Ñïîñîá äîñòàâêè: ïî ýëåêòðîííîé ïî÷òå òðè ôàéëà îáùèì ðàçìåðîì 2,5 ìá. Îïëàòà: Áàíêîâñêèé ïåðåâîä (îðèãèíàëüíûé ñ÷åò è ñ÷åò ôàêòóðó âûøëåì ïî÷òîé), ïî Ìîñêâå íàëè÷íûìè êóðüåðó, webmoney. Öåíà: 1000 ðóáëåé. From noreply@sourceforge.net Sun Apr 15 13:34:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 05:34:32 -0700 Subject: [Patches] [ python-Patches-416248 ] 2.1c1 unicodeobject: unused vrbl cleanup Message-ID: Patches item #416248, was updated on 2001-04-15 04:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416248&group_id=5470 Category: core (C code) Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) >Assigned to: Tim Peters (tim_one) Summary: 2.1c1 unicodeobject: unused vrbl cleanup Initial Comment: Variable set but unused: *** unicodeobject.c.orig Sun Apr 15 18:10:43 2001 --- unicodeobject.c Sun Apr 15 18:11:57 2001 *************** *** 4793,4799 **** int flags = 0; int width = -1; int prec = -1; - int size = 0; Py_UNICODE c = '\0'; Py_UNICODE fill; PyObject *v = NULL; --- 4793,4798 ---- *************** *** 4931,4937 **** } /* prec */ if (fmtcnt >= 0) { if (c == 'h' || c == 'l' || c == 'L') { - size = c; if (--fmtcnt >= 0) c = *fmt++; } --- 4930,4935 ---- ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-15 05:34 Message: Logged In: YES user_id=38388 Assigned to Tim, since he tweak this code ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416248&group_id=5470 From noreply@sourceforge.net Sun Apr 15 13:36:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 05:36:12 -0700 Subject: [Patches] [ python-Patches-405101 ] Add Random Seeding to OpenSSL Message-ID: Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None Status: Closed Priority: 5 Submitted By: Moshe Zadka (moshez) Assigned to: Moshe Zadka (moshez) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-15 05:36 Message: Logged In: YES user_id=6380 But Modules/Setup is no longer used to build the socket module! It's now built by setup.py, which ignores Modules/Setup AFAICT. I'm very tempted to undo this patch, as it has too many problems (see the python-dev discussion: it needs work for pre-0.9.5 versions of openssl, and on some systems it always issues a warning whenever you import the socket module. That's bad, since few of those imports are intended to use the ssl support. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-15 04:37 Message: Logged In: YES user_id=11645 Whoever builds, in Modules/Setup After many discussions, I have not found any way to autodetect a running EGD so setup.py can enable it. I should probably have documented it somewhere....sorry. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-14 21:29 Message: Logged In: YES user_id=6380 Who defines USE_EGD??? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-18 00:45 Message: Logged In: YES user_id=11645 Checked in ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #405101, was updated on 2001-03-01 02:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=405101&group_id=5470 Category: Modules Group: None >Status: Open Priority: 5 Submitted By: Moshe Zadka (moshez) >Assigned to: Guido van Rossum (gvanrossum) Summary: Add Random Seeding to OpenSSL Initial Comment: On systems without /dev/urandom, OpenSSL does not work unless explicitly seeded. This patch gives an option to seed it either from EGD, or from the C rng ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-15 05:36 Message: Logged In: YES user_id=6380 Reopened and grabbed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-15 05:36 Message: Logged In: YES user_id=6380 But Modules/Setup is no longer used to build the socket module! It's now built by setup.py, which ignores Modules/Setup AFAICT. I'm very tempted to undo this patch, as it has too many problems (see the python-dev discussion: it needs work for pre-0.9.5 versions of openssl, and on some systems it always issues a warning whenever you import the socket module. That's bad, since few of those imports are intended to use the ssl support. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-04-15 04:37 Message: Logged In: YES user_id=11645 Whoever builds, in Modules/Setup After many discussions, I have not found any way to autodetect a running EGD so setup.py can enable it. I should probably have documented it somewhere....sorry. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-14 21:29 Message: Logged In: YES user_id=6380 Who defines USE_EGD??? ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-18 00:45 Message: Logged In: YES user_id=11645 Checked in ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2001-03-17 08:38 Message: Logged In: YES user_id=11375 Looks OK. Go ahead and check it in. ---------------------------------------------------------------------- Comment By: Moshe Zadka (moshez) Date: 2001-03-01 03:40 Message: Logged In: YES user_id=11645 New version of the patch: now warning when using the insecure srand/rand (version at http://www.lerner.co.il/~moshez/ssl_seed also updated) Index: Modules/socketmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.137 diff -c -r1.137 socketmodule.c *** Modules/socketmodule.c 2001/02/07 20:41:17 1.137 --- Modules/socketmodule.c 2001/03/01 11:37:12 *************** *** 176,181 **** --- 176,182 ---- #include "openssl/pem.h" #include "openssl/ssl.h" #include "openssl/err.h" + #include "openssl/rand.h" #endif /* USE_SSL */ #if defined(MS_WINDOWS) || defined(__BEOS__) *************** *** 2473,2478 **** --- 2474,2505 ---- if (PyDict_SetItemString(d, "SSLType", (PyObject *)&SSL_Type) != 0) return; + if (RAND_status() == 0) { + #ifdef USE_EGD + char random_device[MAXPATHLEN+1]; + if (!RAND_file_name (random_device, MAXPATHLEN + 1)) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_file_name error")); + return; + } + if (RAND_egd (random_device) == -1) { + PyErr_SetObject(SSLErrorObject, + PyString_FromString("RAND_egd error")); + return; + } + #else /* USE_EGD not defined */ + char random_string[32]; + int i; + + PyErr_Warn(PyExc_RuntimeWarning, + "using insecure method to generate random numbers"); + srand(time(NULL)); + for(i=0; i Patches item #416262, was updated on 2001-04-15 06:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416262&group_id=5470 Category: Build Group: None Status: Open Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1c1: make setup.py check zlib version Initial Comment: Currently, setup.py will build the zlib module without checking whether the version of zlib on the target system is up to date (or at least 1.1.3). The module will thus be built on a stock SGI system where the zlib version is 1.0.4. WHen the zlib test is run, a core dump results. The patch below checks the version of zlib, and only builds if >= 1.1.3 *** setup.py.orig Sun Apr 15 20:59:34 2001 --- setup.py Sun Apr 15 21:00:53 2001 *************** *** 449,457 **** # Andrew Kuchling's zlib module. # This require zlib 1.1.3 (or later). # See http://www.cdrom.com/pub/infozip/zlib/ ! if (self.compiler.find_library_file(lib_dirs, 'z')): ! exts.append( Extension('zlib', ['zlibmodule.c'], ! libraries = ['z']) ) # Interface to the Expat XML parser # --- 449,471 ---- # Andrew Kuchling's zlib module. # This require zlib 1.1.3 (or later). # See http://www.cdrom.com/pub/infozip/zlib/ ! zlib_inc = find_file('zlib.h', [], inc_dirs) ! if zlib_inc is not None: ! zlib_h = zlib_inc[0] + '/zlib.h' ! version = '"0.0.0"' ! version_req = '"1.1.3"' ! fp = open(zlib_h) ! while 1: ! line = fp.readline() ! if not line: ! break ! if line.find('#define ZLIB_VERSION', 0) == 0: ! version = line.split()[2] ! break ! if version >= version_req: ! if (self.compiler.find_library_file(lib_dirs, 'z')): ! exts.append( Extension('zlib', ['zlibmodule.c'], ! libraries = ['z']) ) # Interface to the Expat XML parser # ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416262&group_id=5470 From noreply@sourceforge.net Sun Apr 15 20:14:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 15 Apr 2001 12:14:24 -0700 Subject: [Patches] [ python-Patches-416298 ] Fix in typo in WeakValueDictionary Message-ID: Patches item #416298, was updated on 2001-04-15 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470 Category: Modules Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix in typo in WeakValueDictionary Initial Comment: There is a small error in weakref.WeakValueDictionary. This error was found in 2.1c1, a quick look in the april 15th build revealed it was not fixed. Demonstration: >>> class Spam: ... pass ... >>> dict = {'a':Spam()} >>> weakref.WeakValueDictionary(dict) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/python-2.1c1/lib/python2.1/UserDict.py", line 6, in __init__ if dict is not None: self.update(dict) File "/usr/local/python-2.1c1/lib/python2.1/weakref.py", line 103, in update L.append(key, ref(o, remove)) Examination of the script reveals that the fix is obvious: def update(self, dict): d = self.data L = [] for key, o in dict.items(): def remove(o, data=d, key=key): del data[key] # L.append(key, ref(o, remove)) # ^^^ erroneous ^^^^ L.append((key, ref(o, remove))) # ^^^ right ^^^ for key, r in L: d[key] = r ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470 From noreply@sourceforge.net Tue Apr 17 15:24:28 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Apr 2001 07:24:28 -0700 Subject: [Patches] [ python-Patches-416704 ] More robust freeze Message-ID: Patches item #416704, was updated on 2001-04-17 07:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Toby Dickenson (htrd) Assigned to: Nobody/Anonymous (nobody) Summary: More robust freeze Initial Comment: This patch addresses three issues, all relating to robustness of frozen programs. Specifically, this patch allows explicit and complete control over which modules may be loaded from source on the filesystem of the host system where the frozen program is run, and which may not. Without this patch it is impossible to create a non- trivial frozen program which will *never* load a module from source on the filesystem. 1. A patch to correct bug #404545 (frozen package import uses wrong files). Under this change, submodules of a frozen package must themselves be frozen modules. Previously, the import machinery may also try to import submodules from curiously named files (packagename.modulename.py) from directories in sys.path 2. A patch to add an extra command line option -E to freeze.py, which forces freeze to terminate with an error message if there are modules that it can not locate. If this switch is not specified then the default behaviour is unchanged: modules which can not be found by freeze will not be included in the frozen program, and the import machinery will try to load them from source on sys.path when the frozen program is run. In practice we have found that a missing module is probably an error (and it is a fairly frequent error too!). The -E switch can be used to detect this error; any missing modules will cause freeze.py to fail. In the rare case of a frozen module importing a non- frozen one (ie one which should be loaded from source when the program is run), the non-frozen module must be excluded from the freeze using the -x option. 3. A patch to add an extra command line option -X to freeze.py, which indicates that a specified module is excluded from the freeze, and also that the frozen program should not try to load the module from sys.path when it is imported. Importing the specified module will always trigger an ImportError. This is useful if a module used by a frozen program can optionally use a submodule... try: import optional_submodule except ImportError: pass It may be preferable for the frozen program's behaviour to not depend on whether optional_submodule happens to be installed on the host system, and that the 'import optional_submodule' should always fail with an ImportError. This can be achieved using the '- X optional_submodule' command line switch to freeze.py This is implemented by including the excluded module in the frozen imports table (_PyImport_FrozenModules), with the code pointer set to NULL. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416704&group_id=5470 From noreply@sourceforge.net Wed Apr 18 05:35:49 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Apr 2001 21:35:49 -0700 Subject: [Patches] [ python-Patches-416298 ] Fix in typo in WeakValueDictionary Message-ID: Patches item #416298, was updated on 2001-04-15 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix in typo in WeakValueDictionary Initial Comment: There is a small error in weakref.WeakValueDictionary. This error was found in 2.1c1, a quick look in the april 15th build revealed it was not fixed. Demonstration: >>> class Spam: ... pass ... >>> dict = {'a':Spam()} >>> weakref.WeakValueDictionary(dict) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/python-2.1c1/lib/python2.1/UserDict.py", line 6, in __init__ if dict is not None: self.update(dict) File "/usr/local/python-2.1c1/lib/python2.1/weakref.py", line 103, in update L.append(key, ref(o, remove)) Examination of the script reveals that the fix is obvious: def update(self, dict): d = self.data L = [] for key, o in dict.items(): def remove(o, data=d, key=key): del data[key] # L.append(key, ref(o, remove)) # ^^^ erroneous ^^^^ L.append((key, ref(o, remove))) # ^^^ right ^^^ for key, r in L: d[key] = r ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-17 21:35 Message: Logged In: NO Ok, I submitted it the day before the 2.1 was released. I has been fixed in the release. Nevermind. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470 From noreply@sourceforge.net Wed Apr 18 05:36:15 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Apr 2001 21:36:15 -0700 Subject: [Patches] [ python-Patches-416298 ] Fix in typo in WeakValueDictionary Message-ID: Patches item #416298, was updated on 2001-04-15 12:14 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Fix in typo in WeakValueDictionary Initial Comment: There is a small error in weakref.WeakValueDictionary. This error was found in 2.1c1, a quick look in the april 15th build revealed it was not fixed. Demonstration: >>> class Spam: ... pass ... >>> dict = {'a':Spam()} >>> weakref.WeakValueDictionary(dict) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/python-2.1c1/lib/python2.1/UserDict.py", line 6, in __init__ if dict is not None: self.update(dict) File "/usr/local/python-2.1c1/lib/python2.1/weakref.py", line 103, in update L.append(key, ref(o, remove)) Examination of the script reveals that the fix is obvious: def update(self, dict): d = self.data L = [] for key, o in dict.items(): def remove(o, data=d, key=key): del data[key] # L.append(key, ref(o, remove)) # ^^^ erroneous ^^^^ L.append((key, ref(o, remove))) # ^^^ right ^^^ for key, r in L: d[key] = r ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-17 21:36 Message: Logged In: NO Ok, I submitted it the day before the 2.1 was released. I has been fixed in the release. Nevermind. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-17 21:35 Message: Logged In: NO Ok, I submitted it the day before the 2.1 was released. I has been fixed in the release. Nevermind. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416298&group_id=5470 From noreply@sourceforge.net Wed Apr 18 06:37:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Apr 2001 22:37:32 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Wed Apr 18 07:04:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Apr 2001 23:04:31 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Wed Apr 18 09:54:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 01:54:35 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Wed Apr 18 09:55:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 01:55:39 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: M.-A. Lemburg (lemburg) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Wed Apr 18 13:51:03 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 05:51:03 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Nobody/Anonymous (nobody) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-18 05:51 Message: Logged In: YES user_id=21627 Committed as 2.83 of unicodeobject.c, with the requested addition of init/fini code. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Wed Apr 18 16:00:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 08:00:10 -0700 Subject: [Patches] [ python-Patches-413419 ] termios cleanup Message-ID: Patches item #413419, was updated on 2001-04-03 07:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 Category: Modules Group: None Status: Open Resolution: Postponed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: termios cleanup Initial Comment: If TERMIOS is deprecated, then perhaps it would be best if the docstrings in termios didn't refer to it! Also updates termios functions to be METH_VARARGS. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-18 08:00 Message: Logged In: YES user_id=6656 I am about to submit a patch that subsumes this one. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-04-09 12:35 Message: Logged In: YES user_id=3066 The docstring updates have been checked in as Modules/termios.c revision 2.23. The remaining changes will be considered after the 2.1 release -- since there is not a test suite for this module, we do not want to risk introducing bugs immediately before release. This will remain open & assigned to me for consideration after the release. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413419&group_id=5470 From noreply@sourceforge.net Wed Apr 18 16:30:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 08:30:26 -0700 Subject: [Patches] [ python-Patches-417081 ] termios modernization Message-ID: Patches item #417081, was updated on 2001-04-18 08:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Nobody/Anonymous (nobody) Summary: termios modernization Initial Comment: this patch does several things to termios: (1) changes all functions to be METH_VARARGS (2) changes all functions to be able to take a file object as the first parameter, as per http://mail.python.org/pipermail/python-dev/2001-February/012701.html (3) give better error messages (4) removes a bunch of comments that just repeat the docstrings (5) #includes before #including so more constants are actually #defined. (6) a couple of docstring tweaks I have tested this minimally (i.e. it builds, and doesn't blow up too embarassingly) on OSF1/alpha and on one of the sf compile farm's solaris boxes, and rather more comprehansively on my linux/x86 box. It still needs to be tested on all the other platforms we build termios on (which is why I didn't do this last week...) I still need to do the docs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470 From noreply@sourceforge.net Wed Apr 18 16:34:37 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 08:34:37 -0700 Subject: [Patches] [ python-Patches-417084 ] sre: Speed up Unicode charsets Message-ID: Patches item #417084, was updated on 2001-04-18 08:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417084&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: sre: Speed up Unicode charsets Initial Comment: When matching large Unicode charsets (e.g. the one that defines an XML name, from xml.utils.characters), matching is quite slow, since a linear search over the ranges is performed. The patch compiles a unicode character class into a BIGCHARSET opcode, using a compression technique similar to the one that the expat parser uses (see comment in sre_parse). With the patch, runtime for import time,re,xml.utils.characters u = u"Hallo welt" e = xml.utils.characters.re_Name t = time.time() for i in xrange(1000000): e.match(u) print time.time()-t could be reduced to 45%. Even when doing full parsing using CVS xmlproc, a 4% speedup can still be observed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417084&group_id=5470 From noreply@sourceforge.net Wed Apr 18 16:35:12 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 08:35:12 -0700 Subject: [Patches] [ python-Patches-417081 ] termios modernization Message-ID: Patches item #417081, was updated on 2001-04-18 08:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: termios modernization Initial Comment: this patch does several things to termios: (1) changes all functions to be METH_VARARGS (2) changes all functions to be able to take a file object as the first parameter, as per http://mail.python.org/pipermail/python-dev/2001-February/012701.html (3) give better error messages (4) removes a bunch of comments that just repeat the docstrings (5) #includes before #including so more constants are actually #defined. (6) a couple of docstring tweaks I have tested this minimally (i.e. it builds, and doesn't blow up too embarassingly) on OSF1/alpha and on one of the sf compile farm's solaris boxes, and rather more comprehansively on my linux/x86 box. It still needs to be tested on all the other platforms we build termios on (which is why I didn't do this last week...) I still need to do the docs. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2001-04-18 08:35 Message: Logged In: YES user_id=6656 And here's the docs (not much, as it turns out). Fred likes these, we hear. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417081&group_id=5470 From noreply@sourceforge.net Thu Apr 19 06:03:14 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 22:03:14 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-18 22:03 Message: Logged In: YES user_id=8500 loewis, First, a question. Are you using the SCO UDK compiler to compile Python? The UDK is the target compiler addressed by these patches (see the README file included with the patch). 1. This patch added support for using threads and to generate a shared Python library. 2. There is no reason to not explicitly specify the argument that are the defaults either. 3. I'll cede the point about using cc to link the shared modules, but the shared library does not need crti.o and crtn.o. They would be linked into the executable that references the shared library. 4. Perhaps, but my goal was to get UnixWare to compile with thread support and using shared libraries. I do not have access to those other systems, so I could not make chages to the way configure handles them (I wouldn't be able to test those changes). If others would like to make those changes, I would be willing to work with them to come up with a uniform way of teating the similar systems. 5. The UnixWare UDK requires the use of -Kthread to control the (correct) linking of the thread libraries. Using -lthread is specifically warned against. There is no -Kpthread option nor is there a libpthread library. The -Kthread option will load the POSIX thread routines if they are used. To reiterate, my goal was to be able to compile on UnixWare using shared libraries and including supprot for threads. I also wanted to do this in a manner that would not affect how other systems were handled. Again, I only have a UnisWare system on whick to build and test the changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Thu Apr 19 06:06:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Apr 2001 22:06:47 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None >Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-18 22:03 Message: Logged In: YES user_id=8500 loewis, First, a question. Are you using the SCO UDK compiler to compile Python? The UDK is the target compiler addressed by these patches (see the README file included with the patch). 1. This patch added support for using threads and to generate a shared Python library. 2. There is no reason to not explicitly specify the argument that are the defaults either. 3. I'll cede the point about using cc to link the shared modules, but the shared library does not need crti.o and crtn.o. They would be linked into the executable that references the shared library. 4. Perhaps, but my goal was to get UnixWare to compile with thread support and using shared libraries. I do not have access to those other systems, so I could not make chages to the way configure handles them (I wouldn't be able to test those changes). If others would like to make those changes, I would be willing to work with them to come up with a uniform way of teating the similar systems. 5. The UnixWare UDK requires the use of -Kthread to control the (correct) linking of the thread libraries. Using -lthread is specifically warned against. There is no -Kpthread option nor is there a libpthread library. The -Kthread option will load the POSIX thread routines if they are used. To reiterate, my goal was to be able to compile on UnixWare using shared libraries and including supprot for threads. I also wanted to do this in a manner that would not affect how other systems were handled. Again, I only have a UnisWare system on whick to build and test the changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Thu Apr 19 13:03:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Apr 2001 05:03:24 -0700 Subject: [Patches] [ python-Patches-417331 ] makestup should be called correctly Message-ID: Patches item #417331, was updated on 2001-04-19 05:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417331&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Neil Schemenauer (nascheme) Summary: makestup should be called correctly Initial Comment: The calls to makesetup in the Makefile and in configure should be the same. It is very important that the order of the Setup files are the same. The order in the Makefile is the correct one since it allows you to override things in Setup.local. This pertains to Python 2.1. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417331&group_id=5470 From noreply@sourceforge.net Thu Apr 19 22:55:42 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Apr 2001 14:55:42 -0700 Subject: [Patches] [ python-Patches-416248 ] 2.1c1 unicodeobject: unused vrbl cleanup Message-ID: Patches item #416248, was updated on 2001-04-15 04:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416248&group_id=5470 Category: core (C code) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Favas (mfavas) Assigned to: Tim Peters (tim_one) Summary: 2.1c1 unicodeobject: unused vrbl cleanup Initial Comment: Variable set but unused: *** unicodeobject.c.orig Sun Apr 15 18:10:43 2001 --- unicodeobject.c Sun Apr 15 18:11:57 2001 *************** *** 4793,4799 **** int flags = 0; int width = -1; int prec = -1; - int size = 0; Py_UNICODE c = '\0'; Py_UNICODE fill; PyObject *v = NULL; --- 4793,4798 ---- *************** *** 4931,4937 **** } /* prec */ if (fmtcnt >= 0) { if (c == 'h' || c == 'l' || c == 'L') { - size = c; if (--fmtcnt >= 0) c = *fmt++; } --- 4930,4935 ---- ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-19 14:55 Message: Logged In: YES user_id=31435 Patch applied to unicodeobject.c, rev 2.85. Thanks! ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-15 05:34 Message: Logged In: YES user_id=38388 Assigned to Tim, since he tweak this code ;-) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416248&group_id=5470 From noreply@sourceforge.net Sat Apr 21 05:19:19 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 20 Apr 2001 21:19:19 -0700 Subject: [Patches] [ python-Patches-417795 ] Fix memory cycles in Weak*Dictionary Message-ID: Patches item #417795, was updated on 2001-04-20 21:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417795&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Allouche (ddaa10) Assigned to: Nobody/Anonymous (nobody) Summary: Fix memory cycles in Weak*Dictionary Initial Comment: There is a subtle bug in WeakValueDictionary and WeakKeyDictonary that cause them to create reference cycles. This does not break anything by itself, but: 1/ it's bad to rely on the garbage collector; 2/ this could lead to uncollectable cycles if a subclass of Weak*Dictionary defines __del__. The trick is that deletions of a key/value of a item trigger a remove function. That remove function is strong referenced inside the weakref object. That function internally stores a strong reference to the self.data (dictionary) object. self.data obviously strong references the weakref object. The minimal overhead solution would be to use a __del__ method that would empty the self.data dictionary (thus breaking the references loops at Weak*Dictionary destruction). This solution is not acceptable since a key (for WeakValueDictionnary) or a value (for WeakKeyDictionary) can be a composite object. Such composite object can contain a reference which ultimately loops back to the Weak*Dictionary. Ok that's an user ref cycle, but the library __del__ method makes it uncollectable. The solution I propose is to change the remove function to contain, not a strong reference to the dictionary, but a weak reference to the Weak*Dictionary object. If the weakref has expired when the remove function is called; we just do nothing. This can lead to a silent change in behavior if the user has broken the encapsulation of the Weak*Dictionary and stored an external reference to the data dictionary. I think the best possible solution would be to give the choice between the two remove functions at runtime through a module variable. The attached patch makes a "weakref-patched.py" file from the "weakref.py" file of the 2.1 distribution. That file implements my proposed solution. It has been regression tested. It would make sense to add test units for memory cycles int test_weakref.py, but I'm too newbie (and do not have enough time) to do it myself. Keep on the good work. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417795&group_id=5470 From noreply@sourceforge.net Sat Apr 21 13:15:56 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Apr 2001 05:15:56 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: M.-A. Lemburg (lemburg) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:15 Message: Logged In: YES user_id=21627 Reopened, since the previous patch broke test_unicodedata. In this version, the cache is only consulted in DecodeASCII, since PyUnicode_FromUnicode must not share objects. It also has the requested init/fini code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-18 05:51 Message: Logged In: YES user_id=21627 Committed as 2.83 of unicodeobject.c, with the requested addition of init/fini code. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Sat Apr 21 14:18:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Apr 2001 06:18:34 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 06:18 Message: Logged In: YES user_id=21627 Dear Mr Allie, 0. cc -V reports Optimizing C Compilation System (CCS) 4.0 10/23/00 (UDK FS 7.1.1b) 1. Support for threads on UnixWare was there before the patch was applied. I don't think the patch really supports generating a shared Python library, though. When I compile Python 2.1, I get, after the first stage build, PYTHONPATH= ./python ./setup.py build dynamic linker : ./python : could not open libpython2.1.so *** Error code 137 (bu21) The cause is that the location of libpython2.1.so is not known to the dynamic linker. So your port does not work out of the box, the user is required to set LD_LIBRARY_PATH. This is precisely the reason why no other Unix port uses a shared libpython: it only causes problems, and gives no advantages. Why do you want libpython as a shared library? 2. It simplifies maintenance, since maintainers can reason whether some option needs to be carried over to a future release of the same system or a slightly similar system. Options that don't do anything cause confusion. 3. crti.o and crtn.o are certainly needed, they provide the .init and .fini section, and arrange to execute the .ctor and .dtor sections. See also bugreport 417491. 5. The mentioned compiler does support -Kpthread, cc(1) reports pthread Causes the same effect as -Kthread, except that in addition POSIX threads semantics are enabled at runtime for the fork(2), raise(3C), thr_exit(3thread), and pthread_exit(3pthread) calls. -lpthread is an acceptable synonym for -Kpthread. Therefore, even though there is no libpthread on the system, -lpthread can still be passed to the compiler, and the standard pthread detection routines in Python will work correctly. So in short, I think the entire patch should be backed out, and any remaining problems should be fixed differently. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-18 22:03 Message: Logged In: YES user_id=8500 loewis, First, a question. Are you using the SCO UDK compiler to compile Python? The UDK is the target compiler addressed by these patches (see the README file included with the patch). 1. This patch added support for using threads and to generate a shared Python library. 2. There is no reason to not explicitly specify the argument that are the defaults either. 3. I'll cede the point about using cc to link the shared modules, but the shared library does not need crti.o and crtn.o. They would be linked into the executable that references the shared library. 4. Perhaps, but my goal was to get UnixWare to compile with thread support and using shared libraries. I do not have access to those other systems, so I could not make chages to the way configure handles them (I wouldn't be able to test those changes). If others would like to make those changes, I would be willing to work with them to come up with a uniform way of teating the similar systems. 5. The UnixWare UDK requires the use of -Kthread to control the (correct) linking of the thread libraries. Using -lthread is specifically warned against. There is no -Kpthread option nor is there a libpthread library. The -Kthread option will load the POSIX thread routines if they are used. To reiterate, my goal was to be able to compile on UnixWare using shared libraries and including supprot for threads. I also wanted to do this in a manner that would not affect how other systems were handled. Again, I only have a UnisWare system on whick to build and test the changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Sat Apr 21 15:29:43 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Apr 2001 07:29:43 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 07:29 Message: Logged In: YES user_id=21627 I've added an alternative patch, which does return shared objects from PyUnicode_FromUnicode, and corrects the two places where the result of PyUnicode_FromUnicode did modify the resulting object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:15 Message: Logged In: YES user_id=21627 Reopened, since the previous patch broke test_unicodedata. In this version, the cache is only consulted in DecodeASCII, since PyUnicode_FromUnicode must not share objects. It also has the requested init/fini code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-18 05:51 Message: Logged In: YES user_id=21627 Committed as 2.83 of unicodeobject.c, with the requested addition of init/fini code. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Sat Apr 21 18:31:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Apr 2001 10:31:40 -0700 Subject: [Patches] [ python-Patches-417872 ] unset PYTHONHOME when running setup.py Message-ID: Patches item #417872, was updated on 2001-04-21 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 7 Submitted By: Neil Schemenauer (nascheme) Assigned to: A.M. Kuchling (akuchling) Summary: unset PYTHONHOME when running setup.py Initial Comment: This should be applied to the 2.1-maint branch as well. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417872&group_id=5470 From noreply@sourceforge.net Sat Apr 21 18:42:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Apr 2001 10:42:07 -0700 Subject: [Patches] [ python-Patches-417331 ] makestup should be called correctly Message-ID: Patches item #417331, was updated on 2001-04-19 05:03 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417331&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Neil Schemenauer (nascheme) Summary: makestup should be called correctly Initial Comment: The calls to makesetup in the Makefile and in configure should be the same. It is very important that the order of the Setup files are the same. The order in the Makefile is the correct one since it allows you to override things in Setup.local. This pertains to Python 2.1. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2001-04-21 10:42 Message: Logged In: YES user_id=35752 Applied to configure.in 1.217. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=417331&group_id=5470 From noreply@sourceforge.net Sat Apr 21 23:38:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 21 Apr 2001 15:38:10 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Billy G. Allie (ballie01) Date: 2001-04-21 15:38 Message: Logged In: YES user_id=8500 1. when compiling, you need to set LD_RUN_PATH to the directory that will contain the shared library. This is or should be standard operating procedure whenerve compiling programs that use shared libraries. Doing this prevents having to have LD_LIBRARY_PATH set when executing the program. For my use, I set LD_RUN_PATH=/usr/local/lib:/usr/local/pgsql/lib. Since I know I will be accessing PostgreSQL from python, I let python know that I will be using shared libraries contained in /usr/local/pgsql/lib. You would only need to set LD_LIBRARY_PATH=. when first building and testing python. The advantage of using a shared library includes, but is not limited to: a. Faster start-up times once the library is loaded into memory. Loading a 5k executable is faster than loading a 760k executable. b. Executables and other shared modules will not have to be recompiled if a fix needs to be made to one of the objects in the shared library (that does not invole change the parameter or return value of the object). 2. But the options do something - they make explicit the intent of the code. Also, what happens if the defaults change (not likely, I must admit, but possiple). Rather, then make matenance more difficult, I believe that it makes it easier, since the true intent is clear. But, I fear were are treading into the realm of philosopy and the "way to do things", where everyone has an (a differing, but equally valid) opinion, 3. I never said that they were not needed, only that they are included in the program using the shared library, not the library itself. 4. I have he save compiler version, but my cc(1) does not mention the -Kpthread flag. I will check into this and will change the UnixWare build to use it. It would appear to alieviate the need to implement the fork1() call. As to rolling out the patch, I disagree. Having the shared library does have some addvantages, and the proper setting/use of LD_RUN_PATH and LD_LIBRARY_PATH can be handled with a platform specific FAQ. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 06:18 Message: Logged In: YES user_id=21627 Dear Mr Allie, 0. cc -V reports Optimizing C Compilation System (CCS) 4.0 10/23/00 (UDK FS 7.1.1b) 1. Support for threads on UnixWare was there before the patch was applied. I don't think the patch really supports generating a shared Python library, though. When I compile Python 2.1, I get, after the first stage build, PYTHONPATH= ./python ./setup.py build dynamic linker : ./python : could not open libpython2.1.so *** Error code 137 (bu21) The cause is that the location of libpython2.1.so is not known to the dynamic linker. So your port does not work out of the box, the user is required to set LD_LIBRARY_PATH. This is precisely the reason why no other Unix port uses a shared libpython: it only causes problems, and gives no advantages. Why do you want libpython as a shared library? 2. It simplifies maintenance, since maintainers can reason whether some option needs to be carried over to a future release of the same system or a slightly similar system. Options that don't do anything cause confusion. 3. crti.o and crtn.o are certainly needed, they provide the .init and .fini section, and arrange to execute the .ctor and .dtor sections. See also bugreport 417491. 5. The mentioned compiler does support -Kpthread, cc(1) reports pthread Causes the same effect as -Kthread, except that in addition POSIX threads semantics are enabled at runtime for the fork(2), raise(3C), thr_exit(3thread), and pthread_exit(3pthread) calls. -lpthread is an acceptable synonym for -Kpthread. Therefore, even though there is no libpthread on the system, -lpthread can still be passed to the compiler, and the standard pthread detection routines in Python will work correctly. So in short, I think the entire patch should be backed out, and any remaining problems should be fixed differently. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-18 22:03 Message: Logged In: YES user_id=8500 loewis, First, a question. Are you using the SCO UDK compiler to compile Python? The UDK is the target compiler addressed by these patches (see the README file included with the patch). 1. This patch added support for using threads and to generate a shared Python library. 2. There is no reason to not explicitly specify the argument that are the defaults either. 3. I'll cede the point about using cc to link the shared modules, but the shared library does not need crti.o and crtn.o. They would be linked into the executable that references the shared library. 4. Perhaps, but my goal was to get UnixWare to compile with thread support and using shared libraries. I do not have access to those other systems, so I could not make chages to the way configure handles them (I wouldn't be able to test those changes). If others would like to make those changes, I would be willing to work with them to come up with a uniform way of teating the similar systems. 5. The UnixWare UDK requires the use of -Kthread to control the (correct) linking of the thread libraries. Using -lthread is specifically warned against. There is no -Kpthread option nor is there a libpthread library. The -Kthread option will load the POSIX thread routines if they are used. To reiterate, my goal was to be able to compile on UnixWare using shared libraries and including supprot for threads. I also wanted to do this in a manner that would not affect how other systems were handled. Again, I only have a UnisWare system on whick to build and test the changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Sun Apr 22 14:26:27 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 06:26:27 -0700 Subject: [Patches] [ python-Patches-410046 ] asynchat: handle excessive response size Message-ID: Patches item #410046, was updated on 2001-03-20 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Fort (dougfort) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat: handle excessive response size Initial Comment: When reading with a numeric terminator, asynchat assumes that if the server didn't send fewer bytes than requested, that it sent exactly the number of bytes requested. This is normally the case, but an overloaded server can return an error message that is larger than the number of bytes requested. When this happens asynchttp.handle_read() goes into a tight loop, returning an empty string for data and zero for a terminator. This patch raises an exception if the number of bytes returned exceeds the number requested. It's kind of an ugly fix, because asynchttp doesn't raise any other exceptions, and passes on those it catches to handle_error. However, this really is an exceptional case, and the results of not handling it are disastrous. ---------------------------------------------------------------------- >Comment By: Doug Fort (dougfort) Date: 2001-04-22 06:26 Message: Logged In: YES user_id=6399 I have sent a copy of the patch to Sam Rushing with a request for review. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:16 Message: Logged In: YES user_id=6380 Doug, I'm hesitant to apply this right before releasing 2.1 -- I have no way to test this code. Can you ask for a review by Sam Rushing, asynchat.py's author? ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-25 06:22 Message: Logged In: YES user_id=6399 I have discovered that there are real cases where the server sends back more bytes than requested: specifically in Trannsfer-mode: chunked. Here is a revised, much simpler patch that passes on the data. *** asynchat.py.original Tue Mar 20 10:43:01 2001 --- asynchat.py Sun Mar 25 09:13:56 2001 *************** *** 106,113 **** self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: --- 106,113 ---- self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() else: ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-20 08:36 Message: Logged In: YES user_id=6399 *** asynchat.pyTue Mar 20 11:11:58 2001 --- asynchat.py.originalTue Mar 20 10:43:01 2001 *************** *** 49,60 **** import socket import asyncore - class async_chat_exception(Exception): - def __init__(self, message): - self._message = message - def __str__(self): - return self._message - class async_chat (asyncore.dispatcher): """This is an abstract class. You must derive from this class, and add the two methods collect_incoming_data() and found_terminator()""" --- 49,54 ---- *************** *** 111,128 **** self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! elif lb == n: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() - else: - # if we got back more than we asked for, the server - # is badly confused - raise async_chat_exception( - "Unexpect response: requested %s bytes got %s. %s" % ( - n, lb, self.ac_in_buffer - )) else: # 3 cases: # 1) end of buffer matches terminator exactly: --- 105,115 ---- self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! else: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: # 3 cases: # 1) end of buffer matches terminator exactly: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 From noreply@sourceforge.net Sun Apr 22 15:55:09 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 07:55:09 -0700 Subject: [Patches] [ python-Patches-418011 ] Updated zipfile docs Message-ID: Patches item #418011, was updated on 2001-04-22 07:54 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418011&group_id=5470 Category: documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Nobody/Anonymous (nobody) Summary: Updated zipfile docs Initial Comment: Updates zipfile.ZipFile's docs so it mentions that fact you can open arbitary file-like objects. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418011&group_id=5470 From noreply@sourceforge.net Sun Apr 22 18:56:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 10:56:02 -0700 Subject: [Patches] [ python-Patches-413011 ] Port to UnixWare 7.1.x for Python 2.1 Message-ID: Patches item #413011, was updated on 2001-04-02 00:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Billy G. Allie (ballie01) Assigned to: Nobody/Anonymous (nobody) Summary: Port to UnixWare 7.1.x for Python 2.1 Initial Comment: The attached file contains patches and files needed to allow Python-2.1(b2a) to be configured and compiled successfully on a SCO UnixWare 7.1.x system using the SCO Universal Development Kit (UDK). The compiled Python-2.1(2ba) executable did not fail any tests except for the atan2(0,1) math test. UnixWare returns pi instead of the expected 0.0 result. The Python-2.1 on UnixWare 7.1.x will have a shared Python-2.1 library, have dynamically loadable modules, and support for theads. The attached tar file (Python-2.1b2a-UW7.tar.gz) contains a README file describing the details of the changes. The MD5 checksum for the attached file is: 46704c26064c41f195decccd60adffab Billy G. Allie ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2001-04-22 10:56 Message: Logged In: YES user_id=21627 1. Instead of requiring administrators to set LD_RUN_PATH, configure should automatically set all proper options, -R/lib in this case. However, I still doubt that using a shared library offers advantages: a. According to my measurements, linking python statically brings a 50% speed-up in startup time when *not* using shared libraries. This is because: I. fewer shared libraries have to be located and loaded II. the LD_RUN_PATH is shorter, so fewer directories have to be searched III. The main part of the interpreter is not compiled with -KPIC; PIC code is typically slower since EBX is not available to the optimizer. The size of the executable is pointless; the system has to load libpython21.so in the shared case, which is 800k b. There is typically only a single executable relying on libpython.so, so the administrative overhead of replacing the library is the same as replacing the executable. There may be applications to a shared libpython, but given the pain that this causes, that should be a configuration option, and off by default. As an option, it should equally apply to all ELF-based systems, at a minimum. 3. crti and crtn are needed in *every* shared library, otherwise, constructors don't work. Use -# to see how the linker is invoked for -G, to notice that it not only links crti/crtn, but also libcrt. 4. I just checked that supporting -lpthread is required by Single Unix from conforming implementations, see http://www.opengroup.org/onlinepubs/007908799/xcu/c89.html So I'm surprised your UnixWare copy does not support it. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-21 15:38 Message: Logged In: YES user_id=8500 1. when compiling, you need to set LD_RUN_PATH to the directory that will contain the shared library. This is or should be standard operating procedure whenerve compiling programs that use shared libraries. Doing this prevents having to have LD_LIBRARY_PATH set when executing the program. For my use, I set LD_RUN_PATH=/usr/local/lib:/usr/local/pgsql/lib. Since I know I will be accessing PostgreSQL from python, I let python know that I will be using shared libraries contained in /usr/local/pgsql/lib. You would only need to set LD_LIBRARY_PATH=. when first building and testing python. The advantage of using a shared library includes, but is not limited to: a. Faster start-up times once the library is loaded into memory. Loading a 5k executable is faster than loading a 760k executable. b. Executables and other shared modules will not have to be recompiled if a fix needs to be made to one of the objects in the shared library (that does not invole change the parameter or return value of the object). 2. But the options do something - they make explicit the intent of the code. Also, what happens if the defaults change (not likely, I must admit, but possiple). Rather, then make matenance more difficult, I believe that it makes it easier, since the true intent is clear. But, I fear were are treading into the realm of philosopy and the "way to do things", where everyone has an (a differing, but equally valid) opinion, 3. I never said that they were not needed, only that they are included in the program using the shared library, not the library itself. 4. I have he save compiler version, but my cc(1) does not mention the -Kpthread flag. I will check into this and will change the UnixWare build to use it. It would appear to alieviate the need to implement the fork1() call. As to rolling out the patch, I disagree. Having the shared library does have some addvantages, and the proper setting/use of LD_RUN_PATH and LD_LIBRARY_PATH can be handled with a platform specific FAQ. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 06:18 Message: Logged In: YES user_id=21627 Dear Mr Allie, 0. cc -V reports Optimizing C Compilation System (CCS) 4.0 10/23/00 (UDK FS 7.1.1b) 1. Support for threads on UnixWare was there before the patch was applied. I don't think the patch really supports generating a shared Python library, though. When I compile Python 2.1, I get, after the first stage build, PYTHONPATH= ./python ./setup.py build dynamic linker : ./python : could not open libpython2.1.so *** Error code 137 (bu21) The cause is that the location of libpython2.1.so is not known to the dynamic linker. So your port does not work out of the box, the user is required to set LD_LIBRARY_PATH. This is precisely the reason why no other Unix port uses a shared libpython: it only causes problems, and gives no advantages. Why do you want libpython as a shared library? 2. It simplifies maintenance, since maintainers can reason whether some option needs to be carried over to a future release of the same system or a slightly similar system. Options that don't do anything cause confusion. 3. crti.o and crtn.o are certainly needed, they provide the .init and .fini section, and arrange to execute the .ctor and .dtor sections. See also bugreport 417491. 5. The mentioned compiler does support -Kpthread, cc(1) reports pthread Causes the same effect as -Kthread, except that in addition POSIX threads semantics are enabled at runtime for the fork(2), raise(3C), thr_exit(3thread), and pthread_exit(3pthread) calls. -lpthread is an acceptable synonym for -Kpthread. Therefore, even though there is no libpthread on the system, -lpthread can still be passed to the compiler, and the standard pthread detection routines in Python will work correctly. So in short, I think the entire patch should be backed out, and any remaining problems should be fixed differently. ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-18 22:03 Message: Logged In: YES user_id=8500 loewis, First, a question. Are you using the SCO UDK compiler to compile Python? The UDK is the target compiler addressed by these patches (see the README file included with the patch). 1. This patch added support for using threads and to generate a shared Python library. 2. There is no reason to not explicitly specify the argument that are the defaults either. 3. I'll cede the point about using cc to link the shared modules, but the shared library does not need crti.o and crtn.o. They would be linked into the executable that references the shared library. 4. Perhaps, but my goal was to get UnixWare to compile with thread support and using shared libraries. I do not have access to those other systems, so I could not make chages to the way configure handles them (I wouldn't be able to test those changes). If others would like to make those changes, I would be willing to work with them to come up with a uniform way of teating the similar systems. 5. The UnixWare UDK requires the use of -Kthread to control the (correct) linking of the thread libraries. Using -lthread is specifically warned against. There is no -Kpthread option nor is there a libpthread library. The -Kthread option will load the POSIX thread routines if they are used. To reiterate, my goal was to be able to compile on UnixWare using shared libraries and including supprot for threads. I also wanted to do this in a manner that would not affect how other systems were handled. Again, I only have a UnisWare system on whick to build and test the changes. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-13 15:04 Message: Logged In: YES user_id=21627 Even though this patch has been applied, I'd like to express my concerns about it. First, Python 2.1b2 was compiling correctly on UnixWare even without this patch, atleast since configure.in 1.212. So what specific problem had been corrected with this patch? Next, the patch seems to overspecify compiler and linker options. Eg. -dy is the default, so there is no need to explicitly specify it. Also, in many cases, using cc to link executables and libraries is better than using ld, since cc will automatically pass missing options, object files, and libraries. E.g. with your options, crti.o and crtn.o won't be included into the shared libraries, but should be (See Notices in ld(1)). The patch adds code specific to UnixWare which would apply to many other systems (Solaris, Linux, ReliantUnix), and it would be good if these systems would be treated uniformly. E.g. it creates libpython as a shared library. Why only on Unixware, why not on Solaris or Linux? Likewise, why the special casing on threads? There are other systems (SysV variants) that also support -Kthread, so there should be a test whether the compiler supports the flag, not whether the system is Unixware. Also, shouldn't this be -Kpthread, not -Kthread? Finally, isn't just using -lpthread enough? ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 14:19 Message: Logged In: YES user_id=8500 Every thing looks fine (as far as I can tell). Thanks. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-11 14:00 Message: Logged In: YES user_id=6380 Thanks, that's much better! Applied now. (Please check that I checked everything in... :-) ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:13 Message: Logged In: YES user_id=8500 here is the MD5 checksum for the corrected patch: MD5 (Python-2.1b2a.UW7.p2.tar.gz) = 62941fcbdd0d4272767b52b2a42d9388 ---------------------------------------------------------------------- Comment By: Billy G. Allie (ballie01) Date: 2001-04-11 13:08 Message: Logged In: YES user_id=8500 Here is a corrected patch file. I pulled the latest files from CVS and patched those. These should be fine. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:47 Message: Logged In: YES user_id=6380 Something went wrong with tabs and spaces in your patch; it appears the version of the sources you diffed against had some tabs replaced with spaces or vice versa. Unless yu can supply a correct context diff really fast, I won't be able to include this patch in Python 2.1. I don't have the time to review every change and to manually apply the chunks that patch rejects. (Esp. configure.in). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413011&group_id=5470 From noreply@sourceforge.net Sun Apr 22 19:43:44 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 11:43:44 -0700 Subject: [Patches] [ python-Patches-403703 ] Fix for Tools\compiler\transformer.py and renaming Message-ID: Patches item #403703, was updated on 2001-02-08 23:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403703&group_id=5470 Category: library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: Jeremy Hylton (jhylton) Summary: Fix for Tools\compiler\transformer.py and renaming Initial Comment: This patch fixes a problem with transformer.py and statements with the following form: "from x import y as z". In the previous version, that statement would be encoded as: From('x', [('y', None)]) instead of From('x', [('y', 'z')]) ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-04-22 11:43 Message: Logged In: YES user_id=108973 Transformer.py commit 1.20 fixes this problem. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=403703&group_id=5470 From noreply@sourceforge.net Sun Apr 22 19:45:46 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 11:45:46 -0700 Subject: [Patches] [ python-Patches-413333 ] Improved support for unicode conversions Message-ID: Patches item #413333, was updated on 2001-04-02 23:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Quinlan (bquinlan) Assigned to: M.-A. Lemburg (lemburg) Summary: Improved support for unicode conversions Initial Comment: This patch is designed to increase the flexibility of the unicode conversion function. The proposed strategy is: def unicode( val ) if type( val ) == type.UnicodeType: return val else: return str_to_unicode( str( val ) ) This makes it possible to perform operations such as: unicode( 5 ) => u'5' without generating an exception. ---------------------------------------------------------------------- >Comment By: Brian Quinlan (bquinlan) Date: 2001-04-22 11:45 Message: Logged In: YES user_id=108973 I would propose ignoring this patch, leaving the existing function as is, and adding an additional function to unicodeobject.c that does this. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:35 Message: Logged In: YES user_id=6380 Too late for 2.1 -- no functionality changes allowed. Assigned to Marc-Andre, who's in charge of Unicode. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=413333&group_id=5470 From noreply@sourceforge.net Sun Apr 22 21:34:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 13:34:47 -0700 Subject: [Patches] [ python-Patches-410046 ] asynchat: handle excessive response size Message-ID: Patches item #410046, was updated on 2001-03-20 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 Category: library Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: Doug Fort (dougfort) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat: handle excessive response size Initial Comment: When reading with a numeric terminator, asynchat assumes that if the server didn't send fewer bytes than requested, that it sent exactly the number of bytes requested. This is normally the case, but an overloaded server can return an error message that is larger than the number of bytes requested. When this happens asynchttp.handle_read() goes into a tight loop, returning an empty string for data and zero for a terminator. This patch raises an exception if the number of bytes returned exceeds the number requested. It's kind of an ugly fix, because asynchttp doesn't raise any other exceptions, and passes on those it catches to handle_error. However, this really is an exceptional case, and the results of not handling it are disastrous. ---------------------------------------------------------------------- >Comment By: Doug Fort (dougfort) Date: 2001-04-22 13:34 Message: Logged In: YES user_id=6399 Sam Rushing thinks that this patch will break other protocols. I have to admit, I was only concerned with HTTP. I can work around them problem by overloading handle_read(), so why don't we forget the whole thing? ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-04-22 06:26 Message: Logged In: YES user_id=6399 I have sent a copy of the patch to Sam Rushing with a request for review. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 15:16 Message: Logged In: YES user_id=6380 Doug, I'm hesitant to apply this right before releasing 2.1 -- I have no way to test this code. Can you ask for a review by Sam Rushing, asynchat.py's author? ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-25 06:22 Message: Logged In: YES user_id=6399 I have discovered that there are real cases where the server sends back more bytes than requested: specifically in Trannsfer-mode: chunked. Here is a revised, much simpler patch that passes on the data. *** asynchat.py.original Tue Mar 20 10:43:01 2001 --- asynchat.py Sun Mar 25 09:13:56 2001 *************** *** 106,113 **** self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: --- 106,113 ---- self.ac_in_buffer = '' self.terminator = self.terminator - lb else: ! self.collect_incoming_data (self.ac_in_buffer) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() else: ---------------------------------------------------------------------- Comment By: Doug Fort (dougfort) Date: 2001-03-20 08:36 Message: Logged In: YES user_id=6399 *** asynchat.pyTue Mar 20 11:11:58 2001 --- asynchat.py.originalTue Mar 20 10:43:01 2001 *************** *** 49,60 **** import socket import asyncore - class async_chat_exception(Exception): - def __init__(self, message): - self._message = message - def __str__(self): - return self._message - class async_chat (asyncore.dispatcher): """This is an abstract class. You must derive from this class, and add the two methods collect_incoming_data() and found_terminator()""" --- 49,54 ---- *************** *** 111,128 **** self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! elif lb == n: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = '' self.terminator = 0 self.found_terminator() - else: - # if we got back more than we asked for, the server - # is badly confused - raise async_chat_exception( - "Unexpect response: requested %s bytes got %s. %s" % ( - n, lb, self.ac_in_buffer - )) else: # 3 cases: # 1) end of buffer matches terminator exactly: --- 105,115 ---- self.collect_incoming_data (self.ac_in_buffer) self.ac_in_buffer = '' self.terminator = self.terminator - lb ! else: self.collect_incoming_data (self.ac_in_buffer[:n]) ! self.ac_in_buffer = self.ac_in_buffer[n:] self.terminator = 0 self.found_terminator() else: # 3 cases: # 1) end of buffer matches terminator exactly: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410046&group_id=5470 From noreply@sourceforge.net Mon Apr 23 07:59:31 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Apr 2001 23:59:31 -0700 Subject: [Patches] [ python-Patches-418147 ] Fixes to allow compiling w/ Borland Message-ID: Patches item #418147, was updated on 2001-04-22 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418147&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Hansen (ixokai) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes to allow compiling w/ Borland Initial Comment: This patch supercedes the following bugs that I submitted before realizing it'd be better to just submit one big patch: 417802, 417949, 417952 So if someone wants to close them, they can :) Now, an explaination of the changes I found that needed to be done: In pyport.h, I put a couple #defines to make rename chsize/setmode to _chsize/_setmode.. why there? I really couldn't think of a better place to put it, and it seemed better then surrounding the calls to '_chsize/_setmode' with #ifdef __BORLANDC_'s. Posixmodule needed a lot of fixes. Borland obviousely doesn't support Unixish *id's, firstly. Secondly, io.h defines chmod as 'chmod(const char *, int amode)', and we called an 'extern chmod(const char *, mode_t)', so that needed to be altered. Later, it needed to include __BORLANDC__ in the places where it names 'posixmodule' as 'nt'. In Timemodule, we have some renamings to do again. I put them here instead of pyport.h, since it already had most of them for Win16, even though I don't know if that was best or not. Further, Borland needs to keep HAVE_CLOCK, so I had to make it so Mark Hammond's clock code didn't replace the built in one. Config.h needed a few changes. I moved HAVE_SYS_UTIME_H up by HAVE_HYPOT, so it could be defined for everything still, and just have Borland #undef it... So I basically copied what they did with HAVE_HYPOT. Okay, so all of the above was actually rather self- explainatory from the patch. Oh well. :) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418147&group_id=5470 From noreply@sourceforge.net Mon Apr 23 12:26:50 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 04:26:50 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-23 04:26 Message: Logged In: YES user_id=38388 Thanks for the update. Digging a little deeper into the possibilities of sharing Unicode objects I found that there are some important issues to be taken into consideration which require a little more work on the sharing code. I will work on this during the week and get back to you next week. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 07:29 Message: Logged In: YES user_id=21627 I've added an alternative patch, which does return shared objects from PyUnicode_FromUnicode, and corrects the two places where the result of PyUnicode_FromUnicode did modify the resulting object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:15 Message: Logged In: YES user_id=21627 Reopened, since the previous patch broke test_unicodedata. In this version, the cache is only consulted in DecodeASCII, since PyUnicode_FromUnicode must not share objects. It also has the requested init/fini code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-18 05:51 Message: Logged In: YES user_id=21627 Committed as 2.83 of unicodeobject.c, with the requested addition of init/fini code. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Mon Apr 23 15:44:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 07:44:35 -0700 Subject: [Patches] [ python-Patches-416953 ] Speed up ASCII decoding Message-ID: Patches item #416953, was updated on 2001-04-17 22:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: M.-A. Lemburg (lemburg) Summary: Speed up ASCII decoding Initial Comment: In code that supports both byte and unicode strings, mixing unicode strings with plain character constants is frequent. E.g. both sre_compile and xmlproc look for specific characters in an input string. Every usage of such a character requires default decoding, which will create a temporary Unicode object. This patch caches Unicode objects that represent ASCII characters. On the benchmark import time u = u"" t=time.time() for i in xrange(1000000): u+"(" print time.time()-t it shows a 10% speed-up. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-23 07:44 Message: Logged In: YES user_id=38388 Checked in a modified patch. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-23 04:26 Message: Logged In: YES user_id=38388 Thanks for the update. Digging a little deeper into the possibilities of sharing Unicode objects I found that there are some important issues to be taken into consideration which require a little more work on the sharing code. I will work on this during the week and get back to you next week. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 07:29 Message: Logged In: YES user_id=21627 I've added an alternative patch, which does return shared objects from PyUnicode_FromUnicode, and corrects the two places where the result of PyUnicode_FromUnicode did modify the resulting object. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-21 05:15 Message: Logged In: YES user_id=21627 Reopened, since the previous patch broke test_unicodedata. In this version, the cache is only consulted in DecodeASCII, since PyUnicode_FromUnicode must not share objects. It also has the requested init/fini code. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-18 05:51 Message: Logged In: YES user_id=21627 Committed as 2.83 of unicodeobject.c, with the requested addition of init/fini code. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-18 01:54 Message: Logged In: YES user_id=38388 I knew this would come one day :-) The patch looks OK, but please also add proper init and finalize code so that unicode_ascii[] gets cleared up properly when the interpreter shuts down (this is important for uses of Python in e.g. mod_snake). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2001-04-17 23:04 Message: Logged In: YES user_id=21627 Attach patch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=416953&group_id=5470 From noreply@sourceforge.net Mon Apr 23 20:50:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 12:50:24 -0700 Subject: [Patches] [ python-Patches-414391 ] Inplace optimization for binary ops Message-ID: Patches item #414391, was updated on 2001-04-06 13:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 Category: core (C code) Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Robin Thomas (robin900) Assigned to: Nobody/Anonymous (nobody) Summary: Inplace optimization for binary ops Initial Comment: The idea behind this patch: >>> x = range(100) + [1,2,3] + range(90) creates *five* list objects before binding the fifth list object to x. Four of the five objects are discarded. Or: >>> x = range(100) + [2] creates three list objects and discards two. How can we make this more efficient? The implementation overview: When the Python VM POP()s two objects from the stack when doing a BINARY_* opcode, the frame owns one reference to each object. If the left operand object (second one popped) has a reference count of 1, then the object is only reachable by the VM in this frame. Since the VM will DECREF() the object after completing the binary operation and thus discard it, why not do the in-place version of the binary operation? This makes the above example more efficient (by making only three list objects and two list objects, respectively). Any questions, mail me or post to python-list, where the patch and other discussion is present. The patch posted to python-list is against 2.1b1 release. On Mon Apr 09, I will create a cvs diff against current tree and upload here on Sourceforge. ---------------------------------------------------------------------- >Comment By: Robin Thomas (robin900) Date: 2001-04-23 12:50 Message: Logged In: YES user_id=127529 closing patch since it's not relevant to current development. ---------------------------------------------------------------------- Comment By: Robin Thomas (robin900) Date: 2001-04-11 18:00 Message: Logged In: YES user_id=127529 The performance stats are bad: a loss (on my Solaris Sparc) of ~180 pystones/sec. Sigh. I'm posting the patch anyway, so that if others find it useful and wish to revive, it will be here. ---------------------------------------------------------------------- Comment By: Robin Thomas (robin900) Date: 2001-04-11 08:21 Message: Logged In: YES user_id=127529 Yes, I'll upload; I never wanted to to go hunting for the patch! :) Some colleagues and I have gathered performance stats on the patch. List concat/repeat is 15-25% faster, but ops on built-in numerics are 1-2% slower. Using Python "make test" to measure the distribution of ops/types, it's almost a wash: ops on built-in numerics are about 10 times more common than list concat/repeat. However, we don't want this patch to be list-specific; the original need was for a general hook so that extension types and user-defined classes could take advantage of the in-place optimization without doing fancy dancing in their own code. Thus, the patch will include a README with our performance and survey findings, and we'll leave the issue open for debate. Expect a patch upload today or tomorrow. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-04-10 14:29 Message: Logged In: YES user_id=6380 Sorry, I don't have the resources to search c.l.py. Can you please upload your patch here? The file uploads should work fine if you check the checkbox above the Browse button. This won't go into 2.1, obviously, so a patch against 2.1 when it is released (expected 4/16/01) would work too. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=414391&group_id=5470 From noreply@sourceforge.net Mon Apr 23 23:39:52 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 15:39:52 -0700 Subject: [Patches] [ python-Patches-418390 ] static member functions Message-ID: Patches item #418390, was updated on 2001-04-23 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: static member functions Initial Comment: This allows for class methods to be called statically without the need for workaround abuse as described in the python FAQ (or any other method involving grabbing the "im_func" member from an unbound method object). This patch changes the "call_method" function in ceval.c. It removes the improper 'class type enforcement' on unbound method objects and just passes the arguments as is. This allows for natural and clean static methods inside classes. The only thing potentially broken with this patch is a looser guarantee that the "self" value for a method would be some inherited type instance. This is far less 'dangerous for abuse' than other python class designs (no private members, etc). With this the static method example in the FAQ is much more cleanly realized. notice, no "self" member for static methods... class C: count = 0 def __init__(self): C.count += 1 def getcount(): return C.count def sum(x, y): return x + y C(); C() c = C() print C.getcount() # prints 3 print c.getcount() # prints 3 print C.sum(27, 15) # prints 42 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 From noreply@sourceforge.net Mon Apr 23 23:47:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 15:47:36 -0700 Subject: [Patches] [ python-Patches-418390 ] static member functions Message-ID: Patches item #418390, was updated on 2001-04-23 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: static member functions Initial Comment: This allows for class methods to be called statically without the need for workaround abuse as described in the python FAQ (or any other method involving grabbing the "im_func" member from an unbound method object). This patch changes the "call_method" function in ceval.c. It removes the improper 'class type enforcement' on unbound method objects and just passes the arguments as is. This allows for natural and clean static methods inside classes. The only thing potentially broken with this patch is a looser guarantee that the "self" value for a method would be some inherited type instance. This is far less 'dangerous for abuse' than other python class designs (no private members, etc). With this the static method example in the FAQ is much more cleanly realized. notice, no "self" member for static methods... class C: count = 0 def __init__(self): C.count += 1 def getcount(): return C.count def sum(x, y): return x + y C(); C() c = C() print C.getcount() # prints 3 print c.getcount() # prints 3 print C.sum(27, 15) # prints 42 ---------------------------------------------------------------------- Comment By: Mark Kimsal (hardcoreholly) Date: 2001-04-23 15:47 Message: Logged In: YES user_id=89302 an application programmer could still secure the type of the arguments if s/he felt it was necessary by raising the unbound method exception if the first arg was not the expected type. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 From noreply@sourceforge.net Tue Apr 24 00:00:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 16:00:26 -0700 Subject: [Patches] [ python-Patches-418390 ] static member functions Message-ID: Patches item #418390, was updated on 2001-04-23 15:39 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: static member functions Initial Comment: This allows for class methods to be called statically without the need for workaround abuse as described in the python FAQ (or any other method involving grabbing the "im_func" member from an unbound method object). This patch changes the "call_method" function in ceval.c. It removes the improper 'class type enforcement' on unbound method objects and just passes the arguments as is. This allows for natural and clean static methods inside classes. The only thing potentially broken with this patch is a looser guarantee that the "self" value for a method would be some inherited type instance. This is far less 'dangerous for abuse' than other python class designs (no private members, etc). With this the static method example in the FAQ is much more cleanly realized. notice, no "self" member for static methods... class C: count = 0 def __init__(self): C.count += 1 def getcount(): return C.count def sum(x, y): return x + y C(); C() c = C() print C.getcount() # prints 3 print c.getcount() # prints 3 print C.sum(27, 15) # prints 42 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-04-23 16:00 Message: Logged In: NO btw, i did submit with my email address, but sourceforge has relabeled me as anonymous. please respond to "pete at shinners dot org" should that be required. doh, i see sourceforge didn't respect my example formatting either. ---------------------------------------------------------------------- Comment By: Mark Kimsal (hardcoreholly) Date: 2001-04-23 15:47 Message: Logged In: YES user_id=89302 an application programmer could still secure the type of the arguments if s/he felt it was necessary by raising the unbound method exception if the first arg was not the expected type. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418390&group_id=5470 From noreply@sourceforge.net Tue Apr 24 06:11:02 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 22:11:02 -0700 Subject: [Patches] [ python-Patches-418465 ] patches for python-mode.el V4.1 Message-ID: Patches item #418465, was updated on 2001-04-23 22:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418465&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Weiner (bwcto) Assigned to: Nobody/Anonymous (nobody) Summary: patches for python-mode.el V4.1 Initial Comment: This patch fixes a number of issues with python- mode.el (the fixes are documented within the patch) and also extends python-mode.el so that it works with the emacs interface to pydoc, pydoc.el which was just released . Please let me know if you decide to apply all of these changes and put this into a production release of Python, at which point, I will stop distributing the modified python-mode.el with the pydoc.el package. Thanks, Bob ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418465&group_id=5470 From noreply@sourceforge.net Tue Apr 24 07:58:21 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 23 Apr 2001 23:58:21 -0700 Subject: [Patches] [ python-Patches-418489 ] unittest string format error Message-ID: Patches item #418489, was updated on 2001-04-23 23:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418489&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: unittest string format error Initial Comment: unittest.loadTestsFromName has a string format error of the form - it needs some parens. Currently is: raise ValueError, \ "calling %s returned %s, not a test" % obj,test should be raise ValueError, \ "calling %s returned %s, not a test" % (obj,test) Let's see if this really will let me upload a patch. Index: unittest.py ======================================================= ============ RCS file: /cvsroot/python/python/dist/src/Lib/unittest.py,v retrieving revision 1.7 diff -c -r1.7 unittest.py *** unittest.py 2001/04/15 09:18:32 1.7 --- unittest.py 2001/04/24 06:57:32 *************** *** 443,449 **** if not isinstance(test, TestCase) and \ not isinstance(test, TestSuite): raise ValueError, \ ! "calling %s returned %s, not a test" % obj,test return test else: raise ValueError, "don't know how to make test from: %s" % obj --- 443,449 ---- if not isinstance(test, TestCase) and \ not isinstance(test, TestSuite): raise ValueError, \ ! "calling %s returned %s, not a test" % (obj, test) return test else: raise ValueError, "don't know how to make test from: %s" % obj ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418489&group_id=5470 From thelink Tue Apr 24 15:21:54 2001 From: thelink (thelink) Date: Tue, 24 Apr 2001 16:21:54 +0200 Subject: [Patches] WWW.090000900.COM GAGNEZ 1 AN DE COMMUNICATIONS GSM ! WIN 1 JAAR GRATIS GSM-GEBRUIK ! Message-ID: <007601c0ccc9$e9f7d540$01fea8c0@jctubiermont.brutele.be> This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C0CCDA.AD2CB8E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006F_01C0CCDA.AD2CB8E0" ------=_NextPart_001_006F_01C0CCDA.AD2CB8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --{ Liste h=E9berg=E9e par PoPList }------{ http://www.poplist.fr/ }-- --{ Voir en bas de ce mail les options de d=E9sabonnement }-- ______________________________________________________________________ GAGNEZ 1 AN DE COMMUNICATIONS GSM GRATUITES ! WIN 1 JAAR GRATIS GSM-GEBRUIK ! =20=20=20=20=20=20=20 TELECHARGEZ PAR SMS 1500 LOGOS et SONNERIES AU TARIF LE PLUS BAS ( 30 bef /= unite ) ! DOWNLOAD PER SMS 1500 LOGOS en RINGTONES AAN HET LAAGSTE TARIEF ( 30 bef / = stuk ) ! http://www.090000900.com $ Pour vous d=E9sabonner, rendez-vous simplement sur cette page : -> ------=_NextPart_001_006F_01C0CCDA.AD2CB8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
GAGNEZ 1 AN DE COMMUNICATIONS GSM GRATUITES=20 !
      
 
TELECHARGEZ PAR SMS 1500 LOGOS et SONNERIES AU TARIF LE PLUS BAS (= 30 bef=20 / unite ) !
DOWNLOAD=20 PER SMS 1500 LOGOS en RINGTONES AAN HET LAAGSTE TARIEF ( 30 bef / stuk )=20 !
http://www.090000900.com
 
$
 
Pour vous d=E9sabonner, rendez-vous simplement sur cette page :
< http://cgi.poplist.fr/@/u/electro/patches@python.org>
------=_NextPart_001_006F_01C0CCDA.AD2CB8E0-- ------=_NextPart_000_006E_01C0CCDA.AD2CB8E0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Id: <006201c0ccc9$e9718e40$01fea8c0@jctubiermont.brutele.be> R0lGODlhgACAAMQWAPSpi4Y2a5FKeapmk/KPaP7+/uxeJvnSw7FJUO1pNM1S Or2Tr+94Sfe/qPjn49Gzx+RbK/z089/L2Prf1OldKP3v6f///wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFZAAW ACwAAAAAgACAAAAF/2AgjmRpnmiqrmzrvnAsz3Rt33iu73zv/zSIcAihUIjG 4nGYZCaXRCTTOV1Cp0JrFvrENqvRsBRlKJvP6LR6zW673/B4nIKiyO/4vH4P h9T5gIGCg2Z+J3aEiYqLaoYmiIyRkoGOJZCTmIAMAAcOEREOBwAMd5Ukl5mp cgwHBQUREwedEa4NpH1/qrpvCQCvBwQJZwkErREAwm6mI6i7ugkMBAAEDA0F EwRtBA4FAG/LIs1x0LfOBuTJbAQNtK7u2W4ME93KuWsE+PnSwQAVE+V3elE7 s2mUm37/2CSwVkDUugIVrsFrw8ATwDTgAogz466jK2muLsYhUOsMyQIT1//4 ipASjbUD5axJ+9RSDckDbTJuLNOgZ8QIPRv0esUAWjozDESWOdmAIACDw4qa 8VVh4tGTBxpkI9nUAIEIFY6uaaW0jM42CdK2+pfWgLUInRxgM0NgQoUKwNIw JSiLVLGsDuTCo5oNwAShZRLM63hg3kRf3tyQjNzInsK1Md1FhOiXliyILffS pVVYsysHpStEi0iZ5LGkDBOaucsLLpuzbhJgNsMwWG/F9NwWQEy35GiUBgCQ HnosucRWxJ1TXjj8qLWyZ+zetrxG97XMEfx+THBaVkQHAEUvJZ2cFikGr7yt jCibZ3iT1c/4qpmm1fZDvOzGE1FejefKJ2DhlZ7/ceshp1wB78XnnDsTWHdf cdE5xx8a/q2BG1oCCnffScG44o0wbeE3nEnsPRhhc7440EBE0flCHHUZXvdG YP89EuB3vBFIoneoJTUNGljlE02L7hkAH4wFoNdbccPh0wqQs4WVW0M9WvJj fW+Jh9w2HlG2lEfdfOVgSE5KuFJS81wInDtAtfJYcG1A1uUpvADQADJ09SRM NbaUUY0sf15EaFC2EPqeoOf0tFVPfjWQ15lAHckAXMJ8pSVaE1xYGYDmqGJN oQNOQ9MbNubEXamSUNfQNG9J9MZX6LlKKqyprNNOR2beE9GGhbzKa6zRTLMJ RICq0Qt79ex6rDlkOgDV/znSzIMaLtJO68yzByLoSgXXRuujt7wSY6ksDoll rpfoxrvHh/LWGwe99ua7JzMGXCHGvwAHLPDABBdssMBm/aEAAgw37PDDEEcs 8cQUV2zxxRhPDIEBZykAxMcgv7BxxyGXbLIJIyt88sompwygxyzHDITLPsIs 88070OylzTj3bIPOfPLs89AxAM2v0EQnzYLR4RiAtNJQn8C0Rk5HbXUKU9vx 9NVWZ10112CL4PXWYSc9dtlgn82CAGyzDUTbbcMAt9shq62CAAPknbcAL+i9 twp+/+1C4APwnQLhiBuONccqp4A34YqzEHjkJTweuAuW+w044okvTjIKmftN +f/meo8+Quh5Y4446ZxPjoLdJbReeN+iH9655LefIHvuJMAuAuquD177CcCn vkLxA9guetucS834y5XvPrvwpYPe+trXo0B49Jej/HzNJEgveAvBmzD58Mrz Hn73JIQ+ut3Il4979bqLzr729mtev/7tyy/29ztb3/IgRzv6cW9vobvbAPkX u/v9zn8BgJ3lDIc60+HPgAL8GwRH4LoNbu+A4xuB7+j2wA1eMIQc1N8H92e8 FWbQeKdzoQgBGLTjEZB6KAxAAnXowBjqb4cNXB7bmue9zznuhuRDXwrp5z4W Tq+JQRTf9ErgOxNUsIA5LJ8MRaBFJXJRilOkIg2PZkP/EzqRckAMwBbTuEUw WjCCY2wa2UroRdaFUY1KhOISQ6jHL+7ujf8zovXMaD4vgvGOh6Tc9pD4ujhS bY48JGQUwxi/1fkQjJNMHh7r2DtHaq2MnDxhGA85PlKOsnuoU0EVQZjD9J0y kXuUYuRWyEgxCpJ4tbSj4tw3tyGicnK9TGUsNelHDHbylpsUHyCTOcUt0rGF PSwmDJlJzEgy8JiNe+EfV9BFY15Sg6HUowxzCUdkwlKXz7yjNvuYyWGyspoz NKcbuTk8Zw7TntIkZhu3WMVzutJw+LSm+lgJ0B5eEZvQy6TsANlEdr4zlOnU pDOFGc9s+iCgaCuiRXng0Ix6/26jOqCoR5fmya9xlJwjdR4ycdDRlDqPDgnt geVcKrJ+gTSky6RpJw1wU53GbGM8jalPcQbUng71ZEUV6lF/WgajLrVuTVXq U5EaVfBNlalBtepVV5ZUrW61ZVUN4FepmlWxjrVkXTXrWUGW1hquFapl5RME MkbXutr1rnjVWFj5pK++ssFYfvUrYAOrr8ES1l6GPay8uIMPd1FkIKmIBnZg ZY8HuQImBjCGGWgxAUNx4zQpIYkDyhCjVJ3kHZxAFGUq4g7UoAklHbFWGVwx 2wI4iV2iSMaVLptZLvV2Irl4Eq1wYoDPZgM+tDUALaYBAAeIhU1XEgY3ohGl p8gnSv8HoEVXlisN5z6lFaKYRnVdZIDk0tY1nbiGMKDzlGxcyb3I2Su/nEPc M7jjuudN7liQ8w7yRKBA9ZXOOUhzEjXoCcCkpYd5bXuTMrTCG3Y6w5VwEmH5 Ns05x0hJlLhkDAghVyuOhQx85iFenDR4KsGxxihqEQz9BOfEKi6vbWWMYOd0 tsIOvgaEcJyLBPxqWzfhBnlCgZzdNgdJsxpOkr1xWnoc2BcUphNlDozeOAlj wTUu8G5n/ODh8HhXm/gshG6i4uHs5xyGuS8a/Lufa0RYtO0VMH3RvJjgUDm2 8MDyibVs5sjYyRNfPheL0tQNX3zkwIaaR4DLoGjbzmMeZwrY8JNXhBRFJzgy N1lJMvTsW9H+VsIoiVF84zpfDhW6G8gtwFCCBeU0GLqzhibuiS9dBm6w2rd3 jnJXOE3cU33aDHby8UfMkAtOMJcoerI0ZLbBXGipqCmGxvR4jy2KtXjFWjOJ b67bxN8Z59daYertn57yaUMDl1SWjRIpYqynTIv5yGs2Ebfh0eRTnwYxzZUy iqVN3Fab97+nhcsttmzbCCP33IJ2EmTjIFlVNJwPMU5EYhUbkFg4lg8Tp7gc Lg6IjGucVx7/eKnIIPK+vvXkKE+5yle+gxAAACH5BAUKABYALAsANQBpACIA AAXgoCWOZGmeaGoFgaq2I+zOdG2rwl3mNp/6L6DuJhsJU0XRkbQcOp9QZ7MX HU5n11O2yi0ljbOv8scs77roNBlM26rZUrML6H4/hXULHkWv9e1hUGImf1SA WiSDfIl+codvhW2OcHqPanmEhkoyR5iXUJ6UlmqDW4qZo5CTc6tnqVV5SbGu a6+2mpWht1igtJW/u7U1nDpFkcHIvHC6yahxlJgC0tOE1Hetwk1Tx77Nu9ze J6er48vYzXl7jYiiwGPJzL3t4uEo5Uiu4M5o8fWj9/6QAQxIsGCzgQZtwehn MAQAIfkEBQoAFgAsCQAnAG8APgAABf9gII5kaY5Cqp5s674wq850Gsf0re98 Wf+CnqkmLBpPQOIxkFs6jcnZUvms7qKrY9PKxWGDUGl3/PqCi1uyeogNZ9dw 0td9jtvNwrQdju+J93dzfm+AcYJXhIV8bTBZf4qLUS5Eej6VclSNmWxmSS2H Mpcom5OkmJ0/oaBIokypXqajqKadmo+Wr2VAn7OkqLY2vLmlw7hSv7LIwonJ safFz8HNub2isZK6u6rMjK7Vt97MIjmt49ic3OeU1dF10eHuxjbWld3e07Xm 4vD60qyO4Pr5E6inzjeAAZs4U3hpkz15qdr42kLvT8M0q/DVywjvTMU3Fw/+ O9eO1iOThCb/fhvpaZu2ae3Q+VPJDl3HgRAL6kx3a+NKYwRx5sTZa2hLmPme BY0n82RRjSQ7Lk0o7SUxjE+nHiUIlehMaCxTZr0JisrDexpvDIuojlywtRS3 drUa1uPHt3cNxqVLlmNMri6DLNwLkm/fsxCbXZ0XECbgvqwOO3M82e9jJWcZ Kwv8uG45swzlHmQac7JWYHiPlZ2l1jSkkkIluw76ujXYzrMN1za6jGm507t7 N+Y3EvXv13KBboPVL3jgffqyDYq9Ozkb6TyGI7duyVZ26Ntvd8euQ7si7tfJ w6J+Hv34q+XBtxefHr5t0pDc1+993znw+Nmwp5R/+kW22Hr4AVLgIT/CJdic cwuq8hwwEOrWHy6yHFidhfFVZRF05kVCnwshAAAh+QQFCgAWACwJACcAbwA+ AAAF/6AljmRpnqKArmzrvrClxug82nSut/ju/8CgMNbrDY88pHJ5NC6dzKgP qqNKrysrS4uNcrndMBJswpHF6LR6nWS7d+f3FBuXw+qogF5mpwMDFnt/LICA IoYviIeEJIVDios3iYEtiII7kCWZNE57mzmOeT+Ohp+HpaGmkpqeI5Bal6at lKqulK6yoi49m5l4NLUmgrm0hZeTi3rHJAJUip+pyyvKxi6kwXmlOZ2WotUx ltSMp0fYzJq41uiV5LYn4T7Pc42R3sDdtNPp58Ap87fQboF6pypWCSs4EP1a 5amXu2vWtLlbFwrIlzbt6GXcJyzZu48S6xHhtBBex48b2f/RMzdkYSVptuTl W1cFhiInsGgeM4hu1qmQMQOxRFhDx7JUwpR1BBrRGMssQl89Eik0KMqoOykW E7KJ6NV8FXfKlInrqEeBRfnxQTvy5M9xkLAFZFqT3FNdPdlO3KtR2zNScFZt DZLJKdaseZViFckTo7+y0O5qrPr1od6UE2EuqRhP80rL7PBRpuJysphqntHi C0X64GMsJrMlA6wvZOy2ZDj3o8qqV0GO8EqrkywZ4Ki3l1l18dXnROs3wr1s K9Psl2LBzXe9KOKaUfE10cuolZ39XxAuSsNL/wEmjvo0XttzKt9kO3bH5V3W OfM+zMX59AVYXx/P3dEWgAK+ZqApEv3lV9cW9DVYoIIJdleheAn+4pWFzl14 X0s3NOPhgYGFyJ19H47IQggAIfkEBXgAFgAsCQApAG8AOwAABf9gII5kaQZC qqZn675w7K40Lb+1cO98X+Y5HykoLBpPQKJQeWwak7ZlzUl9QlXFaXXbu6oG izApvBiMBOQAOMwiL8biLVlHWr9bZDPczaYNCoBngAUSIwuAEgJ/gHQSg3oB g1yOBZAilJUniwUPJZiDBREDNI8imxEjD4APipKXg50irlWUlgKgdyWqg3Sv oIOiWJR3h7wiDoALrYG+jLLMtICWxREFDifV1QW5AbUpC9rKbavN2yi8ywUj n7GzOGGWJ7UkjhHzdavk69Iqu4ksi65FwqUGUYpN+wg5c9diADJzL+6d41SM W4Bdi1AlHPXNIItbjBb5C1CMVbqEFQf/qntRLBkMiRUXFSKRrZu0jQfDYQnw EEwyScMOzqqVDeTKFrsGWTQh0ZsxU+RKJpwg4WEojnR2hZFWq6dQaLUqUmLp YCtEF/dAahyWymXGhL8iiGNBchUlNNIAOfgylB+isTNEpIx4sy6hAQN2xQoQ DnEpmwo9roBKCNm1YpRMnvRlZtdDGYPRFv70S8emXxDDKo3CGFSngMn4gr15 +ihLl4QzGUVtriVqgd4oRWCdFKI2fl+P3rNq20XoFvMwI0asmGey6ZvMeBOg TXMv33owDZddgMU93zDCUJKgzIW2zrgpVwKkESVkji054jOGV3I6FRId9xJq 8ZDwiFG9PGON/z6GIHKfCg/9U8Ig1yQ3138pwMQQUwS6wEsxApHgWXzyCbBd Ou3VMd0KK3pBFxclgAijFy24eAWMYzy2BY0m2MgjjqrIheONPf74I4wpzghF kVpMNkQSOEb5JJQ/aIHCTlUyIeWORJ7B2pVYZmnlllV06WWYYL7I5JdkOmFm mmrCiUMNC0jAHh18JIhGGWrwwUYcatTzwFI3vMmmnHPm9IsZcUEilW+ILCIY IsgMJwWVZyaYqQwQcqJDHNIM4MhMF9GHgmPbTMcMMncgdikQYmoqgpMwdFSe psxIKosDjkBSmK4MZrHklLLOiuYMh0ho4EqHCPTHoJyM8CszlDjwQP+BhWK6 KRLH1jgqGnayp9JjqpRhjbSZFLSSQ675YGi3xsZJWCItvaHXVSNUY26609oG xntdDLttFLTGoMo/JprDCKvyKfWMHroOQSKn2sarw5EwLMKRI/aqs4gOB4eh ikD9miLIWRRXDCfGMIwcBsPUEtKaHiDpUPItZS1gWbEzqLzym7UWJwGj6+YV ok0dQxxIYqAkwgPQP0Nd40GjbIkYz4nCuqaNTxfcZrY+rxyrvFlj/fXUYa9Q 552zPlDNBNcKBugcxILLNkl89JnHCHbwqbch7bGBtx5z+LEAK2vgfYeioIxS D1sq0dHTlAMcd9Mvl/0yE6SdJIsu0dqZs8j/hR1NgPRANAuADCt4G6ZCe0a9 YZQtKaz+6R3XuXrItSnt7lMlnj+M+umOeMdXIYe80eusxWja/GSbdO6wl82b UNikd3BcV/bbBD/8TRwfMl4NfyBvzvIoeM/3IHcKZVmpDFMvs/UUBc4JYhFY mjwK+np/eSbFqwZW/CCz/aEvYcgL1xt8E4zkIQMk+/PSqEiiwHFlAlLE0Fxd SPW/0FUDYeSLlgHThUDDQARcBkmeKg5WvidNsF4DKUPVkhUGAdblIazzXybA tw19wUp0FzyKAA62D4vsAi/m0lcLvUTEVyQtRxk031b0N7/vAbB7VwmCuERl hjrtpxHbeNHIEqaMq0f8IUSyAeMTG3QHIo5QejMBCeiQJoAJEEILVVPDrGzh Mp1tY4WHi83yHEEyIfbDGi9TGCHC5RNesWV/GpOJHzXCQ2WMzklnrEsntGcs oYHBKnJJgR27GK2BZKo/kbIg8EAhpO2JwI3HcYAeKpmhLPaihSOEBIvyuMcB ki1Wp+LlFq6GNq2Zgg40i4fXTgmvU56tmFoCW7HCZrFffk1qKVMTNg/1zKhZ 8wUhAAAh+QQFMgAWACwKAEcAbAAaAAAF3WAgjGRgmuR4rmeasnAsz3TNujj6 3vuMC7agcBj77XorpC9HbDqLRpVIqZPWfs9sNiqlVoFBpnYs5LZKUOtVTG6n jWfwe8h227/YKv5Ld93/eH5xU2Z9aIBuXHKEimo2dYhbUTyNjmtekUSKlJWL l4eZT5tJnZY0gqFOo6SgjK2fnqllhayxrrZLr7KwkIwyqGGYu7+Tabmmx7jD MKuUp7rJy8FwxMquhsjScdTG0bPQ2oHChJ/Y1tK01bDf2ejp3d684W+9zs/g te3D79XKeff6dvHrlywgsHnNaIQAACH5BAV4ABYALAcATgByACsAAAX/oCWO 5GKey2At0lOm4gDLS2wKAroIYq6vMItPqOP5irqaTwVkkp5QUmFKLdQcU+fU IVpYVwWJCOsaVAsRlbnqknwta/jZIVifBXN5wWVxO6OAIwMDDwUTg3IRbxZU NV6OYRaFdHISg25lWYM8bjV6lYNYO5d7iFMpiHYqfoGtJZFde7CMilyPYJZZ MbBemQVPnbu/ZmK4I8EiuoJoe30Ff66AXsUWE89TPIxhVrfT1p5yDiYRaXon IshxxEKYx4tTDzdyE4oDrNGt07sRzp5ZBeK+eFH0axkbHnamoHuj7kyEbP1G nFETptCDe/ik8QpDCJZCMgLDuKFGjJSYNYOY/6RTaMaBIgkQIyazsgnUFIwZ oeirdqYAD4VeROFCuavYmjoKSawcxlHZQnBOK0kC+CynxpOnTAhNiiWkmEIP pYLxGUcpQ5aRgpqFWnUZ1qhWR+jbCcZFUi9eRSjKFEGCm0hr/Pod++DBXqkC FIFDpk2wpXVT28Z9JeabQTwFLSg2NjbFmQcIe8aiAlPswGyMew6CRXSy69dx a8KeTbu27du4c+vezbu379/AgwsfTry48ePIkytfzry58+fQo0ufTr269evY s2vfzr279+gGwlsNb0A4+efk01s4L4J9evbtDSQAACCB+PUMLDRoQOD9/AYW EJBAewwAsF9/5M13wP8B/NnnXnnrlffefRNGCOGE6lko4YPvPWEAA2gwcB4B ipBTwAH2BVgBGiKgGGCJiqD4oTUmBtghhRtWqON5FXrI448QAvJhARU4+CEW AMxYAIAMVCBCAgzwJx8/AFjAgDUAAjhBfhYkGd+G8Vn4pZgjqIdhkBpqiGEU QxZJXpUTOEgAiwCceGF4cJI3Z5wAHsCAkWPiSCaQJJy5pqHi9VgoiG6Gl6WD XEa5pHwMVGrAAZOGxygByUwAoJE/hsmhml/eiOihihJIpIMDdhkhiL9gmiQA E0zgJ6YWMkCOgA2sOIWMD4qKY47DdljmqfCl+UR+Ra6XAID1aToFAQ1MSoDM NQFiCqC0FfSXAAEA4JpksBEOmuh9pWZ4LLI+oikCswPiuaScaMw3qZUTWFnt Ae3N6YCI4iXA75jlljtqssiiSuyay1rQbHgkRoAgpgeUB5CICVhDAIgRALyv lSK2qF+agp6pZo4nm4oyolFwWYEDDsyKxgH5diwfgBUsOK0BVUZAM5GV0mOr NRVwGarBPe5ILMEZJfuEwLXWWuW3B7zcAJcWUP3yAQJmTUDVDlyddbiKVCB2 IE5312oUCaxNQttQtO02m2l/R5y7s4UAACH5BAUyABYALBEATgBdAAwAAAVZ oCAGgTiSaKqapuq+cCzPJWvbdIrnfJ/fwFbv5isadUGgj3hs8pLJ4c5JjUGD S1Z164qSlFIhd+z9Tn/aMRe6Sj/daiobKUbX48dr9z47441zbXxWcH9ZUSEA IfkEBXgAFgAsCgBKAGwALgAABf+gJYrCMAhjqq5s675wLM+LU9yFs6DiIP2D 1E8STA0ek5tkp1oMhwvm6Pl7LIq9YdH3WwiBK+fNsUw9cOjbFoe1sFOL9C3i HcXlhQgWf3vwBm8WgDg8bmpwEXhEFnd5VhJKI4MFbYGMOBE/aFiNcnoifH09 gZMFdYaUdmgTEjZ5QUmvkn6SlqhFAokFEiO5Y6o3wAUPoDd1ApCHk2uYPJa6 E1g+RTi8LsspgY1t2yKNQnPFprXGgqRpddq2KphtKtgjgcnW2aKXwVM44qeT XvCDrhyIKxJrwotkY6ys6GfCRCAcxFS4svYtX4595Mb9U3Jm3EN7LUphOmUu VKp+KxD/etO30h6OYwhRbDQW6Q1KQQ0betOVJmLJUEFugsPXKU0EZ6HqzCxg wZUPZS9FdKwG5wHPQz+tROkm1CLTe5728PG59N6DZEGjgo20EGFEeAMtCFCb YmLLXVWkiCPTpU3ZuXnQ/jwWxS4LwLtGYY3blG29YXdf0F14Dt9UrLp8ipjn AqLiVPGwdozwTm3FFpNLY530WXS4obysFAKr1FblcRaPRu5cLuRtr6C7zpu0 RMyYP7YXN9KK8NRpFqmN/L4L2sLUJQMW6JJwOY0DacmrIxsLhyXq3izKjuDZ BqEcYgusotExG+6tJq7GuHu+InpGZl/dtV9+fZAklwmzzXAN/4IKNuigDCWY 8OCEFFZo4YUYZqjhhhx26OGHIIYo4ogklmjiiSimqOKKLLbo4oswxijjjDTW aOONOOao444ZAuCjjwyI4CMBFgAgggEWEAAAkQYYwMCQCRTpo5RTJgDAAQcA kACSSgLQ5JNedvkjkVZiCUCQJhpF5AEFGHmACFEC0GaTcjKVBwFs2snUma64 YQEDBtRJgAEEFHBAoGkQkEAsOBBZ4g0E4FmAQWy66YaRcnopZwRLAjBBlEpC SgADbDZgQAJsHlrnoYWqWkADkSoqpwMMWGlkml8VylSlFrwZQQRWMpUApBY0 iWSTuorAwA2A/snspkm2WmSbKbBpkP+K+MzaK7VvJuFjm8kWayyyN9BZLpKG fEtpq4jCOuq0k56JohxrcjutA5nW+SeWWZJbgLkTNFnMtwDY4CaiOBi5KBoN nDjGnSLw+qakleq7bMT+mvsvujcQLGeqSOYw5AgENKDLrSTekIDBEdsbaQ5M hYvooYSeq6vAyxYQqpYR2FDsxy2sbCiuSTK7raWDxqLlpT8bmnGTiQyKaASI ahrMzCmgKUISDT/6VapH95okwlZzeqXTNW88tY+JWO1lzq5GwG/BETRwdgFa j4hPzpK6qXOTBtPJkwNMGjJunXl4iai4DTiNeMcm40A4j0cy8K4KAqcQaeYp GAuD5XlPGAIAIfkEBTIAFgAsCgBKAGwAEwAABamgIIpBaQajcK5nOrJwLM90 7N5lar816vbAoNB3I+V4LF2vOGw6TUUlUSat4Z7YYBTJ+xFVwGt2PNuCjyqz MVwlu6HmlrpNE7/fcfl8vfTe3Wore3RUfn9jgXqDQoaHT4mKZ2iEhUiOj3mK MHZWlJd9W5uWkYyen3WhopKCpkmtp6pRO6usfJ2jsLdMs2WvcLi5lbK8wrTF wWzDxMJavsGZy7O2x8i9qTIhACH5BAV4ABYALBcASABSADAAAAX/4CKN0hCc qEgKLEtKCyqro/zG8klL8+svptyiQCwEbcVCi5Xk5QKSpKz5hEpR0aS24DgG hkXvKUtcCqhPcmFadObUyO32CCaKrUUz+n097eNEgHJFEQI6SXdqem1VcCh/ WH14dgOVD1oxAnVGaVJLkGOSoJNrkUVCVJqInaefjKyBj698p6axKGeem4lX LaOOfrOCwzlaLLuwpb7CtqXBRG7EobUoA0kOx00+EhG9TMzTtwG/ksAnl0UP 2YNyJ8vQjaLgpIIL9gsOWgPr7Fq4ufCSsQlIS5wadur49aP2jaC0cfPMHZQj YckmIJUyAmtYIFqzgR3jUSO15cECM8gK/zrj6DGcM4gOPzYboCaTxVUq/5Eb udOglAHdwqDEKY2lSHE9XzrahO1mGIHuABaIUCUfT0JVy/WxSiShQl4MBQS1 k0MqVRRjOckwK80aohYpiwpQUwIXXRnooB2Z+0diE7hEZQZQCG3EFhyHtJA4 /NBtkZOqnuYc3GIixWTsPJoTkHfqV6hmLP99wrdfxcmUxSY5ucsQMTNfuDZB XAUfRdoynQo147rKvxa4Btzb55u0cHvEi5flvSQ1bOXPlUufDp05cOfNi/Om zr17VOu9wWvP7r18detrWXzvvZy8+ffp0ctAQL++/fv48+vfz7+/f/sGBCjg gAQWaOCBCCao4P+CDDbo4IMQRijhhBRWaOGFGGao4YYcdujhhxkSQEACHjIw 1YDdMEAgAQcQcYCKBgDAhYBJRABAgAAcoCMABAgIwFgvdphPjwYQUMAEK04F AAATkGiAVTASsWQ+N7Y4QYsF3GiijQQ0cICHMjYQYANZEtgNkQKaOEGZBhAR oJFfttijkREkIOOXIBqwZYApDmgkkgTKKCOgbsZYQJwFEDmkjFzmOSScgR5a YD5PFqCii1j2KGeALQKQwFgOoMmhoGRWqSMDdxJo4peltknIjQZsGmuZqHIF I4dqdkOiji+mOqCMSSBJBANncpqosbC+2U2yHK4pqapEOBkglUum6KZGjA4Y 26OJlhLY6YfAMiuglSI2oOa4WRZK5awNALBujjwyeiuu0RpoJyHL+nhooXQm gOWRsP5YhAPz5nlgAiJuyAABBTMYAgAh+QQFMgAWACwJAC8AbQAyAAAF/2Ag jmRZCmhqrmzrvjCbznRs0oKt7/yL1z1gb0jU/WZBYXHJPB1RSVVzOn1CeUqq NnrEZrfgmDW3+4bPrbFXim6nrWWke75SG+X0/Ah+Z+vzfDBPf3R2LmN+hFuG dYh4ilqMTo5mkESSe5Q/llWBJJqDnEuYoJ6ia12fiJmmpzaMqY8Bra6Cnpsi srmptWKGOKqJrMC9tqG7iZWzuMWHgcTDZDLMzY3HX8rIutXR0NvbN9Dc3UJm 4JPnxb/C2q/Zvbfsy1fG6a7r9OH5Pu+n+GRA7AWTB+/YvByr+uxrBgtUHIGW TJV6SFCUpFLS6i2sdXGiwowFDWrbR00jN1Lf+lYNBHmPViWV0arROvimor6N nDC1q8nSmU1CM2ny7Dntpx6dO4vitLZUUVChPD+GLHmTn9GDRIE+RWa1aTeO Iot2zbqSLKCwSod6xdqSVz21Ztla3DoiBAA7 ------=_NextPart_000_006E_01C0CCDA.AD2CB8E0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Id: <006401c0ccc9$e98b7ee0$01fea8c0@jctubiermont.brutele.be> R0lGODlhgACAALMNALdLTOzBuq9tmfKPaOxeJZVSfoU1aoU2aoU2a+xfJoY2 a+xeJv///////wAAAAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFZAANACwA AAAAgACAAAAE/1DJSau9OOvNu/9gKI5kaZ5oqq5s677kIs90bd94ru987/+Y WSI3lBVrBOHROEw4ibolsyZ9OqtUW1FaC2aNt21SRnguxuUrzbouC89fJc68 eI6Zy+273rwvvEduQwR+TW9FhFqDYEdNS4lgPYE0Y2xieXWZZGwzXniHdHwJ gjqFmqCnmoiCjYh8M26Zeq88oTJBiJyGh3Kisr67N0mNcJlJfpuwxjuWsGzD sU+eg3SOxJGi1mSfwa/Retq0a6mnowMDAQzqDAED1W/DR153W6NZ9nWJo9fi 43RlkOzZO8boFb8rhBKgWxegYTp17RJS2ncHUKtfyeRYcTJM2D4owf/UGGSE 71QaJwMgusOzkMFKYKkAUYKXzwayKUIqFcPYh4u/MJEUnjuXrl29NSnZ0Zt0 6wKtk/eUnHMUjdY1nTiZTYUVy0jLdeoGUDm6UKygjp2cEqQytO3UogPQFBSD 9ByedmJ5zkjZbk+lh3gfshN7hW6dpHn3ZJo2MwHYx+fUcUH2LmmAWIj7CXlI WAvcTOkiu/wl8jA7fGibWpgCSYZDhg0TPFSohlXiRQssCyGqjXamzL5Ms4vI d0hSNSVjhQ5e0akhtIVnXwHM2SvgzkUsD0RH3OFn2WEXONzyePhoGXy3YUM/ 2tYQmXPA9x0iGCxKiNVp6G6CWGH50cf1d5//S0SptI9jDFA2ETsz0QAfL3XM BlpY4LmEYABOFGVHbhAVk1l/1XGmIR/FGTEiH8t9tNMQ6pxhiDxOLbOKi5+5 JhmHFsK2Dh26kYEYAZkhKFZSKm3GQGH+Yahfe1jYWJMNnmCDT0tqVNfff315 BVEaOA4pmX+j1adkE8vBUZwZKcWVUQ3p+KRaBfG5KF9iEl7J4CgAbWEZlx+G JySYgDlS1Ekn2qhmKla0qIyDMbK2S4X4WEkhXO4YdYRlQ4HpznFdiicZZxxh 2lKWZ3x5kRCnuYmLJmeZONiER3YJJljuGEIkQ322Fx6IYQ1Tn3lxGWehNgCx dxtOQRT7ohXcOdJs/4QR5eadXRt511ClRjWbYbaxKXQtfyp5iSGY9ZhBXqx5 FGHRSOZiIhJlSIakiC/xwORThq8aChxJYJTYzXvOcWXSWOotY8yGSkhxRyXL PjIOJdd9RSrBOB4lRZSoPJzVxmB0FYeUtmixzXNf0ZrTIUD2ukOUpZHWhkA/ TWEHUxsXklBqSMCBklsQnTqgmrN00SgejpCzRknuBV1SVoE8erQkWoZVK0qC HfrkLKuy5swODMciV8hAIbE0UFze5Ox/67hzTLlF/zG0zGsxjAlOKj4tC3J3 K/aF0xSLwt205oa92NB9UMGwRnPY20veLzfInMia+WWGglW9ScF6/2jMj/9J L6pXtJvk6AJU4GC3nFwxCamrFimQz80HZayThlscCrOayxlfcxKPK4+6YhCM q/0g/PDEF2+8D7gAoPzyzDfv/PPQRy/99NRXb730aQUPwAEHKHAAAgYgcIAB ChjAvQLiS/A9+N0bYD4C3pP/Pvnovy8B/POb/z335O9fPgLiY9/4ANi/+vWP e+ArX/gkID8Eru986AMgAL0HvuzBSQYEBN/7uhfB7+mvfBQMn/gGOD4OmpCA 3lOfBz9oPhE6cH0EXKAHBchADZ5vfeaLYALdxz0YMnCFFrxcArYXvhyqL4Aa BGD32hc/8MEPgfnDnwcp6D0mdg9+8EOfAts3vvj/gbCH5HPi/f7HvgwOsH9Y dCIHeaiAIE6gDgBQYhrdFz4cHjCB5bvi/UY4AfqFsIsRXOAH+1g/DaqviOKr YwPrSED+nc997EOjE9WYR/S5UQIzoGQVOyhBMIZxgiMMZQ7lh0UI7k+E7stj EcdXxComEIUBVOATFfg/Vp6Pj7PUnwmpeMk2DtGJYZQhMNOYyEnG0pGStB8L pzjGJZ4xi/tboh+/CEn8hZGJNnSkBDt4SAkOTntZJGUPnxjN9KHPfxTMoBEb eUsxstGV6eNgKbk4wB+m8Ip1PGMJF0jJCXpxn2203Btl8L0U0pGLSExhAQQg gIU6tAClLCIjmznOVoay/4sIlKIPXUi/avpQj1pkZQYpWEISIrCXMgBAAWfI 0nMqYKEMjWlMCwDFZ45Ql4nEJx8L8NKe8rQAdHxiUK2ZQg3QsYVnzAD/fOm2 1QwRndBEKPlgKlOZ0rR9kAxpCaXIzSxStaoCoIA0PQjGA3y1qhAtqgQBeNaY VtEA37zgAoQ5TS1KAKxgpen/cpjED64QmBPA60z9+b8fFvSlgm1oOmdYvrYy VI8oXQARJ4nG8zk2r2vdX/qumU8sFlUBiWXoORWpwBZONbS15CP3HAtU/EV2 e0zk4TYvm1ce2k+Jow2gMrVIW9HOUI5I/F5vw3pRAl4WgpFdAALVGr7hovV9 uP985DvXuM3QMhSo9VsfFRM4XFfmEXysTR8CUPpUKIoQsdZ97g3dmcJ4HtSQ 6RUAFulXUDMOl6YJPOVlZxlXIcbRk92Lb17be78HTiC2MUSvdUlK1gOLL76q zChrCwpXgDlVuRQ2gHMFi18S3u+TIc2qFgUMVFa68oqrTW9as4i+y9KSvHGk 5YY5nF0jYhSr8kwlaAVcVKSOEgEb9iL7WBvC1+JvxoltrRRTqV1AjrCLSK6f Qf3Z3PhCFH8pFCwg+zvQBTgRyRzeZmZreE4uMhCvl8XuA20IXh7TF8hofiuX MSlZ7Qo4yQbO7wRlS9kA55XIMQxmQWd85f0dt6AwFiT/bXlq3atWtI5U/KgE iCzYE5v3tG6u7oDDOOeAermHO0ar+nqr5DVSmI81nGClQ/1c9qkwfUhO6/hc 3EUjm/OrPHV1o6vYPnbW0rzwq/QBOFxPZ8qPw5XW34QD+FoI3rWh1awiqQtr alYaUZiAdvEmu5hK1oa5oMmmc1PlqsIKKLKIjVYiIyF5zVOyj8OYzusUHQg/ xyq4qvED9Peavclj9vrZeMayeHdYRiOGm9VW5XZOJx1nGptVyxPs9BniqNtX BrfFoaXpeUOZU0ciUNvhS2yNx/lwebuYfBAvX3IjqMU77tkA6UZiThMZyCeH GZIunqQ9WavhZAMafs3WrBwl/8pKUi+3pLcMJm6JzcE0gzqcMEfz+ESO8Jjy r8LjvpxkEQlJZ94TAem+Z1L1J0fhJpuOVXerOf0Z3p7jFeBV5a9AxT32Hcov jLsu4N3vjseQx1ngVC8tD3kOd6umnacMlLhkAynlRt4643YFYePVGmw0b9N8 aZbyGMPL8Lc7doFMTR4tRXzxqCdZlbhVX3uLmPkKZN7ZlR8wCJE94AEmt4fy BDUI3Wd0lyJyq1pk651Rq24Ptr3Nf8YrClFKgDjm0H+ehW/GPW5I4Icx7cMf bCLfR+T+xVqazea6Zj/ZPaPfNJoY/SCYIe/1e8/0isiPbws97QkJolKFXs87 ipU4zv8yrh+1vRZvhndIhEZ2/CZDJBd8bvdtjgdd+eRn2Xd6xVRyokZzppde Wpd1XdZRGeVPELRrLIZMjCQ+/wd59OV+13VEvGdlffRaHLVx+CNBu/ZHp7RY CxiBqwZ6RHZIUwdhiDZ3vvRfJjYBP9VT2DdTRYh4qPRkRzhpPvWESRZLKKhY XYdxjQZDt1dORxiBLlVMcCZ1IThfZvd3FERkGQVu6bVUr6VDCYSDlaZBiPSF YPV1aiRHtKV6U6iEKDSFhvc+LmhLAuiGosVJ9BN4WeRZgER1YaRtj9RFGKhF K2dCECiIbtVAhsZ0UnZ19ZR5OaRvJrWFVDg+ihdjV8eHXEj/RtxHbDjVSfN3 h3nUfTrGQaCIWxI3RMHHQZSIb5BWiMLWhTdVWk1YQicHjLwIbyN0e/FDPyX4 dsN0g1V1VBMUW6B2euUXZ9DFa3KIVyVEf2qhUnuFcrlYiV3njDOFgAhVU+To VpOIb4F0XutYVQ4EYzGUReGodv0DjsyIYgB1WLN3dmaoe66WZp51e/HkekZY hE+YkEXYQJJHhEYIaUsUSS20h4iHkAx0kEaYTuzmbBiJeE9ka+0VSU9mRrVk QGe4hOckhUk0RjFoSIz0TPZTX7sHSt+1Z/WlW3yViZAIhBMnRdGIkw6ESF0Y koh4kRcJYlSERgW0WdeHUNUXPydU/3wYNU9HV0w/xHzKlUGRlJILl033uESy ZE8w9GNfGUISdUjuWGMS+WRBaWxv9l0M9Hs5lGibFFQ8ZG1nJEKI6JR7hHRn CEIxqFPbqEMbNEax+ICV5WOql1PzA5je02wiKU2ctVTbyD8Wl0sTEFz8lF0x pF07VG43SZUuN4L+A2rt5kPzxY3B42WN2YgCZEh7ZWDSNHlciXsG9EUs1pJ6 uUVExXEqyEkZtUE3pZdrBXQ8WWfmVWaFZVHuqGO+KVumJIsLx4YCBJZ7yFcb xFf2B0oPNEPzh3sHJYvJJWbd2YiWqWOFpVrzd423RGHctkHAlk4190T5dZYm hVRC5Z6dZf+d3GNktlVRlZQ/ejeVGcWZOkefXDlPBnWXE5WS2CQ/lnZ1LzmW SSSR5wNjekQ/9amhGkpz/bdHeMRV7CZIRLdK4AlplMVr8sSU2weagnaYWuk+ yXU9NFqjNnqjOBo9ydUPy/I7SyM3uaMTCsI2HWMK5aAZOsERV5MxfbMuqlAN uMElkLM4dsMFrsMJ60GlMgM6UwolhOM4wUE3c4OlRlOmXfoUYroLfiAReKI3 RmMGFtE2hQMSJHEUGJEDN6E5PNo7ZCAXzvAIWMERXJA1vmMExRIzxbMWBWM6 Wuo5NgETn8A6q/AREqGB4iYHJxEvQrERmpowyLEzckMNnFoYTDD/FaFQGKbK qURTD6bKMTLRCkTSFyVTK30SACTCEAPSM3VAIRxiq2JCq2AxJmkAJPVRKzsS IRRSIT2Tpw8yHfhhFHBRJ1uSHhXSEEeCGAsxLmWSHkVhrRiCrQ3hGYNRJmkz K2LBGWkiEsAjV0hxI7c6JhpCJElSMYtQFEYwKe3BrcMSFieCCcAhELhKJHGR IqR6MUMzrPa6BRoyIDgyGAyysJkQHsiKIRJbHKFBLtfRDTiCF25wKwRQNZ5C IJvDkzgzIr6SKjjSq6ERJhZCAxI7J6GRBPr6GtqKK68DLriqsi5RFAxyK1nS ppG1FIUiH9nRInzBF6dRKATwshqyrQ8b/6x5wR1powUSkzLe6rC26i2CIaWM 4lR5sLAnOyZJ0asI8rRKErFM0rT5arYLqye8KiehMhtHiyunYSb9cQO4QA3s EStacrbxmrQd0rb0kSp/UrGA6w69Yg0dMqpnYLE5IjWEe6/t4aWrSRKUAq3j SiHFsR/h8q0qoSEfy689c7GOWyBHsiFHuydqexlHGxpUYhiWGlAXoawWMqtl wBdl0LbFmjI2i6y4Ch5eYh60Egy3UrcXa6+I8asG0RwXBgo7w6mtmg0IcTet SgiZshSpSi8AYb1qow83u6lyIwqEML7PuxHI8jZ6KzCqMBLMMBk7wQ2Y0Co9 aqZHOjC10LVwMoi93qAxrFCm4fsciFK/7HIqoeMThWAFRmo7fkCoswMysmA2 HcGlbRAFEVw0WGGoykAPUVEKGMyTVrq+WgAvd2O+jzCye5AHeao3Gsu++VAv YKo6lZsnAmw3QQEHh1PD/NIIBOEGUloaijo5mEMMbYPBDQwDRnzESJzESrzE TNzETvzEUBzFJhABACH5BAUKAA0ALAkAJwBwAEAAAAT/sMlJq5UItcz1/WAo jpTmdVVGktymrnAsb25bIoo3T0qvNL6dcFjpAX8+4/E3xAElSqJUiEwmj9Lq dcqdIZfM6tD67ZpX1mUBPFZGz/CQ0a1lygrrNS/OB83JW31UBQqEhIIUPXkN i4RvJIsTa3ZEBxR6cJSJmpJHOiGREpGcQqGhMY2MIkymZTCnmGewloJveQJG nx+nqntdsarAkMHBwlCiFY4iwqa9U3qpO5jGF5SjpJ3EsbHY0snEqJ28e7Cu l8jOkeND08530O5+Fmu4P7rwvcDT3a/oyOvLzq37EW0SKXzt2pmBh89fQHDU JBiQkwNIs3zfHEpR+O9ONnCJ//Bow3IBobhs/EYUUiiS40OMER9t8nAxj76P z0BE1ImTFyttQeY5jBaPHUaCMIf5A7jSgoAnAh0qeHoOmcwV2+Lt5MlI5Elf 2gzugmKEKLeUoDB2/erH67aLT4TVm+coiEyFuWZkzaiR66SoPBiu7QbILI9A Sn0mHdEwbkZFH0iJuZoOiznGl4xtLWl18bGOjGRaSnLoJ8crlMc2dgtybN+E FvfKrFPlplVAmPcKlbQZ70c8SjYDCgPamV3EnFtXVU4X5wF1/wQfKvInJGBl tJWuTY7TtTuTy0NbOJ6oNbcnWnS6zEjUb4WJjSv7EcNzPdTUv713d605+tLp h2FTiP9Wn6XxmVD4cIIUQF/1V5l9Bc52HVToGZjWSLD0tVtRai0nTFCc6Ubd H7qMRGBxW0H4E1vGWFgBVdABCAaIF8IF0Us7FYSTi8mIOB4ZCKpl0l7UCDYe h/tVV02D4m3CY1XgwaZheA1MBKWJGgXlBk0bVgMkk0J2lyJb5Kj2I2p1YPnX iPTxlYpNbxbX5ZJY7hhFHgNux9YXYVgYY2BIGILUfldScxdzpNnIi6Hp8RUO Pla6SSdAZ5XVU1TSkYWYlKsQuaGhQY5D2lKeialpcKBtNqF3XgXYKneHyWem kRX2YKWPmE0pq5MExfmhD0PW2dAaE30JElrs6XnlpMkBgyrpkqlmY1AZzagq bY0f2SWKjiMWqmZ+M64IYX2gRYqOs2lKGuCg8V3bmLHjynPptteGG1e1TpLa EXTSiqUIv9ZK6mAvW9DIHHpF3CdJGQxTR+ExyEYG8ZEIn+oicQo+fCZJq6SL SMfpIReZwWxGTNzHaKDJMcj8ZKdSmyiPzMbKHdPMK8le4hzzugXHIHKsOidM 1s4X4ABk0DIT1id+DEfMB20/g6zx0KhRFHXMxz2ZssG4HZiCx0RbnIbTJf9A y9E280y2GcNdPYIHf/R5atpuhF3el/jZrffeKyRAgt8SLMB3A4BTUPgOEQAA IfkEBQoADQAsCQAnAHAAQAAABP+wyUmrrUXmy7v/ILeNWhl+Slqoyum+8NQq K61qbXyReu+LJt7ml2tkMoifUodIko5G0w+6rCp50eESa+2eqEeatMf1mj1F rPZ6boOgz3GIVqhnz7NGLuWm2NZrMUcCgVNGhHcvdYuMHnBUco5GdoeLXUd2 kF+EnAWIH56hiSGMnRqERVeAUYqMloV6d6GfBQagFJZZlD+2oY2ab52moIiU sDK6dZ1aqVOBwG+Zr7eVE8eTlYSDrlVDv6xf1riKkbiik1qzK1a5JdCOj5gd 0tpRthgakJna74LWmaPeiBPlqcMndzsw0drFsJkOeecCRtOVL1CLOHKEaPK2 i02Qadf/xknpCOTUM2zKRnT0xg4gvlYQ+Z2EiE2kyijFUoIzRLCiPFLiKnLa MRSUvpJRHMKgieFgNEwcSbpjiovW1Cz1uu2siC7kSAH/yhUay/Drtn6kHlnw OuGetA3FtjaIS0WpkCDiwJZQ6iguBqhsveXEGPTlBQMsBS/KCoWviEc5jHVy HNYYnJ3xwnHElhVfEqBY8QEWaHKcPLcTrFq4iGMrv4OX58iCpS7tz2oRp3Yu mQ4dv8LkQv/tGmte0MhvwyJcRwFB7Kq+RIl5LhCTw21OH9+uNoZtuYGVwYek 850VN0liIR49Vgazt8gPt5sTdk29jIhxcr8s8Hnt2ZlymdOe/3/tAKFfPjUV l6BxzWyDTiRo6bHMgiJVuANKY/lVQnbgwcPdSsARaA1d5kkT4EgGriJRiGvl lEWDd9jl4jQLsjSPiS3G5OBat5xDHYoE7ojQg/IZxt5JCF6IVC5hXAiLKTjq CE4hbv1o2mW0hSMeb/f4VFpNPUElgV0d8igBfRRaw4cfV8LRDGsBPrGeMVMG UuU7qP0yTIVYmkWRkjzCQWJify5pj5mpvTIWZnokBoYkqxCm5gqJ8WOXlQhC sudAaaQUm3pi8gCfLycGOgkiMErR5T9WnVfYbTtuVAxsSV1VqgV+ScWVrhbW JloOs/rok31AMuoCQO3Z2MCqjKqka+xmyCrkKxe9MelPQHemmVE2SH5p0kI0 NamGgC6wphOiB+Y3m2iVgYQZiewW+tBvz4hpZr0cBuHUtKEmAgi4/uiUQRoj qlhtdIhi6KVLWyqHbL5olCiXokrCBVW+leai10DW9rrQQ2AaO7G/NXaLKF9r EHxrH+iVh9SN13rHMl4DvkzasTOfACemNxsY3MA5gzZkCM5pKfPKQZO8wQFL aalZ0h2M6rJAKJsn9NFmwFcmyMat6GR/UNu0E2UtV3CAsh4gNnXSGm0hA8GS Vhz2vSaADcPOYrOIjAlk94ER1nMHLjgHC1CQAAiHD35GBAAh+QQFCgANACwJ ACcAcABAAAAE/7DJSaudpTR9u/9g6GnZRp5i2iBUoahwDCMazdoFu8kdx/HA 4CWj+Ll8uiAJ8xI6ec1NUbp8So41qzZ2mhqfvq0YSjxOd8LweA3KYHdVWZRN FxXPZjVvqTHUxUkWJRhSaClecIZWL3yKdlBXkVV+HwdDDQIcc3SbIY0anYSJ XyFzfHFbnzGhjhQGjZIwcT8SrKutQKoSlD2ZkbiCLRsCiWuqthW2tJdqy8kV VajIssBcoxOhYc1tjrpPm96lI9RUgU3L0b7YWqjPKd4uPZLEZ7vB6ITO7A2M 1RbKnj7VywfNxK91QQz0a8fPnghQxXbYykQMRa1uGGEJ4UVBwUKJ4v/kfYh2 sQFHkA35zUIz7SGVlP/ewalHIpvBg7VokSygLmIQZBpBAPRUEacwfaOKCrF0 7UPLa3gQtvCFVGFHlYSoKoK45SPSjqxoMiumzyMcnSTU6YHhlR/TknBHvhSG UFtPD+dEGiK1KNZXqYSixGHFUBSGMJn0DILpsmZBd3JROfOo7S+2EkQkfalJ K9A4xleDdgj1om0wNEjLcBvihprj0SpEX8BDUVPMKwNjaVaU24Ify6Ub2SJ9 8WNBPoFYrCXI+2A8mVwfu0YJkA+xS600aPVZ5IRlfyVlXwUtzPiV7T3MnsaZ l8rTRJ36QR4bvRPf1HPHGmbyRt53gn8Rd1T/dkbl85Z0xYBjCFA+0TXfPSjF dRNqe+hmVHD7rUOYc1DN5uGAOjWIlT88raWgCfGBSCFLF5wEIGh5lTiVXnIx l150FppyDyKwuURhNDbVKM1pRFRXiF80HieRTYv9lZmFGsk3wkCCQahkYRKO ltd1sh0xk5d0DYbdYoa9VlpDZ4a2YT/qQUOVdiy2cEcy+JRHYxNV3nYmhliS x40RDHG2FU6BEnkRkO8VxOSS8qAXF49IWoQkhzWm8IqIgK1GVnZ3oGBET/gJ gs9y5NDHT3WJjWejkj9GdF+bI75nHChJzEEYSavixhUsIYJmW4F9auonktno SAs43WWzHTynGSvD10qqCmmjPk82het60zango61BCKcodfaZJ+DTQ06J0GJ KrfXg6JiASmwo7agDXYmUbHZPhNw9C00ydq4SW9wYQaZH7wkq4+LIVDC0cL1 urhZdw89J9R//En8hydbWfyBum1QfJiUF09MaGylyhRyxBD/gPBsANMLwqVg njySwbjJ0vLHJXiWpMxEGuyxnF91GnNkPP85NBcaD1jIgYLckSgdPkAshNRg CUpmBUwFG3IY/aZxdBl4vKDzL0nzHI27aUR1r72fgVcHmGgXLffcWxAQg910 sxEBACH5BAUKAA0ALAkAJgBwAEEAAAT/sMlJq73l6s2755kUTuNnkk15rmyr FYZLIUVWy3hOKamd/j4dJaQSGle+pISnIzKPUA8tpcjwQtWoSMs1+bK/5rZL fhGBYeHoWW43wFeUS8F224fb4Px9qd+jIypEMSY8flqGfIkriY0gj4Vvi0VC hnSKLJaaOVWEHJZ8FYcyl410oxqOi30WJZSikksVVlGll6GRoLYHGHKznha6 t2tQt6a4H8KYLRnAoo6sxaWxqx2q1F47MMHTtrComZjd4N/Yt5B4zkzjeEvk uZLr08ni1IeUeu6bi37nOt7Lqn0Sx49FCV3xYo1Zd8SYQ3ceQCmSuCFfuXkC IepA8FAWxYgT/+Up/GADwYRVll7JqmSsnr8Nqgp0a9UrDUSKTM7U8njy1DJr CWe+bFcBGMAxs4i2QPgEIUho+4gWoTQsn0qbJmKwOxkyoi2G1Hh1oPqCZpir QBP2XAtSEi1lFU/YAHM1TjifyLy9U3hOIh0EBgKZrYm18NlM8vo5hRlUJLa4 GgILClZzLr2mqXgO/HkzEdq4U/UNAXPClOKOjGd6bOQqzavPx57IvJGsYCqw MDexMqTSH2nDXOfphG1v9yZnXOsFV0sYlkosj8d8vqlI7I5ruZWrvbfBJJpP iU9asfgN2u2R0XSXQ+phetdeaFte8i7BpFBUR6+jP9xWKfakwGli2v8peiFD 2TEHpkUCeZl9tMVv1tjGD4EDzbPeZnI9qJpZr+yjDErx9EPQbkidUYd7qxnI xxkqUMhGgRittMNEnCVnEDoEjSJTZvbQsSNUAjaIjTqDWcGGTuzNiFtZVDnG lItNKWCURoZY19yMo+34nU0ToiMSXilltNgz7xWVJBYnAtGaHF9BNkZgW9Gj UXpL0OdmjUmmRqN5ImDmIHhQcuPTfAAmKdBspcXGXB48WRihZod8aadSSiaF D1K6DYpLixPuRd1QBTZg5Zn6pKkkfuHR2Ccxjnqg1Z5Y9uVpcqb+yNlbDLWK hipDRZirfovigWR+K/Yk0UFrqYfVf/AsmSy9ekhyg8wgTpbH1LRUmLMHgb6N 6V2HLVHqkIi8KqRTeLMC62ycS0QLa4OqoekSnn71ChSCnx7Jn7x/MniXHCoQ ki4sJxkgMJ5bopgnfEgs/MedkWR448NjuQYcxGVdPBjFkOwo06z+ogDhbYhq yXFSdLEwasUyZpwCchwPl8NVQaCocBmTiTGpyx3DbIdsD95cKE1KDCQ0GeO5 K8NrVaQMTsgPC1aJVcuqFBgVR0NR8xtZn+z11xIkAPbYEkQAACH5BAV4AA0A LAkAJgBwAEEAAAT/sMlJq6VFgny7/2DYbVYGNJyormzrushLKXJte+kd5hKv /8DboZIxBI8fWm854fhYzokSSS11ntWsdnvBcpEpX8G4Ogy/aOKHQ1YhEIcp 8n0wDhFt1R1uhsdscg0GBQICAQIFNHcHhYUVb4WHiRIKjU2ODZWNjQV3BnmU CqKPBgd+QzSNf5mEmA2WHwIMs7QBDTFxtZSZsrSzARm9DAISAbM9vrQCCAp4 FpW/OW98zbfCxJTGDLavv02ZUsIB48em0N4SCAW15MMotTTayLXbBdMGq+ra 24Gmb5kGFOzjJmgfNnRdoklg1EnBkH3uDhTQFgabMAYZ5L0b5s+MKTMK/4xU ghhgVYM4b0r9gUjm3LZu7mZM0EbwIx0Dv37B6RUg0LxfBjSuG+bwlqlPNGIM 9QWMwlFBdWD24oAAIjGE6WbO6oSHWSleswxte6Nt2QWe9XrNA0YVjkMyEw/R rBDnKB+K6ARu+9ULGwpwEmh1alUo0QF58g6HRbGJ2FByYhn8HHcIahyoCgoE U/gInCljAXC+ZLytLNYK3qr6QhT0Zd8GFGF66wtaaDKOMeAYMUnTJBxw+Pqq xlhsW1+sKQ4INmCo9+PIJcuiaBdAYtihajcewlQqakgKPHMgzbST71xCYUEv prC7tWR86IcNTwasLDPNtKRO9LW2u9tq+OQxl/9T+AgSA0S6wOYaUxgYgY99 qehEE2XXYeUNdrJJph0fZtyi228T8FRBdyo9RhlFCMhS2UAzOKiOYHj0JSIx PA3n12yLKcCfEXxxEhIqpTDXDl9KFOjRazG8BhoxBmEwASTsRBnTK6DJNqRk GMomyFKrnXRSShnCI4EddexnCx8NeCNdmqf98VtkuuRHgXT7MbXZaEtNcNtY KQXIyJ4EMXNkNHwgINiSxY12gT9JurJCioh4KIggbTDzFiXT9HlKV9OkA6Zl uuHzTxwhibqbF4t2WkMnLIjah6r3BBngBynhoZIZt/YByhUioOrkC5f5EZKb duDRxxkd5OaVrbpm8uP/D76uoYetut3hKSp1qNrBU+TpJgiANOwqgk9M7EIu DM588hGyrzJqigeFnvQVJZ5kC4QP4YL0jQv6GoXsLS7uFlUHAXXkLR2oZHLZ qh/U8VFmv4aAq6h+5BHHJycdJW46fRhVlIHqfoSqF2K0WGpKT6CKT0dGWdCn qcxsK4qtKo1J6TT/quCFHAGd9KMR0VYwrEN9WkCGOZ9ekNvKLY8ZQ0AYq5BZ DololkEOqgCNCMSvYGN1D5otMQYKNGgmSqS/3lcY2GP/hcjXIRqmiQSYRCKA EuI41iXdBrlXT3xMbtVaT2aqRuMwQ6FnizGJiFPQSySpOF2CixmTYU/dtKO4 /yEpGONYimmFDvlWCmL0mIKNI17hMsZAw9bVFBUSluyLu+O5gnLVvgwiSboj CyJT0s1PKfs54zlPkWlWFk+tCfAn8OktHt176ag4TCnjQAm8LTzKlZ5kS1Kl 4ua1/KFid2k2paDspe11t/u1qWbP7+lThsg4Qy1UTO63zNL7IXgyDjkoYyWL +K4epcEc7Va2Dls8ZBgqqo3qqGMMwzFHddAxVO2aoRTPbUUgPXme5ExxDOPI KRL16MbhZOcX4ZUkKYzjEUY8aELgsU92qAOdDYWTPc8VBS0cmYUpxrcNI0hu HCJKR+Iu2A7abUcrcqGdWKZnpvT9bipXNCFxxuK5/f9koDTNgeD5jBGcIi7p dseoEhJBcyfjXC5ENNmdMjJSH9sBA3HZo1+Tfvc82ABDSL/Anz6iE5oUjeMW TaSSLVQEp6YYERZdg+QtwpYpq5nCHqsgxCQdYrYMuMVqRdDMIDSjFN1QMmxL yIc6MIDKV4RIiSj4w8Y80AyHvMVhBePgX3rwh7q85VwWMFi3ckaijuQsBF6x Qhk89K5CfcIkI2rGHlAigjc4hFH/mEAdAuIHZ6ihAz+qRg1q5i9MfWIQLrOm s24hE3DQYBTgiNlvqvHOrLjzD6PwVTbXIEn7naQVrCrM05BlNw5sAiC8uBth GkMMTQQDEQxdaKTiUpkKVGb/bY76Bpy2uJpzmEUnu+GbL1wiOP3Qp0rNY9NF SuiL+KxJeMPwXBf3VRyIQnQ0BhyLiOyFHVWMr0qlq84NFQeW99licydhHO88 BykLjA49LQTPNh72pyfaozc0MVLm0lHG6jSQGRT6A075xFT/DXIMytFQZpbk lxRwUTK/g+ZmShIJ/ATycd9rnbpUszhDBIZCK7zdfiIEDGjcrXXvAAYc1CNH vjg1NLKAaheYap+4AIVCMmWAH4pTOwiuJiOePepYS9I8QzHgE3HphGKQGJxE UuCtOkyb5KpoDRVVxXsxxUgzJYe7BtKvdLRoxiwI24y4BvCPigFYbqiUwhDR 6G3qyCNC4lSoyd5aThvyk+oBt2fazYlFedwYn+HYVDb8BcZ0msHE7cDmiMIQ ImUX3Etu5ctd0KR0S2HaXuaYqjjTwpApwiVOAzlAkshhYCuMW+8VmnO15oTX Ea1gjA+aU4i1Nng7TjhEUz1E4QzMjTFoM4SII4FEtI1BE5BSXtC+GQUQXC0N Lo6YDFbchFkqDcZHOCaOd1wuHtC4CzYOAzDDABgepwwFNsZBO8fJ4x1k4chU a7KUv0lTZYKzylOmcpa3zGUgJKDLQIgAACH5BAUyAA0ALAkARwBwABwAAAT/ EKFGqTIHnVrRpQZifFRRVMrUKGkzho3mhtI3Ku5mrOm+ejODcKjC0EqnhglZ aLkUpqUio8GVLpLJIXPZRU/NaU8UysRkmVuoyxWztjxPmZXa4jBda1QJNr13 B1BRbi8VJhgiVFUeX3xmHlmFIxs1PQdqF1saVDkiUzcaIhOJHoF8jYMSgEsm kFaGTRVUGw2XB1+pFymia4hnb4G6W1sYtLVCaRRmLnJTFiy4rH60I6xTnhK0 flZYtJuCX592aZe1IiuXoYFy7DCywTBwOetFgdF94hbWU+Mbg7J0QAQycM+S BiGqEh3b5SmYLU4WQiC8QykFHWoI+jRSIs6fFE2m/zhM64BBmSpwg4Ztcnhk Ij0WCIe8OngQB5Ba6S7hsHdqj4Vg0FKFY2FIzMQ1HlhM2NMkmyougaJmQmYL yw2pQt5YjLGzaho8fU5xbIMjnEY/Rd0cS6rD3r50VUbQHGJkB9sezGBiATaw Ew5xBMXi0ruhrM+eSSJ+qnVmB7JXStD9xOmDCDotpEJ6imEsmASTHIIZGr1i iDcOqFOXUK0asjLWsGPLnk17Re3YrmMnvs27t+/fsS8JqTAcBWsdn1GrGHWM M2hmOs5syJDuHW3LsPe+CocTTjZjIqeNwwOwofB0cmtlop5Ioh1Eo+zsRvIj U24Um9Yg3vFpgtKbsIxky/8L1KiUxYC6zCNRDcVcI1EXQxzWUx4IsZbNC9Uk EUsd/FGXWjia0JHgD/QQA6EVeFTBDx7TIZTUDUugNk0pyaW2GAcZ7XFHN1fJ GCM35ahCVw0gWDGMXSt509cTxJAhiGp+PFZGa+XYl2GMXEAiBwfgcERDHbtw NcxOm3Siw3DDcEYCSP4FNR9H6jnImnuaOIbLPKG4Eh4Y/FwD03R1lDPJMyWl Y1FhyCgzhj4bFcUVTCqgBkwc3ICY1DWaoOCTiC8aKQY5iQq5lnoTvKACCcY1 CoJdf/iQWnvdJZfSHcVks+cJFvWwhkXsOOnDXApdw9UIFLgCFhNcDsdrcTay RxVvI3ssIkYWz0z4QgtvNJPGtGcemokq6DjDAxUoSagSpu7MWYcWGZZQji3q uaphK4nYIA6KEhE7Qw2mGKFMhbFCq6pfXYjim2v3ceCqBcA1LKnDvr2ZMGsT Q2yxbBVfrPHGHHfMpccgh9xbxiKXTEEEACH5BAV4AA0ALAwARwBoADEAAAT/ sMkpFZWmqW3vFFdXadvEdZw5riNSlUhJcq5nX0HABGAj6ECR5Mco9nS9ApAh sOR2PB9TkpMCm8NcYTgtMAW7cOBGnhR1Oyk0kJko1yBFkcENp8/zAnjc0L2f UwpoAi5oBV48gDk1ZTZpDUZePSF7F3sMW4gNmjpUX1N9DAhgIJVvO05nmpuP jI0Xj0h7AgJbbkg4TGl7emmyWpWhobW4pDtbS6ukrq+wfEBeeRRvkxJ3Y9Fn IGhnUkeYYHMBBQh+fsNiXAFCzRSxTIi0QtQU4eGHdt+0su9Wx5tAgAwbpI5Z O2vPPlWbUO6Rpznwjj0qoo6Up4a0poQTF6rXI0S2/w66g3IsXI4ArqLtu9eL xw6MoVx+YoLGm0pSh8xhisZnmUhY4ggRkVaPm0AEGNNEO6Uq1JxaFvecG4hJ QTBeP+vRYrjp0CF2CPRs7eHCKzkNh8KaZSS2QIZDFQ7VaqM2rAWvbgxmnba3 LwUEB8q0EanXr4LCfhMrXnwQMeNmSCXUiPx4b1u0tBYqgGu2s4XNmUJ3tlRg s4ADethVbrZxCjdQDdm8JglCyRhSs/moiwZz9cFZP5oELJJpkJ6AvWoXwbhv x9YPEcdM9d0M1y06Hf31sDgMIEru3OsxkSMdE/Vmcui0pWZIkK5x3jzV7mQ9 PPRavkSdfxXNqiqjhBiQ3/8W4HXxUoELxbeDATqotl8IRWwGzRJjhIWHRvB0 Z1t38V2gxDaloPRgI9ZpQR88UglESmC48IagB6MQmEmCI3p4hiGd3EMcPuBk aJJA9YEiHjGiTFcjjKfwUE4UJ1WRRUZkbbROh/ZxQQxKWhxJhgsGGIAUM7Yw slkDLgQ2Ajl0UeaYC5Fl4JiWf13w5oNzwilBSJLZqedPg+3p55+ABirooIQW auihiCaq6KKMNuroQQtEKmkDki6QAKUSLECpppM2kEAAA1BKgKYSDJDDAJdS YCqonpK6KqoNEOBpH6emmmmkl456K6m6YoppAp1augABwGo6qqTHUlqssrbS AWz/ArI6c+kCA0AkAbChWpMGtWYUke2mlQorKrDMRirBqAkUq2mx6uJ67KTp pissp9k+e0G6QFgKSQD4onopA6iGugMBQAxAgKnRgourueDKyu6lzwqLLsMT qHtrrgvLqywkmTYg8LQCe9yHrLiakWm1s+5gKwXyRmtsq+aqOy2554JLwcLD 2kzsuzFXi52n0oEMial9zJruBAFI6vMAPu8A6wToJnvtsfJKOm2411KsbLD6 WgqtxZYWkeqn18b6L9K0ljqB1wl4SzZHUIebM67tfh3rvF1rvbXL5lY66t8J +Dx20GoDTIXHYxg+MrkUWco0GropbDWyODMcKbHDzksBw8/XAsuzsDOLjTa/ lIZ8uCffFlstq8qa6lCsnhb7Od7LXny5uBXjDu/kffus6tCUSiey4f/CCnCk QAQeKrH7rk2q5H1XnvPFEFcNOt3L2lt12XjwKzAfAOPLceKoQo5G+XQk/jP0 0LIdu7ztgp6q1wRgXj/bk5ZcKQXCt64btP6bQKj0RZ+vEW1fK/Ma3dbVt6PF r2oJrB2nLNUrkvmqYp1zWbymtbbYbW5dDqSb0S4gN1JxymYWU1jCjrSyP0Vr hWWIAAAh+QQFMgANACwUAEcAVQAcAAAE//C0SVEzyBjKZ+kStWHbpCHWdZSX WXFWqY2YuaLHoRS8iWa5Dm/4aehSp8PPqFAaFBcE1GhpKq7BhkJaukJzV4NO A1UYiCogirMjfpTbCepJZ6KuQJk5h+DHnE1aW04ZalYaHgVhIR1iPWxcUIUN XJQhWDpTOTliUTFiGRtKc1ITYxODiZhmKaY6RRRNYhJONxIYsn19UzUkUkFg rEZws3J1w6oYwRxjsB5QnSsYkysrcRlTsn44rCfQR1uaYl0pPFZbGTDYHOab fcEhc7hHSDRPgX3KT5RN73qdglSd6iAoDgVzOObAuRRCGicf93TouIAlHL9Z AEOFUESk4iAWlP/EtBmCZdqYVKE0OJRi5YI3M6wwjVFZysi4RB2f2GplY2QP KxK/iJzB8latXSsoJjSFR4quFLumDDmoRSLAWFJ6FJEAFJoXOFhEKFFCRc6u mhjJ8qnAiOAUgnDjyp1bVi5PurHkFgCJt6/fv4ADU2gruDDBpEZsGIZ7Z0PW R4M77RnnjlIfmxRVIhYrsRDfxWNlaXFjimWYimeH2fMikme1JpxqLBZR8pdP RfyqySNaCuYsTj+yyJnJVfjsO8x2qLKcKmQKMFT4ADTzeZey6LNLW/jF0g3s flewq6bINbyKz9Q3aUmXvR8fQN69CBpxuaoFh9OGf64z1ODsWThM49OBenic QGAMa9QxFkQEVVKDRdnZgUp3DZBEBzpfVOKEHTOhMlEHLUlGGGiH4KIVDwp1 o40kJ5BhUxcfMpPEJmRFCAYoGUylCGyDwVTTEfoIgkSNHESkzEMRasFcjKiY UgE0lAzGDxLmvQVXcVFamWRebGwpmJZeKtllmGQWBmaZYUYAACH5BAV4AA0A LBoARwBKADIAAAT/sMnZVBFYzIwLtYJHZYrSSVdxZYXJGlQsx0bA3Ewg2bg2 FTZfA4gLYHINRJB3CxRwNwFiRv0IcoJgI3iaKLSV4OX2ZRwDiCvrabShq3Cl uXFlbOcyou9p35nZWkEKU2xDOSJwMyZzbFlNOh9gVwEwZTo8b3UBOnyOb4kz chp8d5uQP5I5CkmTdDcibpuGRYigMYujSGAwXjYirX65ThJqPzlgtjKicpdm oxR6Q3IefNSHwSoqOaLJMmW0ckW8Q0xOmlEor360SJO13QZZmyFD8vNTEmmm TghA8yJK6JEzFcJIvWHdKCBYuDCfsgkMI0JsKGEQvgpTDPRLgs/DxYQg/0OK HEmypEk4JUoksaBoVQWXKV+uXJWSZoWbXmoOspnswj86BH2YMGhvXhYPXzQc LWrEJbkQWfQV+FiFCI+CUCBZVVJuE6MbruRlHYHlBgJ0oCwtpAe2ATo+eMTc GSVrksZiH91tmpasLSojjqDmQBI2mCEdxQrHYHMWjS9bheRh9aqjMdcpYLQQ cQVJDdUnUvY+BkVKE5EmucygS6y5HR7Pi5HkqMHgHRUF6tj4q0MMypzMc3Aj Jgw7Bj16F5ItCmDhEBddzialiXuoVeLE0IzUkHK0JxPnds69IRJtVo9SvQVu wOILGag0XTAQY1ExRQoJBnyGICTwfow0U8l3Af9VIBF40oEhGYjggpAx6CA8 D0Yo4YQUVmjhhRhmqOGGHHbo4YcgirTAiAtQQOKJE5S4AAEoqpgAiSku8CKM CSUwgCkDJJBAAwQMcGMAOZa4xQANyHjjizfm2COQCyQJJJA2NnBjAzraCGUC TyaZwJKb+EjlAL4B2SMUW0gAZg4EJHDDizjo6FaOPEjAQI524CAllmuqmZWN vjGQZhM6eunWnDteIiVYRK65ACaLznnonUSqKSWRE4AZgI43EJkjnpdOeiih VPrRaZNujWkHkTa4CSiYfvAopKUv7rBjDnz28WWmO+5IJSZQlrIjqQzwKeeZ RdpQqR1NZiqlnMu6ASzmlY9syiuln+IAJ61FzuqjHbEEq60f19apA6uD6iDk pWdaK+V3OUpgpbVu/Jrotsu22eiNgxXJqo+R9qEss5jOKeiXTFDL45n4jpoo AW4FQAATbAabKK3OpvkovhPES2yKFOip6Y6mfkrkw1vwGQCwwd6L5ZvJXunm rZBO4HGVUZqZ6Zle0YrnMXlaGqq7C6zJ7Mnf0Sq0Gw8jke4jTCOxcw4G44vE ij8iKcsWQK6b9Y/7YL3jj1rvug+QUm+iK49UvuyujgQwLEGaZ1eZtts/05x2 qLrm6u7aNMOd9tlw6Ep3iB1TEAEAIfkEBTIADQAsIABHAD4AHAAABP+wIaNM KS3fopDK2VSBmWEgaHVkilq1HdV6JHl45qVd7QqaCJ/koLjJTg3TrQc7EGej miTYUeg2hRsJRSkVO57Y4ai6OVFj40eaXh2uOulkUtKyik+Kuz1dGYxSDURa RFg8NUY+RgiCJ25VBg0Vc4KDeYFfkRUYhohAIX+RFChJX3U3jFQnJoGNQRJd Gyw2TmsnjCFFUy2gkRlEQUitJ1UzDViSW3+Mg7qhkWm2TEQmTMNhiVZYvCHU HWMTJn+/Yb3ELxI9gSgTY5qGHCBfTn8VQNzLvoOrYOm6gaH+rbEhbx83SQfb gXhljMivJK0iSpxIsaLFixgztgqipV4gJ3X3TsGqBG2VBEEQF4Zq50cemBEe kAkqIkpFKCcr2CUZ80LJmIVlisyJ5MEMzZiyKoVpIQOYQ46SxMHwCIKeJXdD miJxeEwHsZ+wWN2aKQonOGZbVAX00aFGPUOTPODi8gvkMkF0yEr5NglnKi1V lmjTgUfoh7tD3HQp1wjsD3tm26o7owYZjGJRcQ3aWRKXI18/Ftfr4jNriqTF wiHENSnJYjtD5XyAuaYoGLktLFMYhY21GofUcgl5vO+Jj3rUiHHaQHeSHn3h VNMUPrAOELNCao1LgqGruj4v5gJzNLP2dhLVpuOUWF2j+/ft38u/GH++/Yj1 78+PAAAh+QQFeAANACwYAEcATQAyAAAE/7BJJZu6qtDKRSmGBE5XgzTaZmUc VbQVhZXTZzUBowdvkeuMF+enE+CCKEZAIvjxUEReQQAMCDLKBjWQCSyhQGPO q/yMvRxtsSlGbtWMpu6z+yHOayWCGi+UfUpNAXcMJzlGehUnEmNpOT16h4xx CFlHAlRGW348fINKBpJDQXtlY5hpnjwUp2MGZUxlc35Bh4CYeltxXrcfHwqP ajxEV6lAcUfHn0jCgGSDnrNlmXWAUz/WzbZCqXKDtpmVT811HoReT1uluKZx CnyAkx5oafVvwZyERpfWL4aUizhN6bPj0iRaz8wo8bKPEcOCkt7w8UaHgYEQ 8jpkyeQMgTN4Uf96EHEnoVSVf5CM7HEiwKOXRbEaJlmSSdgJQAtVmCjpEUFP e/tC/EQhxOMHnyIKwCSaRsVRE0p5+qpHtWqapVazat3KtavXr2DDKtIptmwL GRQQkO06BVMPTKhiYPIIF+4UDSiKYXpX1wOHu3f53vAqZ8c7ZULg8akyhpW7 OceKjLq1ZW1WWnChBRL1wwM7uIkk6eAbqFiFR5nUfRV1Og6uL0p0iLC06dIr BrPHTeZoqau+tp4XSs6Ej3aiTK+++NDd+jAumVxthVnc58hAI5xicbHeQPZM bq2vZ18d5wBl4S1xFhyv+lAl3FCYMwlgwIcZ6FsrX0q9cSE89pY8clv/buCJ gJ1Kfn0FzA55LHGIe79ZgtMPFugQgkD1HMLfEgVqtRJD12iCzjg+tESPS2P4 Q881azURYolmKXJVjDRiRWNJN5Zlo1gd5uhjWBj9KOSQRBZp5JFIJqnkkkw2 6eSTUEYp5ZRU3rjAAglgeSWWAzSQAAFXNjBAAg0QkKUECQygZgJnSjBmA1im mSaaCxDwJp0LoCmml1lemWWWBHCwZZxsLjAAbn+SycCYhZK5hGwD1HloBVhy oMSYXUqgw5h5flFBpH0OmqcEfn7pJyM4XNnlooMm4KCafC6QAw58dveoEoEW tKmhuDkYQKRXEhBom6RuGWigXjbiKq2hdsfA/5mlyoYblpuKieihAaiK6Bhs Ulrnmch62yebxx767LLAbsktmllimwOo76aJqLN/4qZmr2qKCmaYaYgabKWL TppolrMC+qWrAStRaQWbzhlAvXt6KiaZW4YaLqn7Vqzor0o4ukQCvYYJsbzn OrsDm5mS2V2qOBCRaZ2iUhXqn+Y2PKuXjIyKMnzOjrlpwRuTCfKeNP9wccWC 5pmol1hS+CbKKnsZaNO9OqHovYvKC6fWFPc5Br98dlusllhmjDCuw2658q8D /Aq0uehubKeurL7btptx+gl2mcYSW2ammW4N9jG2jlstq+auSjibIyHqr9+k wrl3nmuWKfmobsK6Zxfke8I6KuCbYywmrBnnqbZXF1dZT+oRAAAh+QQFMgAN ACwMADAAZwAzAAAE/7A1dY4yBxnJVfmcZBkkoiAihkrnah4qghxhLambrTcy xfUgyafAUhhfvpsnKLpoLJoNxkJrGDRFDAlW3V2NmF0NpuJ8g8OChjIbXTrp kEyWqSsmsyvNtDrmKV01egYXJGIhUFccFktEDUNbMosrLGkFd2QwPy4wMygZ dzxlh6JzGTOkViZsVaBDj0NHOTpGlpgxOiQYRow5c5RiJzFsqT1bVSpxkHPB lpcTU6FjJ1S6yJ5twCHCvCapVoDEDXXOH7soRhRbEyAfPoQWE9SS6W5XfSoV kjp1ooykfk7l0NcoDTwaXNKtaleA0Lh+M2Tx4KPuyw2BYFIBQnUoCgqKRf/K XVIHjhCFWmlOpBNmhRGMcFskPqzARlsuLrN29DKxjlu5C2+u6Hlpa5cTnmR8 vDDZphUhm4dGQA2RDxAUJUScYZuU0NaTU8Aiqjox7kK8shm+bUp7aMoXoS9P Zk1D540VEgUfweJ1qguxQnvuDcyjJ4mNFrqEBaIaScu9cQgYQlKnz4IzDnGs ZiiB8IUEJJ87LeU4prI+Q4dVSMMFRMirVUQl18gc0ay3NqHuuTjqqQI/uHx3 0FF0A94LNK/GlWWiVp6iMHdIl/i8yIjymwMBAbTB5Xrz7yzAix9Pvrz58+jT q1/Pvr379/Djy59Pv779+/jz69/Pw4xQu4d5NtH/DVjQMN1FORlI1Q936WKG Nzmd585jU/AUoTsnqbKBJ6GxsYETgMFWzz881SZCL4uZB8lmYJ2F2RCg4IEC IVKc1INiJtFo2nCbqXPEZho8oZ47Le2hiQgvOtKBJEHa9hlfoWi2gWiZRKGP DMS1hyFNhbGV5CWaUPGEHliMQyYUIAr1AhU7ZWMWFGWiRyRuvJg1WyyfEIal kODMAQ8vFZriRAlgoLkKSekR6YcWpIUQSwV10KTOPl/ACYZQeN1BzSBssNLJ S0M6UghPqVySZ54nneVYBWHUmOFddZaIyZGbhVrnprA5mtIdjwFlZhRbRCJN FFS9wdcIwgJqKzw8gKVF/yW2TBCPdsh+4WEgVMiBCi8yYoKlHu6FghOodyL5 6pGdWodHTo16V2t3D7XB3w7SzGvvvfiOMdV9ivgWBn/GaBrHIlqYpQWkTGpC I2CdUEUTkFLoZ0cnBT3Dw0omQQGnmYWYZBY1DltVwr7xZVxpxVFy8a0uPRj4 BqS6QYoIYAdFWF8PNaD8JEdBnvhGNv92zJ0TCKdI3ykqgaKzmNb18xB0SufW sCBT0BQnfpF6Qki0R2QErrRYrLNPHjYN6gbJ8V0pGsqreIRHblhC0xuB/25D Yw/eSNzC2xWX1EI34pZJTSEsjDB0S2DvR8WojcCCpVTw/OsRXmYqYqMNnEGa Viu99o0g0CsjyVzWU+IKk4c8K+Rz2KQw5ztBzvNy7vrr+8ke++yu2457cxEA ADs= ------=_NextPart_000_006E_01C0CCDA.AD2CB8E0-- From noreply@sourceforge.net Tue Apr 24 19:47:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Apr 2001 11:47:22 -0700 Subject: [Patches] [ python-Patches-418613 ] regular expression bug in pipes.py Message-ID: Patches item #418613, was updated on 2001-04-24 11:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418613&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) Assigned to: Nobody/Anonymous (nobody) Summary: regular expression bug in pipes.py Initial Comment: I tried running the test() function in pipes.py, but the following exception was raised: >>> import pipes >>> t = pipes.Template() >>> t.append('x $IN $OUT', 'ff') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/pipes.py", line 127, in append raise ValueError, ValueError: Template.append: missing $IN in cmd > After some experimenting, I discovered that the regular expression argument to re.search() contains the character '\b', which is interpreted by the string object as a backspace. Those strings have now been changed to raw strings to avoid this problem. I suppose that this module is not widely used. This problem appears in versions as far back as 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418613&group_id=5470 From noreply@sourceforge.net Tue Apr 24 19:50:05 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Apr 2001 11:50:05 -0700 Subject: [Patches] [ python-Patches-418615 ] regular expression bug in pipes.py. Message-ID: Patches item #418615, was updated on 2001-04-24 11:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418615&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) Assigned to: Nobody/Anonymous (nobody) Summary: regular expression bug in pipes.py. Initial Comment: I tried running the test() function in pipes.py, but the following exception was raised: >>> import pipes >>> t = pipes.Template() >>> t.append('x $IN $OUT', 'ff') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/pipes.py", line 127, in append raise ValueError, ValueError: Template.append: missing $IN in cmd > After some experimenting, I discovered that the regular expression argument to re.search() contains the character '\b', which is interpreted by the string object as a backspace. Those strings have now been changed to raw strings to avoid this problem. I suppose that this module is not widely used. This problem appears in versions as far back as 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418615&group_id=5470 From noreply@sourceforge.net Tue Apr 24 20:41:35 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Apr 2001 12:41:35 -0700 Subject: [Patches] [ python-Patches-418465 ] patches for python-mode.el V4.1 Message-ID: Patches item #418465, was updated on 2001-04-23 22:11 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418465&group_id=5470 Category: demos and tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Weiner (bwcto) >Assigned to: Barry Warsaw (bwarsaw) Summary: patches for python-mode.el V4.1 Initial Comment: This patch fixes a number of issues with python- mode.el (the fixes are documented within the patch) and also extends python-mode.el so that it works with the emacs interface to pydoc, pydoc.el which was just released . Please let me know if you decide to apply all of these changes and put this into a production release of Python, at which point, I will stop distributing the modified python-mode.el with the pydoc.el package. Thanks, Bob ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418465&group_id=5470 From noreply@sourceforge.net Tue Apr 24 22:18:04 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Apr 2001 14:18:04 -0700 Subject: [Patches] [ python-Patches-418659 ] Fixes for UnixWare and ReliantUnix Message-ID: Patches item #418659, was updated on 2001-04-24 14:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fixes for UnixWare and ReliantUnix Initial Comment: This patch fixes the build problems on UnixWare, by: a) backing out 1.215 of configure.in and 1.34 of Makefile.pre.in b) Adding a test to check whether the compiler supports -Kpthread, and using that instead of #defines and libraries for pthread support. This part is not only restricted to UnixWare, but should work on other SysV compilers as well (e.g. ReliantUnix, untested) With these patches, UnixWare still passes the test suite except for test_math. Compared to 2.1, this drops usage of a shared libpython2.1.so. Such a feature is highly problematic, and was implemented incorrectly in 2.1. It should be brought back only as a configure option, which should be off by default, and apply to all Unix systems that support shared libraries. These patches should be applied to both the mainline and the 2.1 maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418659&group_id=5470 From noreply@sourceforge.net Wed Apr 25 04:46:26 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Apr 2001 20:46:26 -0700 Subject: [Patches] [ python-Patches-418615 ] regular expression bug in pipes.py. Message-ID: Patches item #418615, was updated on 2001-04-24 11:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418615&group_id=5470 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) Assigned to: Tim Peters (tim_one) Summary: regular expression bug in pipes.py. Initial Comment: I tried running the test() function in pipes.py, but the following exception was raised: >>> import pipes >>> t = pipes.Template() >>> t.append('x $IN $OUT', 'ff') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/pipes.py", line 127, in append raise ValueError, ValueError: Template.append: missing $IN in cmd > After some experimenting, I discovered that the regular expression argument to re.search() contains the character '\b', which is interpreted by the string object as a backspace. Those strings have now been changed to raw strings to avoid this problem. I suppose that this module is not widely used. This problem appears in versions as far back as 1.5.2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-24 20:46 Message: Logged In: YES user_id=31435 Oops! I didn't notice your patch attachment -- luckily, we made the same changes on the same lines. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-24 20:43 Message: Logged In: YES user_id=31435 Thanks, Jeffery! I found 4 calls of this form to re.search (), and they are indeed clearly wrong. Repaired as you suggested, in Lib/pipes.py; new revision: 1.9 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418615&group_id=5470 From noreply@sourceforge.net Wed Apr 25 04:43:59 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 24 Apr 2001 20:43:59 -0700 Subject: [Patches] [ python-Patches-418615 ] regular expression bug in pipes.py. Message-ID: Patches item #418615, was updated on 2001-04-24 11:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418615&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) >Assigned to: Tim Peters (tim_one) Summary: regular expression bug in pipes.py. Initial Comment: I tried running the test() function in pipes.py, but the following exception was raised: >>> import pipes >>> t = pipes.Template() >>> t.append('x $IN $OUT', 'ff') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/pipes.py", line 127, in append raise ValueError, ValueError: Template.append: missing $IN in cmd > After some experimenting, I discovered that the regular expression argument to re.search() contains the character '\b', which is interpreted by the string object as a backspace. Those strings have now been changed to raw strings to avoid this problem. I suppose that this module is not widely used. This problem appears in versions as far back as 1.5.2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-24 20:43 Message: Logged In: YES user_id=31435 Thanks, Jeffery! I found 4 calls of this form to re.search (), and they are indeed clearly wrong. Repaired as you suggested, in Lib/pipes.py; new revision: 1.9 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418615&group_id=5470 From noreply@sourceforge.net Thu Apr 26 08:59:22 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Apr 2001 00:59:22 -0700 Subject: [Patches] [ python-Patches-419070 ] Fix #416670: register SRE types Message-ID: Patches item #419070, was updated on 2001-04-26 00:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419070&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix #416670: register SRE types Initial Comment: This patch registers the three SRE types in the copy module as immutable, atomic types. This is not completely correct, since pattern.groupindex is a mutable object (a dictionary). Since nobody *should* change that dictionary, treating it as immutable is sufficient. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419070&group_id=5470 From noreply@sourceforge.net Thu Apr 26 15:29:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Apr 2001 07:29:34 -0700 Subject: [Patches] [ python-Patches-419145 ] SocketServer test (UDP/TCP Thread/Fork) Message-ID: Patches item #419145, was updated on 2001-04-26 07:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Kenneth Casson Leighton (lkcl) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer test (UDP/TCP Thread/Fork) Initial Comment: this is a _completely_ inappropriate location to put in a patch: stupid-netscape word-wraps it. well, too bad :) --- src/Python-2.1/Lib/SocketServer.py Wed Apr 11 05:02:05 2001 +++ SocketServer2.py Thu Apr 26 16:23:32 2001 @@ -110,15 +110,22 @@ BaseServer: - split generic "request" functionality out into BaseServer class. - Copyright (C) 2000 Luke Kenneth Casson Leighton example: read entries from a SQL database (requires overriding get_request() to return a table entry from the database). entry is processed by a RequestHandlerClass. +Test Method: +simple echo server, ForkingTCPServer and ThreadingTCPServer. +send data on port 10000, it will be received back, verbatim. +run test with --client to create 20 such test connections, +which will send 20 tests each and expect them to be received. + +TODO: write a UDPServer test, too. + """ -# Author of the BaseServer patch: Luke Kenneth Casson Leighton +# Author of the BaseServer and test() patch: Luke Kenneth Casson Leighton __version__ = "0.3" @@ -555,3 +562,171 @@ def finish(self): self.socket.sendto(self.wfile.getvalue(), self.client_address) + + +class EchoHandler: + """ an example handler that reads data from a socket + and sends it back. + """ + + def handle(self): + """ simple read line, write it. + we don't even do a select on the socket, just read + it. + """ + eof = None + data = None + + print 'received connection request' + data = self.rfile.readline() + print 'received data:', repr(data) + self.wfile.write(data) + self.wfile.flush() + +class EchoUDPHandler(EchoHandler,DatagramRequestHandler): pass +class EchoTCPHandler(EchoHandler,StreamRequestHandler): pass + + +class TestConnection: + """ simple test connector, has send and recv methods. + code is ripped / stripped from HTTPConnection :) + """ + + def __init__(self, host, port=None, socket_type=socket.SOCK_STREAM): + self.sock = None + self.host = host + self.port = port + self.socket_type = socket_type + + def connect(self): + """Connect to the host and port specified in __init__.""" + self.sock = socket.socket(socket.AF_INET, self.socket_type) + self.sock.connect((self.host, self.port)) + + # hmm, don't know enough about UDP / python to know if + # this works as expected! + self.fp = self.sock.makefile('wrb', 0) + + def close(self): + """Close the connection to the server.""" + if self.sock: + self.sock.close() # close it manually... there may be other refs + self.sock = None + + def send(self, str): + """Send `str' to the server.""" + if self.sock is None: + self.connect() + + try: + self.fp.write(str) + except socket.error, v: + if v[0] == 32: # Broken pipe + self.close() + raise + + def read(self, len=0): + """read from socket + """ + return self.fp.read(len) + + +def test(): + """ test method for SocketServer.py + """ + + def test_client_fn(server_addr='127.0.0.1', server_port=10000, + sock_type=socket.SOCK_STREAM): + + clients = [] + for n in range(20): + clients.append(TestConnection(server_addr, server_port, sock_type)) + + for i in range(len(clients)): + c = clients[i] + c.send("echo test %d\n" % i) + + for i in range(len(clients)): + c = clients[i] + expected_data = "echo test %d\n" % i + data = c.read(len(expected_data)) + if data != expected_data: + print "client %d failed test" + + + def test_server_fn(ServerClass, server_addr, HandlerClass): + + srv = ServerClass(('', 10000), HandlerClass) + srv.max_children = 50 + srv.serve_forever() + + def usage(): + print "usage: --client, -c a test client" + print " --thread-server, -t to run a threading server" + print " --fork-server, -f to run a forking server" + print " --udp, to run a UDP server" + print " --tcp to run a TCP server" + sys.exit(0) + + from getopt import getopt + + if len(sys.argv) == 1: + usage() + + opts, args = getopt(sys.argv[1:], 'hftc', + ['help', 'fork-server', 'thread-server', + 'udp', 'tcp', + 'client']) + + threading = None + forking = None + tcp = None + udp = None + testclass = None + testhandlerclass = None + sock_type = None + testclient = None + + for (opt, value) in opts: + + if opt == '--help' or opt == '-h': + usage() + + if opt == '--tcp': + tcp = 1 + sock_type = socket.SOCK_STREAM + + if opt == '--udp': + udp = 1 + sock_type = socket.SOCK_DGRAM + + if opt == '--fork-server' or opt == '-f': + forking = 1 + + if opt == '--thread-server' or opt == '-t': + threading = 1 + + if opt == '--client' or opt == '-c': + testclient = 1 + + if tcp and forking: + testclass = ForkingTCPServer + testhandlerclass = EchoTCPHandler + if tcp and threading: + testclass = ThreadingTCPServer + testhandlerclass = EchoTCPHandler + if udp and forking: + testclass = ForkingUDPServer + testhandlerclass = EchoUDPHandler + if udp and threading: + testclass = ThreadingUDPServer + testhandlerclass = EchoUDPHandler + + if testclass: + test_server_fn(testclass, 10000, testhandlerclass) + + if testclient: + test_client_fn('127.0.0.1', 10000, sock_type) + +if __name__ == '__main__': + test() ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419145&group_id=5470 From noreply@sourceforge.net Thu Apr 26 16:50:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Apr 2001 08:50:18 -0700 Subject: [Patches] [ python-Patches-419176 ] Fix 418977: Properly trace cellobjects Message-ID: Patches item #419176, was updated on 2001-04-26 08:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419176&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Fix 418977: Properly trace cellobjects Initial Comment: There were two errors in PyFrame_LocalsToFast: first, it did not add the offset for cell and free vars. Furthermore, when clearing a cell, not should the cellobject be deallocated, but the object in the cellobject. This patch fixes both bugs. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419176&group_id=5470 From noreply@sourceforge.net Fri Apr 27 08:54:20 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 00:54:20 -0700 Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames Message-ID: Patches item #410465, was updated on 2001-03-21 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow pre-encoded strings as filenames Initial Comment: This patch enables most filename parameters to use pre- encoded strings. On Windows, the default of "mbcs" is used. On all other platforms, the default filename encoding is the same as the general default encoding, which in reality means there is no functional change. However, other platforms can simply plugin their own encodings. Rationalle: os.listdir() etc already return pre- encoded strings on some platforms (notably Windows). These pre-encoded strings may be used now for all these functions - however, if you convert this encoded string to a Unicode string, it can not be used to open the file. This patch enables either a pre-encoded string to work (as now) or a Unicode representation of that same string (unlike now) Things of note: * I invented a new "Es" PyArg_ParseTuple marker. This is very similar to "es", except it leaves string objects alone assuming they are already encoded correctly. "es" assumes a string in the default encoding which it will then encode in the new characterset - ie, a pre-encoded string fails here. * This means that all affected functions have an extra string copy. This copy still happens even when strings are passed, and even on platforms where no Unicode filesystem support exists. The only other alternative was to make a much uglier patch, somehow using string objects in-place, but converting and freeing the buffer when Unicode. This could be done if desired, but I'm not sure the added code complexity is worth it. * New method on win32: nt._getpathname(). This is almost identical to win32api.GetPathName(), except it handles encoded strings. ntpath.py has also been changed to work with this. A hidden bonus of this patch is that it will make os.abspath() work identically regardless of the Win32 extensions being installed. * Tested on Linux, Windows 98 and Windows 2k. Still working out how to build Python on my BeOs box :) * New test for these semantics added. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-27 00:54 Message: Logged In: YES user_id=38388 I like the idea of telling the arg parser to accept strings as-is, but I think that copying all the code just to implement the new "E" parser. Much easier would be switching on the second marker (behind the "e"), e.g. using "et" and "et#". Do you want me to look into this ? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-03-22 14:10 Message: Logged In: YES user_id=14198 I appreciate it is too late for 2.1 for a change of this size. I don't think posixmodule is wrong - at least not how you think :) posix_rename calls: return posix_2str(args, "EsEs:rename", rename); however, it is posix_2str that passes the encoding, not posix_rename itself. Ditto for posix_1str and posix_do_stat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:45 Message: Logged In: YES user_id=6380 Mark, I don't think you expected to get this into 2.1, did you? It's way too big. Also, I think your patch to posixmodule.c has some bugs -- if I understand correctly, the format string "Es" requires two arguments, the encoding and the address of the C string pointer; but several functions (posix_rename and onwards) don't pass the encoding name. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-03-21 21:04 Message: Logged In: YES user_id=14198 doh - forgot to click the checkbox ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 From noreply@sourceforge.net Fri Apr 27 08:55:23 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 00:55:23 -0700 Subject: [Patches] [ python-Patches-419419 ] Support ExtensionClass in pydoc, inspect Message-ID: Patches item #419419, was updated on 2001-04-27 00:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419419&group_id=5470 Category: library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Ka-Ping Yee (ping) Summary: Support ExtensionClass in pydoc, inspect Initial Comment: The attached patch provides support for ExtensionClass objects in pydoc and inspect. Although ExtensionClass is not a piece of the core I think it deserves some support since it is used heavily by at least two major Python tools, Zope and pygtk (2.0). In particular, with gtk+ 2.0 documentation on the thin side at the moment, adding docstrings to pygtk during wrapper generation that contain function/method signatures makes it easier to use this package. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419419&group_id=5470 From noreply@sourceforge.net Fri Apr 27 12:56:08 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 04:56:08 -0700 Subject: [Patches] [ python-Patches-419459 ] urllib adds extra CRLF in posted data Message-ID: Patches item #419459, was updated on 2001-04-27 04:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419459&group_id=5470 Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Nobody/Anonymous (nobody) Summary: urllib adds extra CRLF in posted data Initial Comment: urllib.py and urllib2.py adds an extra trailing CRLF in data that is sent in a POST statement. That is in violation of RFC 2616 that says: > Certain buggy HTTP/1.0 client implementations > generate extra CRLF's after a POST request. To > restate what is explicitly forbidden by the > BNF, an HTTP/1.1 client MUST NOT preface or > follow a request with an extra CRLF. The enclosed patch removes the generation of the extra CRLF. The patch was generated against the current CVS revisions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419459&group_id=5470 From noreply@sourceforge.net Fri Apr 27 13:15:18 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 05:15:18 -0700 Subject: [Patches] [ python-Patches-410465 ] Allow pre-encoded strings as filenames Message-ID: Patches item #410465, was updated on 2001-03-21 21:02 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 Category: core (C code) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: Allow pre-encoded strings as filenames Initial Comment: This patch enables most filename parameters to use pre- encoded strings. On Windows, the default of "mbcs" is used. On all other platforms, the default filename encoding is the same as the general default encoding, which in reality means there is no functional change. However, other platforms can simply plugin their own encodings. Rationalle: os.listdir() etc already return pre- encoded strings on some platforms (notably Windows). These pre-encoded strings may be used now for all these functions - however, if you convert this encoded string to a Unicode string, it can not be used to open the file. This patch enables either a pre-encoded string to work (as now) or a Unicode representation of that same string (unlike now) Things of note: * I invented a new "Es" PyArg_ParseTuple marker. This is very similar to "es", except it leaves string objects alone assuming they are already encoded correctly. "es" assumes a string in the default encoding which it will then encode in the new characterset - ie, a pre-encoded string fails here. * This means that all affected functions have an extra string copy. This copy still happens even when strings are passed, and even on platforms where no Unicode filesystem support exists. The only other alternative was to make a much uglier patch, somehow using string objects in-place, but converting and freeing the buffer when Unicode. This could be done if desired, but I'm not sure the added code complexity is worth it. * New method on win32: nt._getpathname(). This is almost identical to win32api.GetPathName(), except it handles encoded strings. ntpath.py has also been changed to work with this. A hidden bonus of this patch is that it will make os.abspath() work identically regardless of the Win32 extensions being installed. * Tested on Linux, Windows 98 and Windows 2k. Still working out how to build Python on my BeOs box :) * New test for these semantics added. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2001-04-27 05:15 Message: Logged In: YES user_id=14198 MAL - please do! I generally look for the least-intrusive patch when dealing with potentially contentious issues, but I agree it makes more sense to rationalize. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2001-04-27 00:54 Message: Logged In: YES user_id=38388 I like the idea of telling the arg parser to accept strings as-is, but I think that copying all the code just to implement the new "E" parser. Much easier would be switching on the second marker (behind the "e"), e.g. using "et" and "et#". Do you want me to look into this ? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-03-22 14:10 Message: Logged In: YES user_id=14198 I appreciate it is too late for 2.1 for a change of this size. I don't think posixmodule is wrong - at least not how you think :) posix_rename calls: return posix_2str(args, "EsEs:rename", rename); however, it is posix_2str that passes the encoding, not posix_rename itself. Ditto for posix_1str and posix_do_stat. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-22 13:45 Message: Logged In: YES user_id=6380 Mark, I don't think you expected to get this into 2.1, did you? It's way too big. Also, I think your patch to posixmodule.c has some bugs -- if I understand correctly, the format string "Es" requires two arguments, the encoding and the address of the C string pointer; but several functions (posix_rename and onwards) don't pass the encoding name. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2001-03-21 21:04 Message: Logged In: YES user_id=14198 doh - forgot to click the checkbox ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=410465&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:15:34 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:15:34 -0700 Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac Message-ID: Patches item #419648, was updated on 2001-04-27 15:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470 Category: distutils Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Carbon support for distutils on Mac Initial Comment: Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1 onwards needs this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:21:24 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:21:24 -0700 Subject: [Patches] [ python-Patches-419649 ] Metrowerks library adds 0x itself Message-ID: Patches item #419649, was updated on 2001-04-27 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419649&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Metrowerks library adds 0x itself Initial Comment: The Metrowerks C library on the Mac prints 0 as 0x0 already with %#x, so disable the code to add it ourselves. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419649&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:22:47 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:22:47 -0700 Subject: [Patches] [ python-Patches-419651 ] Metrowerks on Mac adds 0x itself Message-ID: Patches item #419651, was updated on 2001-04-27 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Metrowerks on Mac adds 0x itself Initial Comment: The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:25:36 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:25:36 -0700 Subject: [Patches] [ python-Patches-419652 ] Disable input look Tk event processing o Message-ID: Patches item #419652, was updated on 2001-04-27 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Disable input look Tk event processing o Initial Comment: The Tk input handler on the Mac is too greedy, and file handlers are available but don't work. Disable mainloop Tk event handling at least makes the console usable again after using Tk. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:32:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:32:13 -0700 Subject: [Patches] [ python-Patches-419651 ] Metrowerks on Mac adds 0x itself Message-ID: Patches item #419651, was updated on 2001-04-27 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Tim Peters (tim_one) Summary: Metrowerks on Mac adds 0x itself Initial Comment: The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-27 15:32 Message: Logged In: YES user_id=31435 Jack, there's no patch here. Have you reported this bug to Metrowerks? The C std is very clear that a %#x format must *not* produce a leading 0x when and only when the number being converted is 0. This isn't a debatable issue: if they're producing 0x0, they're wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:39:13 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:39:13 -0700 Subject: [Patches] [ python-Patches-419652 ] Disable input look Tk event processing o Message-ID: Patches item #419652, was updated on 2001-04-27 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Disable input look Tk event processing o Initial Comment: The Tk input handler on the Mac is too greedy, and file handlers are available but don't work. Disable mainloop Tk event handling at least makes the console usable again after using Tk. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:39 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419652&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:40:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:40:11 -0700 Subject: [Patches] [ python-Patches-419651 ] Metrowerks on Mac adds 0x itself Message-ID: Patches item #419651, was updated on 2001-04-27 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Tim Peters (tim_one) Summary: Metrowerks on Mac adds 0x itself Initial Comment: The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:40 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-27 15:32 Message: Logged In: YES user_id=31435 Jack, there's no patch here. Have you reported this bug to Metrowerks? The C std is very clear that a %#x format must *not* produce a leading 0x when and only when the number being converted is 0. This isn't a debatable issue: if they're producing 0x0, they're wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:42:32 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:42:32 -0700 Subject: [Patches] [ python-Patches-419651 ] Metrowerks on Mac adds 0x itself Message-ID: Patches item #419651, was updated on 2001-04-27 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Tim Peters (tim_one) Summary: Metrowerks on Mac adds 0x itself Initial Comment: The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:42 Message: Logged In: YES user_id=45365 There's a patch now. Silly form wanted me to check the box, even though I had used the attach button:-( I'll also send the bug report to metrowerks, but that'll be a looooong time in fixing, I guess. Do you (or anyone else) happen to have a section number/etc for the requirement? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:40 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-27 15:32 Message: Logged In: YES user_id=31435 Jack, there's no patch here. Have you reported this bug to Metrowerks? The C std is very clear that a %#x format must *not* produce a leading 0x when and only when the number being converted is 0. This isn't a debatable issue: if they're producing 0x0, they're wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:43:07 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:43:07 -0700 Subject: [Patches] [ python-Patches-419649 ] Metrowerks library adds 0x itself Message-ID: Patches item #419649, was updated on 2001-04-27 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419649&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Metrowerks library adds 0x itself Initial Comment: The Metrowerks C library on the Mac prints 0 as 0x0 already with %#x, so disable the code to add it ourselves. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:43 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419649&group_id=5470 From noreply@sourceforge.net Fri Apr 27 23:43:39 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 15:43:39 -0700 Subject: [Patches] [ python-Patches-419648 ] Carbon support for distutils on Mac Message-ID: Patches item #419648, was updated on 2001-04-27 15:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470 Category: distutils Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Carbon support for distutils on Mac Initial Comment: Carbon support for distutils on the mac was somehow not checked in. MacPython from 2.1 onwards needs this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:43 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419648&group_id=5470 From noreply@sourceforge.net Sat Apr 28 00:40:10 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 16:40:10 -0700 Subject: [Patches] [ python-Patches-419651 ] Metrowerks on Mac adds 0x itself Message-ID: Patches item #419651, was updated on 2001-04-27 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Tim Peters (tim_one) Summary: Metrowerks on Mac adds 0x itself Initial Comment: The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-27 16:40 Message: Logged In: YES user_id=31435 Section 7.9.6.1 ("The fprintf function"), under the description of the "#" flag character: "For x (or X) conversion, a nonzero result will have Ox (or 0X) prefixed to it." In the meantime, at least one other box is known that screws this up, and I said at the time that if a second box ever appeared, I'd do something about it . ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:42 Message: Logged In: YES user_id=45365 There's a patch now. Silly form wanted me to check the box, even though I had used the attach button:-( I'll also send the bug report to metrowerks, but that'll be a looooong time in fixing, I guess. Do you (or anyone else) happen to have a section number/etc for the requirement? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:40 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-27 15:32 Message: Logged In: YES user_id=31435 Jack, there's no patch here. Have you reported this bug to Metrowerks? The C std is very clear that a %#x format must *not* produce a leading 0x when and only when the number being converted is 0. This isn't a debatable issue: if they're producing 0x0, they're wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 From noreply@sourceforge.net Sat Apr 28 06:40:48 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 27 Apr 2001 22:40:48 -0700 Subject: [Patches] [ python-Patches-419651 ] Metrowerks on Mac adds 0x itself Message-ID: Patches item #419651, was updated on 2001-04-27 15:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 Category: core (C code) >Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Tim Peters (tim_one) Summary: Metrowerks on Mac adds 0x itself Initial Comment: The Metrowerks C library on the Mac already prints 0 as 0x0 so don't add another 0x to the front of that. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-27 22:40 Message: Logged In: YES user_id=31435 An ifdef on the compiler isn't the right way to worm around this: it's not unique to this box, and since it's a bug on the box it *should* get fixed someday (at which point the ifdef'ed code will do a wrong thing for the box). Checked in another approach without ifdefs. Please test on your box and scream if it still fails. Objects/stringobject.c; new revision: 2.104 Objects/unicodeobject.c; new revision: 2.88 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-27 16:40 Message: Logged In: YES user_id=31435 Section 7.9.6.1 ("The fprintf function"), under the description of the "#" flag character: "For x (or X) conversion, a nonzero result will have Ox (or 0X) prefixed to it." In the meantime, at least one other box is known that screws this up, and I said at the time that if a second box ever appeared, I'd do something about it . ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:42 Message: Logged In: YES user_id=45365 There's a patch now. Silly form wanted me to check the box, even though I had used the attach button:-( I'll also send the bug report to metrowerks, but that'll be a looooong time in fixing, I guess. Do you (or anyone else) happen to have a section number/etc for the requirement? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:40 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-04-27 15:32 Message: Logged In: YES user_id=31435 Jack, there's no patch here. Have you reported this bug to Metrowerks? The C std is very clear that a %#x format must *not* produce a leading 0x when and only when the number being converted is 0. This isn't a debatable issue: if they're producing 0x0, they're wrong. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419651&group_id=5470 From noreply@sourceforge.net Mon Apr 30 23:12:54 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Apr 2001 15:12:54 -0700 Subject: [Patches] [ python-Patches-419649 ] Metrowerks library adds 0x itself Message-ID: Patches item #419649, was updated on 2001-04-27 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419649&group_id=5470 Category: core (C code) Group: 2.0.1 bugfix >Status: Closed >Resolution: Rejected Priority: 7 Submitted By: Jack Jansen (jackjansen) >Assigned to: Tim Peters (tim_one) Summary: Metrowerks library adds 0x itself Initial Comment: The Metrowerks C library on the Mac prints 0 as 0x0 already with %#x, so disable the code to add it ourselves. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-30 15:12 Message: Logged In: YES user_id=31435 Jack, is this still a problem under current CVS? Thought this got fixed already. As noted then, an #ifdef isn't a good enough solution. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-04-27 15:43 Message: Logged In: YES user_id=45365 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=419649&group_id=5470 From noreply@sourceforge.net Mon Apr 30 23:14:40 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Apr 2001 15:14:40 -0700 Subject: [Patches] [ python-Patches-418613 ] regular expression bug in pipes.py Message-ID: Patches item #418613, was updated on 2001-04-24 11:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418613&group_id=5470 Category: library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeffery D. Collins (tokeneater) >Assigned to: Tim Peters (tim_one) Summary: regular expression bug in pipes.py Initial Comment: I tried running the test() function in pipes.py, but the following exception was raised: >>> import pipes >>> t = pipes.Template() >>> t.append('x $IN $OUT', 'ff') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.1/pipes.py", line 127, in append raise ValueError, ValueError: Template.append: missing $IN in cmd > After some experimenting, I discovered that the regular expression argument to re.search() contains the character '\b', which is interpreted by the string object as a backspace. Those strings have now been changed to raw strings to avoid this problem. I suppose that this module is not widely used. This problem appears in versions as far back as 1.5.2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-30 15:14 Message: Logged In: YES user_id=31435 Just closed this. The bug is already fixed, and there's no patch here anyway. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418613&group_id=5470 From noreply@sourceforge.net Mon Apr 30 23:16:11 2001 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 30 Apr 2001 15:16:11 -0700 Subject: [Patches] [ python-Patches-418147 ] Fixes to allow compiling w/ Borland Message-ID: Patches item #418147, was updated on 2001-04-22 23:59 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418147&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Hansen (ixokai) >Assigned to: Tim Peters (tim_one) Summary: Fixes to allow compiling w/ Borland Initial Comment: This patch supercedes the following bugs that I submitted before realizing it'd be better to just submit one big patch: 417802, 417949, 417952 So if someone wants to close them, they can :) Now, an explaination of the changes I found that needed to be done: In pyport.h, I put a couple #defines to make rename chsize/setmode to _chsize/_setmode.. why there? I really couldn't think of a better place to put it, and it seemed better then surrounding the calls to '_chsize/_setmode' with #ifdef __BORLANDC_'s. Posixmodule needed a lot of fixes. Borland obviousely doesn't support Unixish *id's, firstly. Secondly, io.h defines chmod as 'chmod(const char *, int amode)', and we called an 'extern chmod(const char *, mode_t)', so that needed to be altered. Later, it needed to include __BORLANDC__ in the places where it names 'posixmodule' as 'nt'. In Timemodule, we have some renamings to do again. I put them here instead of pyport.h, since it already had most of them for Win16, even though I don't know if that was best or not. Further, Borland needs to keep HAVE_CLOCK, so I had to make it so Mark Hammond's clock code didn't replace the built in one. Config.h needed a few changes. I moved HAVE_SYS_UTIME_H up by HAVE_HYPOT, so it could be defined for everything still, and just have Borland #undef it... So I basically copied what they did with HAVE_HYPOT. Okay, so all of the above was actually rather self- explainatory from the patch. Oh well. :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2001-04-30 15:16 Message: Logged In: YES user_id=31435 Assigned to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=418147&group_id=5470