From noreply at sourceforge.net Sat Jul 1 03:41:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Jun 2006 18:41:43 -0700 Subject: [Patches] [ python-Patches-1254718 ] GCC detection for runtime_library_dirs when ccache is used Message-ID: Patches item #1254718, was opened at 2005-08-09 14:23 Message generated for change (Comment added) made by rickharris You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1254718&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: GCC detection for runtime_library_dirs when ccache is used Initial Comment: Recently I discovered ccache and am very happily using it. However, some Python extensions (python-ldap, to be precise) didn't link correctly, ignoring runtime_library_dirs, only if I used ccache. (CC='ccache gcc' python setup.py...) Attached patch fixes this by treating any compiler with string gcc or g++ in it as GCC, not only those start with gcc or g++. This feels like hack over hack, but oh well. ---------------------------------------------------------------------- Comment By: Rick (rickharris) Date: 2006-07-01 11:11 Message: Logged In: YES user_id=1269204 Patch is good, bug still exists and not limited to just ccache users. On many systems using gcc, 'CC' does not == "gcc". For example, on this system /usr/lib/python2.4/config/Makefile reads 'CC=i686-pc-linux-gnu-gcc -pthread' Therefore distutils will never link the RPATH/RUNPATH into the .so correctly. If any of the libraries linked against are in directories that are not in the system's LDPATH, then the application will fail when it cannot find the linked library. ---------------------------------------------------------------------- Comment By: Seo Sanghyeon (sanxiyn) Date: 2005-08-09 16:38 Message: Logged In: YES user_id=837148 Hye-Shik Chang pointed out that Intel C Compiler(icc) needs -Wl,-R as well, not -R. Perhaps this should check for icc too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1254718&group_id=5470 From noreply at sourceforge.net Sat Jul 1 13:21:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Jul 2006 04:21:34 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 17:49 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-07-01 07:21 Message: Logged In: YES user_id=764593 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-01 07:19 Message: Logged In: NO ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:53 Message: Logged In: YES user_id=764593 For misc/news, I suggest something like "Fixed an obscure traceback regression when (deprecated) strings are raised." ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:52 Message: Logged In: YES user_id=764593 In order to fix it, I also broke out some repeated code into a subfunction, and switched some logic to a more modern idiom -- these parts *could* be separated if need be, but I won't be able to do it this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 From noreply at sourceforge.net Sat Jul 1 20:10:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Jul 2006 11:10:52 -0700 Subject: [Patches] [ python-Patches-1515361 ] 1515169 fix (ImportWarning flood) Message-ID: Patches item #1515361, was opened at 2006-06-30 19:16 Message generated for change (Comment added) made by sergeyli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515361&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shane Hathaway (hathawsh) Assigned to: Nobody/Anonymous (nobody) Summary: 1515169 fix (ImportWarning flood) Initial Comment: This patch to import.c only generates ImportWarnings if the import fails. It also fixes what appear to be memory leaks involving the "copy" variable. This patch applies to Python 2.5b1. ---------------------------------------------------------------------- Comment By: Sergey (sergeyli) Date: 2006-07-01 14:10 Message: Logged In: YES user_id=141494 See also an alternative python.org/sf/1515609. Mine doesn't have the memory leak fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515361&group_id=5470 From noreply at sourceforge.net Sat Jul 1 20:11:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Jul 2006 11:11:38 -0700 Subject: [Patches] [ python-Patches-1515609 ] Alternative fix for ImportWarning Message-ID: Patches item #1515609, was opened at 2006-07-01 14:05 Message generated for change (Comment added) made by sergeyli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Sergey (sergeyli) Assigned to: Nobody/Anonymous (nobody) Summary: Alternative fix for ImportWarning Initial Comment: Similarly to http://www.python.org/sf/1515361, tries to change the way ImportWarning behaves. The difference between tha patches is that this one does not try to produce a full list of all possible directories that have not been imported. Instead, this patch only provides number of candidate directories found, and prints the first one, which hopefully is the most likely candidate. Full description follows. I tried to implement Jean-Paul Calderone's idea for the following patch, plagiarizing Ralf W. Grosse-Kunstleve's error text. It delays import warning until end of search for modules, but remembers how many potential modules (candidates without __init__.py) it didn't import. I didn't really try to analyze any conditions, instead I simply assumed that wherever ImportWarning would be issued, we have a suitable candidate, and saved it on the stack. If nothing is found, Python emits ImportWarning right before ImportError, and explains what happened. ---------------------------------------------------------------------- >Comment By: Sergey (sergeyli) Date: 2006-07-01 14:11 Message: Logged In: YES user_id=141494 This one also doesn't have the memory leak fix mentioned in python.org/sf/1515361. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515609&group_id=5470 From noreply at sourceforge.net Sat Jul 1 20:12:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Jul 2006 11:12:24 -0700 Subject: [Patches] [ python-Patches-1515609 ] Alternative fix for ImportWarning (fix for 1515169) Message-ID: Patches item #1515609, was opened at 2006-07-01 14:05 Message generated for change (Settings changed) made by sergeyli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Sergey (sergeyli) Assigned to: Nobody/Anonymous (nobody) >Summary: Alternative fix for ImportWarning (fix for 1515169) Initial Comment: Similarly to http://www.python.org/sf/1515361, tries to change the way ImportWarning behaves. The difference between tha patches is that this one does not try to produce a full list of all possible directories that have not been imported. Instead, this patch only provides number of candidate directories found, and prints the first one, which hopefully is the most likely candidate. Full description follows. I tried to implement Jean-Paul Calderone's idea for the following patch, plagiarizing Ralf W. Grosse-Kunstleve's error text. It delays import warning until end of search for modules, but remembers how many potential modules (candidates without __init__.py) it didn't import. I didn't really try to analyze any conditions, instead I simply assumed that wherever ImportWarning would be issued, we have a suitable candidate, and saved it on the stack. If nothing is found, Python emits ImportWarning right before ImportError, and explains what happened. ---------------------------------------------------------------------- Comment By: Sergey (sergeyli) Date: 2006-07-01 14:11 Message: Logged In: YES user_id=141494 This one also doesn't have the memory leak fix mentioned in python.org/sf/1515361. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515609&group_id=5470 From noreply at sourceforge.net Sun Jul 2 08:35:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Jul 2006 23:35:30 -0700 Subject: [Patches] [ python-Patches-1515745 ] urllib2 redirection fix Message-ID: Patches item #1515745, was opened at 2006-07-02 13:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Gladkikh (batyi) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 redirection fix Initial Comment: When redirecting to a new URL, new request is missing attached data (e.g. when redirecting POST or PUT). Thus redirected request will be different than original one. The patch fixes this problem. My environment is: OS: WindowsXP, Python version: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 From noreply at sourceforge.net Mon Jul 3 04:10:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Jul 2006 19:10:34 -0700 Subject: [Patches] [ python-Patches-1515745 ] urllib2 redirection fix Message-ID: Patches item #1515745, was opened at 2006-07-02 02:35 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Gladkikh (batyi) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 redirection fix Initial Comment: When redirecting to a new URL, new request is missing attached data (e.g. when redirecting POST or PUT). Thus redirected request will be different than original one. The patch fixes this problem. My environment is: OS: WindowsXP, Python version: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-02 22:10 Message: Logged In: YES user_id=764593 With a POST (and presumably a PUT), this is required by the standard. I won't argue that it is sensible (why would you send the data to someone whose redirects you don't trust), but it is the standard. Making this a settable option would probably be OK, though. -jJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 From noreply at sourceforge.net Mon Jul 3 04:12:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Jul 2006 19:12:24 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 17:49 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Anthony Baxter (anthonybaxter) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-07-02 22:12 Message: Logged In: YES user_id=764593 I forgot to mention in this tracker that this is a regression against 2.4, so it should be fixed even post- beta, unless we decide to never fix it as part of deprecation. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-01 07:21 Message: Logged In: YES user_id=764593 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-01 07:19 Message: Logged In: NO ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:53 Message: Logged In: YES user_id=764593 For misc/news, I suggest something like "Fixed an obscure traceback regression when (deprecated) strings are raised." ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:52 Message: Logged In: YES user_id=764593 In order to fix it, I also broke out some repeated code into a subfunction, and switched some logic to a more modern idiom -- these parts *could* be separated if need be, but I won't be able to do it this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 From noreply at sourceforge.net Mon Jul 3 10:59:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 01:59:09 -0700 Subject: [Patches] [ python-Patches-1484695 ] tarfile.py fix for #1471427 and updates Message-ID: Patches item #1484695, was opened at 2006-05-09 15:51 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for #1471427 and updates Initial Comment: I have assembled a patch that adds some features from my own development path of tarfile.py (http://www.gustaebel.de/lars/tarfile/) and fixes #1471427 which made some restructuring necessary. The patch affects Lib/tarfile.py, Lib/test/test_tarfile.py and Doc/lib/libtarfile.tex. The changes the patch makes are as follows: Sets the version to 0.8.0. Support for base256 encoding of number fields (nti() and itn()). Up to now this was hardcoded for the filesize field to allow filesizes greater than 8 GB but it is applicable to all number fields. TarInfo.tobuf() has a boolean argument "posix" which controls how number fields are written (base256 is non-posix). Both unsigned and signed (Sun and NeXT) checksums are calculated. Header validation moves from TarFile.next() to TarInfo.frombuf(). A header is valid only if its checksum is okay, in the past the checksum was calculated but ignored. The TarFile.next() method was rearranged which makes header processing clearer and more abstract and fixes bug #1471427. However, this change breaks the interface for subclassing in order to implement custom member types but makes it much easier at the same time. The mapping TYPE_METH was removed. A new test ReadGNULongTest was added to test_tarfile.py and testtar.tar was updated to be able to test the GNU extensions LONGNAME and LONGLINK. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-03 10:59 Message: Logged In: YES user_id=642936 I would like to emphasize on point (2) of my previous post, which should be resolved before 2.5 comes out. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-18 12:00 Message: Logged In: YES user_id=642936 On (1): agreed. On (2): There is still a debug message emitted for a bad checksum: In TarInfo.frombuf() at the bottom a ValueError is raised if they don't match and is passed on to TarFile.next() where it is put out as a debug message using the _dbg() method in the except clause. The debug message where it is now (r46040) is senseless because the try-block will be left when TarInfo.frombuf() fails . On (3): You're right, I attached a patch that adds another Exception HeaderError which is raised in TarInfo.frombuf() instead of ValueError in case of a bad header. I hope that is acceptable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-18 08:11 Message: Logged In: YES user_id=849994 Jim: I agree with your comments and have committed an improved version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:25 Message: Logged In: YES user_id=764593 (1) Why change the exception style? When raising an instance, the style guide (PEP-8, http:// www.python.org/dev/peps/pep-0008/) prefers to construct that instance; the older form is left over from String exceptions and will be removed in Python 3. I could understand leaving them as they were, but if you're going to change them to make them consistent, why not use the current format? (2) Why get rid of the debug messages (such as the checksum check) entirely? Guarding them in if self.debug, I would understand. (3) I wouldn't count on str(e) (where e is any ValueError instance) being as meaningful as the (current version's) ReadError("empty, unreadable or compressed file") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-10 18:26 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 45954. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-09 15:52 Message: Logged In: YES user_id=642936 Here is testtar.tar to replace Lib/test/testtar.tar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 From noreply at sourceforge.net Mon Jul 3 12:06:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 03:06:00 -0700 Subject: [Patches] [ python-Patches-1514737 ] proposal for a new circle method Message-ID: Patches item #1514737, was opened at 2006-06-30 00:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: proposal for a new circle method Initial Comment: The attached file contains the proposal for (1) a new circle method (here called circle2) (2) a new circle function (also called circle2) Moreover it contains a testscript showing the respective3 filling behaviour. Visually they behave differently and it may well be a point of discussion if this replacement schould be made. circle2 has correct filling behaviour and doesn't show the strange 'not drawing feature' after a radians() call. All the other problems with radians()/degrees() remain. (see #1514685) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-03 12:06 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r47209. ---------------------------------------------------------------------- Comment By: Lingl (gregorlingl) Date: 2006-06-30 21:23 Message: Logged In: YES user_id=1547199 A misinterpretation: I think it *should* become the circle method. (It were a weird idea to introduce a circle2 method anyway). I only named it circle2 for now and test purposes in order to compare the behaviours of the two. If you are content with the patch, replace circle by circle2 'as circle' - if not leave circle2 out and let everything as is. Imho the the points to think about are: (i) is the polygon approximation ok? I think, my testscript gives a positive answer: the polygons are visually nearly indistiguishable from the canvas circle items. (Moreover I tested it with radiuses in the range from 1 to 200 successfully) (ii)that the new method relies on the forward method and thus circles are drawn much slower. For me this is quite ok. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-30 18:44 Message: Logged In: YES user_id=21627 New methods are not acceptable for Python 2.5 at this point. Can you think of a reason why this should *not* become the circle method? I understand that this fixes a bug, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514737&group_id=5470 From noreply at sourceforge.net Mon Jul 3 14:47:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 05:47:33 -0700 Subject: [Patches] [ python-Patches-1516309 ] Remove deprecated functions from operator Message-ID: Patches item #1516309, was opened at 2006-07-03 08:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove deprecated functions from operator Initial Comment: This patch removes the isCallable() and sequenceIncludes() functions from the operator module. These functions have been deprecated since Python 2.0. This patch is against r47214. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516309&group_id=5470 From noreply at sourceforge.net Mon Jul 3 15:04:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 06:04:00 -0700 Subject: [Patches] [ python-Patches-825417 ] telnetlib timeout fix (bug 822974) Message-ID: Patches item #825417, was opened at 2003-10-17 12:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=825417&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Johan M. Hahn (johahn) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib timeout fix (bug 822974) Initial Comment: Timeout behaviour do not match the docs. This patch fixes the read_until and expect methods to decreese the timeout between subsequent calls to select.select. See <a href="http://sourceforge.net/tracker/index.php? func=detail&aid=822974&group_id=5470&atid=105470">bu g 822974</a> for more info. My system: Python 2.3 final Windows 2000 5.00.2951 sp4 ...johahn ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-03 15:04 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r47215 and 47216 (for 2.4). ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 11:36 Message: Logged In: YES user_id=887415 Uploaded some simple code for producing the bug and also testing the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=825417&group_id=5470 From noreply at sourceforge.net Mon Jul 3 15:22:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 06:22:43 -0700 Subject: [Patches] [ python-Patches-1516327 ] Module uuid: reduce pickle footprint Message-ID: Patches item #1516327, was opened at 2006-07-03 15:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516327&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Amrhein (mamrhein) Assigned to: Nobody/Anonymous (nobody) Summary: Module uuid: reduce pickle footprint Initial Comment: In order to reduce the pickle footprint of UUIDs I would add a __reduce__ method to class UUID like def __reduce__(self): return (uuid, (self.int,)) together with a helper function (at module level) like def uuid(i): return UUID(int=i) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516327&group_id=5470 From noreply at sourceforge.net Mon Jul 3 15:26:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 06:26:13 -0700 Subject: [Patches] [ python-Patches-1516330 ] Module uuid: functions for retrieving MAC addres Message-ID: Patches item #1516330, was opened at 2006-07-03 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516330&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Amrhein (mamrhein) Assigned to: Nobody/Anonymous (nobody) Summary: Module uuid: functions for retrieving MAC addres Initial Comment: I've written functions to retrieve the MAC address that do not depend on running external programs. Please see the attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516330&group_id=5470 From noreply at sourceforge.net Mon Jul 3 15:32:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 06:32:13 -0700 Subject: [Patches] [ python-Patches-1368955 ] UUID module for Python Message-ID: Patches item #1368955, was opened at 2005-11-29 08:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ka-Ping Yee (ping) Assigned to: Nobody/Anonymous (nobody) Summary: UUID module for Python Initial Comment: I recently tossed off a module to generate UUIDs because i needed one. Fredrik Lundh suggested i submit it here for inclusion in the standard library. See http://zesty.ca/python/uuid.html for a pydoc page. The module provides a UUID class for representing UUIDs and can generate version 1, 3, 4, or 5 UUIDs. One drawback of the implementation is that it currently runs external programs ("ipconfig" or "ifconfig") to obtain the Ethernet hardware address used in a version 1 UUID. The version 1 UUID implementation also does not use persistent storage to determine the clock sequence number. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-03 13:32 Message: Logged In: YES user_id=849994 This module was now added to the stdlib. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-07 18:57 Message: Logged In: YES user_id=34892 Would require a C extension but perhaps this could be used to get the MAC address on Windows instead of running and grepping (unreliable for different locales as Thomas pointed out) ipconfig.exe: http://support.microsoft.com/default.aspx?scid=kb;en-us;118623 How To Get the MAC Address for an Ethernet Adapter ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-07 18:28 Message: Logged In: YES user_id=34892 > use something like webbrowser._iscommand I have a Python implementation of `which`: http://trentm.com/projects/which/ http://trentm.com/projects/which/which.py though that is likely overkill for this case. ---------------------------------------------------------------------- Comment By: Trent Mick (tmick) Date: 2006-03-07 18:20 Message: Logged In: YES user_id=34892 > On Win 2k, "C:\WINNT" is used instead of XP-like > "C:\windows". Perhaps uuid.py could use the "windir" environment variable. It is defined on (at least) WinXP, Win2k, WinMe that I could check and points to C:\WINDOWS (on WinXP and WinMe) and C:\WINNT (on Win2k). It would first be good to verify if it is defined on WinNT and Win9x. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-07 17:58 Message: Logged In: YES user_id=849994 Instead of hardcoding directories for ipconfig, why not try spawnp directly on UNIX or use something like webbrowser._iscommand? Minor nit: a,b,c = [1,2,3] is better a,b,c=1,2,3 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-03-07 16:27 Message: Logged In: YES user_id=671362 One more thing about getaddr function. On Win 2k, "C:\WINNT" is used instead of XP- like "C:\windows". (If I remember correctly, Win 2k is still supportted. Am I right?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=31435 On c.l.py, Thomas Heller noted: """ I haven't used this module, but: The wingetaddr() function doesn't work on a german version of windows (there is no line in the output that starts with 'physical address'). In getaddr(), what if windows is installed on the D: drive? """ ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-03-07 08:06 Message: Logged In: YES user_id=210337 We had some minor problems backporting this to Python 2.3; this fixed it: - uuid = UUID(randrange(1<<32L), randrange(1<<16), randrange(1<<16), - randrange(1<<8), randrange(1<<8), randrange(1<<48L)) + uuid = UUID(randrange(1<<32), randrange(1<<16), randrange(1<<16), + randrange(1<<8), randrange(1<<8), randrange(1<<48)) I'm not sure what the most current version looks like, so this might not be a problem anymore (e.g. if the values get precalculated) ---------------------------------------------------------------------- Comment By: Michael Str?der (stroeder) Date: 2005-12-07 23:47 Message: Logged In: YES user_id=64920 I'd like to see some constants pre-calculated for gaining performance, e.g. during mass data handling. E.g. the MAC address should only determined once after startup. Or at least as key-word argument so that the caller can decide to cache the MAC address. def uuid1(node=None): [..] node = node or getaddr() ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-30 11:54 Message: Logged In: YES user_id=45338 This update fixes the order of the bytes in a hash-generated UUID. With this fix, the interpretation of RFC 4122 is that "octet 0" refers to the MOST significant octet, i.e. the one printed on the left. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-29 09:14 Message: Logged In: YES user_id=45338 This update fixes __repr__ to return a proper expression and adds the use of os.urandom (if available) to generate randomness for version 4 UUIDs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1368955&group_id=5470 From noreply at sourceforge.net Mon Jul 3 15:32:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 06:32:46 -0700 Subject: [Patches] [ python-Patches-1516327 ] Module uuid: reduce pickle footprint Message-ID: Patches item #1516327, was opened at 2006-07-03 13:22 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516327&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Amrhein (mamrhein) >Assigned to: Ka-Ping Yee (ping) Summary: Module uuid: reduce pickle footprint Initial Comment: In order to reduce the pickle footprint of UUIDs I would add a __reduce__ method to class UUID like def __reduce__(self): return (uuid, (self.int,)) together with a helper function (at module level) like def uuid(i): return UUID(int=i) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516327&group_id=5470 From noreply at sourceforge.net Mon Jul 3 15:32:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 06:32:56 -0700 Subject: [Patches] [ python-Patches-1516330 ] Module uuid: functions for retrieving MAC addres Message-ID: Patches item #1516330, was opened at 2006-07-03 13:26 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516330&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Amrhein (mamrhein) >Assigned to: Ka-Ping Yee (ping) Summary: Module uuid: functions for retrieving MAC addres Initial Comment: I've written functions to retrieve the MAC address that do not depend on running external programs. Please see the attached file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516330&group_id=5470 From noreply at sourceforge.net Mon Jul 3 16:30:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 07:30:44 -0700 Subject: [Patches] [ python-Patches-1516375 ] Remove sys.exitfunc Message-ID: Patches item #1516375, was opened at 2006-07-03 10:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove sys.exitfunc Initial Comment: As mentioned in PEP 3100, this patch removes the interpreter's support for sys.exitfunc. This patch is against r47222. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516375&group_id=5470 From noreply at sourceforge.net Mon Jul 3 17:21:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 08:21:30 -0700 Subject: [Patches] [ python-Patches-1221598 ] ftplib storbinary/storlines callback function Message-ID: Patches item #1221598, was opened at 2005-06-16 01:15 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 5 Submitted By: Phil Schwartz (phil_schwartz) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib storbinary/storlines callback function Initial Comment: The ftplib.FTP class currently allows the ability to provide a callback function for the retrbinary & retrlines methods to invoke. However, the corresponding storbinary and storlines methods do not. My ReleaseForge application currently uses the ftplib to send files (rather than retrieve) and it's helpful to know the percentage of the file that has been sent. For my app I subclassed ftplib.FTP and reimplemented storbinary to optionally accept a callback function as a parameter. However, I think this would be a useful method to include in the standard python distribution. I've attached a modified version of ftplib.py which adds this functionality. Unlike the retrX methods, the storX methods only invoke the callback function if it's not None so that it will not interfere with existing code. For completeness, the retrX methods invoke print_line if a callback function is not provided and doing so for the storX functions may be undesired. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 09:52 Message: Logged In: YES user_id=849994 Please provide your patch as a diff between the original ftplib.py and your version. It greatly helps reviewers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1221598&group_id=5470 From noreply at sourceforge.net Mon Jul 3 17:24:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 03 Jul 2006 08:24:07 -0700 Subject: [Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!) Message-ID: Patches item #732401, was opened at 2003-05-05 01:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 6 Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: Allows os.forkpty to work on more platforms (Solaris!) Initial Comment: Recent changes to os.openpty() make it much more portable than earlier versions. Unfortunately, os.forkpty() was not also upgraded. This patch to posixpath.c allows os.forkpty() to run on any platform that supports os.openpty(). This new os.forkpty() will use the C system call forkpty() if available. If not available, then it will do it the old fashioned way with openpty and fork (and only if those too are available, otherwise forkpty remains undefined as before). Other benefits: Since the pty module is based on os.forkpty() this patch will automatically allow pty.fork() to work properly on more platforms. The pty module does not need to be changed. The logic for supporting pty's on multiple platforms can be maintained in one spot instead of in both the posix_module.c and pty.py One of the more notable platforms that does not support the forkpty system call is Solaris. Most importantly to me, this patch will allow os.forkpty() to be available under Solaris. I am testing it with my Pexpect module which makes heavy use of the pty module. With this patch Pexpect passes all my unit tests on Solaris. Pexpect has been tested on Linux, OpenBSD, Solaris, and Cygwin. I'm looking for an OS X server to test with. The code for forkpty should be quite portable and is based on the pty code in OpenSSH and the example in Stevens' "Advanced Programming in the UNIX Environment". I have included a test script, test_forkpty.py. Yours, Noah <pre> # Test to see if forkpty works. (But don't worry if it isn't available.) import os, time from test.test_support import verbose, TestFailed, TestSkipped try: if verbose: print 'Calling os.forkpty()' pid, fd = os.forkpty() except AttributeError: raise TestSkipped, 'No os.forkpty() available.' if pid == 0: # child print 'I am not a robot!' else: if verbose: print '(pid, fd) = (%d, %d)' % (pid, fd) time.sleep(1) # Give the child a chance to print. print 'Robots always say:', os.read(fd,100) os.close(fd) </pre> ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-03 17:24 Message: Logged In: YES user_id=21627 As announced before, I'm now rejecting the patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-03-28 20:17 Message: Logged In: YES user_id=21627 In the absence of a patch that is known to work on all relevant platforms, there is nothing really to revisit. Most likely, the next action on this patch is to reject it, unless somebody steps forward to do the remaining work. ---------------------------------------------------------------------- Comment By: Richard A. Holden III (aciddeath) Date: 2005-03-22 20:49 Message: Logged In: YES user_id=591527 Would it be possible to revisit this since we are now on 2.4? I am developing on pexpect and having this would greatly simplify my life. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-10-13 19:46 Message: Logged In: YES user_id=29957 Google for "HP testdrive". DEC^W Digital^W Compaq^W HP have a farm of test systems you can use for testing. ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2003-09-03 22:07 Message: Logged In: YES user_id=59261 Is there a place where a prospective developer can test on these 8 platforms? I read the Developer FAQ and have been going through the School of Hard Knocks: http://mail.python.org/pipermail/python-dev/2002- September/028725.html I would like to work with someone on this as I only have access to the platforms on Compile Farm from SourceForge. The fact that ptmx support causes HP-UX to hang is probably a simple configuration problem (perhaps incorrectly defining HAVE_DEV_PTMX), but it's impossible for me to research this using only the Compile Farm. Yours, Noah ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-07-13 22:27 Message: Logged In: YES user_id=21627 The addition of support for ptmx inside posix.openpty has caused the test suite to hang on HP-UX and other systems. A good strategy would be to find some code base, and rigorously test these on all 8 or so supported Unix variants. I'm willing to accept any code that has been tested so, but only after Python 2.3. ---------------------------------------------------------------------- Comment By: Noah Spurrier (noah) Date: 2003-07-13 21:52 Message: Logged In: YES user_id=59261 Which openpty has made pty handling unusable? There are two: os.openpty() and pty.openpty(). What is a good strategy for making pty handling more consistent? I think it's impossible to make pty handling totally platform independent, but Python's pty module could certainly be cleaned up to hide the ugliness. Platforms that are not explicitly handled should probably not define forkpty. Currently Solaris uses the wrong code -- thus leaving the user with the impression that Solaris is supported, but providing a broken implementation. Pty handling is a headache -- I never understood why it was overlooked by POSIX given that ptys are critical to every UNIX system. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2003-07-13 17:08 Message: Logged In: YES user_id=21627 It should be deferred. Mere addition of openpty has nearly made the entire pty handling nearly unusable on some systems, as the C library versions of these functions tend to be buggy beyond repair. So I'd rather don't add any more breakage here. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2003-07-13 16:06 Message: Logged In: YES user_id=250749 Martin, I've eyeballed the patch and can't see that it would have any effect other than to extend the availability of os.forkpty (assuming that it compiles on all the platforms that it extends to). FreeBSD has forkpty(), so I can't test this myself (I haven't tried to set up a SF compile farm account yet). I'm a little wary about it being this close to 2.3 release - is this worth pursuing at this point, or should it be deferred to post-2.3? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470 From noreply at sourceforge.net Tue Jul 4 11:08:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Jul 2006 02:08:49 -0700 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-09 22:05 Message generated for change (Comment added) made by mattcomms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- Comment By: matt (mattcomms) Date: 2006-07-04 09:08 Message: Logged In: YES user_id=1543599 Hello, Wondering if your still offering some support. As people have reported success with 2.4.2 I decided to use that version. I have been carefull to follow the steps as described but still having some difficulty. The steps I take are: patch -p3 < ../python-patch autoconf configure.in >configure mkdir cross-build cd cross-build ../configure --host=cris-axis-linux-gnu --build=i486-slackware-linux I also edit the LINKCC line in the makefile and include -static (as I want to run on devboard with limited memory and not to worry about shared libraries) make throws lots of errors like: *** WARNING: renaming "struct" since importing it failed: build/lib.linux-i686-2.4/struct.so: cannot open shared object file: No such file or directory building 'regex' extension cris-axis-linux-gnu-gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/root/Python-2.4.2/./Include -I/usr/local/include -I/root/Python-2.4.2/cross-build/Include -I/root/Python-2.4.2/cross-build/buildpython -c /root/Python-2.4.2/Modules/regexmodule.c -o build/temp.linux-i686-2.4/regexmodule.o cris-axis-linux-gnu-gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/root/Python-2.4.2/./Include -I/usr/local/include -I/root/Python-2.4.2/cross-build/Include -I/root/Python-2.4.2/cross-build/buildpython -c /root/Python-2.4.2/Modules/regexpr.c -o build/temp.linux-i686-2.4/regexpr.o cris-axis-linux-gnu-gcc -shared build/temp.linux-i686-2.4/regexmodule.o build/temp.linux-i686-2.4/regexpr.o -L/usr/local/lib -o build/lib.linux-i686-2.4/regex.so and cris-axis-linux-gnu-gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/root/Python-2.4.2/./Include -I/usr/local/include -I/root/Python-2.4.2/cross-build/Include -I/root/Python-2.4.2/cross-build/buildpython -c /root/Python-2.4.2/Modules/_ssl.c -o build/temp.linux-i686-2.4/_ssl.o /root/Python-2.4.2/Modules/_ssl.c:30:25: openssl/rsa.h: No such file or directory make install prefix=/root/Python-2.4.2/cross-build throws the same errors but finishes. I then mount cross-build via nfs and run python Python 2.4.2 (#2, Jun 28 2006, 18:35:28) [GCC 3.2.1 Axis release R61/1.61] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time import time Traceback (most recent call last): File "", line 1, in ? ImportError: /mnt/flash/Python/lib/python2.4/lib-dynload/time.so: undefined symbol: PyExc_IOError >>> >>> import socket import socket Traceback (most recent call last): File "", line 1, in ? File "/mnt/flash/Python/lib/python2.4/socket.py", line 45, in ? import _socket ImportError: /mnt/flash/Python/lib/python2.4/lib-dynload/_socket.so: undefined symbol: PyObject_GenericGetAttr Any hint as to what might be causing these errors would be most appreciated. Cheers Matthew ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-03-07 21:45 Message: Logged In: YES user_id=843814 I use this command: make install prefix=/my/temp/dir ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-03-07 21:30 Message: Logged In: YES user_id=1330285 Hi again, It seems I'm successfull in cross-compiling python. But I'm not sure of what I have to save on the host platform. There is python executable of course. But there is no lib directory with .so files and .py files in the directory where python is built. Can you tell me what files/directories you save on your host platform ? Thanks again for your support. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-03-06 15:12 Message: Logged In: YES user_id=843814 Hi hugo. The problems you are having are less python related and more system-building/cross-development issues, and this is the wrong forum for hashing out this stuff out. I recommend building a linux-from-scratch system (http://www.linuxfromscratch.org/) on an ordinary PC to learn how the insides of linux machine works and how to fix things when they go wrong. Good luck, Dan. ---------------------------------------------------------------------- Comment By: hugo (hugo_koopmans) Date: 2006-03-04 20:02 Message: Logged In: YES user_id=1229536 Hi there, I am trying to cross compile python on the fox board (etrax). now everything seemed to go well but when running the python binary is says: ./python: error while loading shared libraries: libstdc++.so.5: cannot load shared object file: No such file or directory I only ftp-ed the python bin not the (much bigger) libpython2.4a .... seems this is a library archive of some kind ? do i need it? how do i use it then? thanx a million if you can help me out. hugo ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 22:32 Message: Logged In: YES user_id=843814 You didn't apply the patch properly. See the other messages about the use of the -p option. Start with a fresh source tree and use: cd Python-2.4.2 patch -p3 <../python-patch.txt ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 21:37 Message: Logged In: YES user_id=1330285 If I try to aplly the patch again, I get messages saying a patch has allready been applied. To apply the patch I executed the following : cd Python-2.4.2 patch <../python-patch.txt ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 21:30 Message: Logged In: YES user_id=843814 The build system python should be in "MyPython/buildpython", and the host python should just be in "MyPython" Are you sure you applied the patch right? What you're getting is what would happen if you didn't apply the patch at all. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 21:19 Message: Logged In: YES user_id=1330285 Yes I guess. But it seems that all I get is for the build system. If I try to execute on the build system ./python it runs. Also, there is no hostbuild subdirectory. Is it ok ? Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 21:14 Message: Logged In: YES user_id=843814 > I then cd to a "MyPython" directory. > I call ../Python-2.4.2/configure ... Then your files should be in your "MyPython" directory. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 20:54 Message: Logged In: YES user_id=1330285 Me again, sorry... What Should I get after compilation has finished ? Where are the files for my target ? Nicolas ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 19:55 Message: Logged In: YES user_id=1330285 Hi again, I finaly dad enought time to work on my project. So, I compiled autoconf tools for my system. Then, I rerun all the steps successfully. Thanks again for your help. Nicolas ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 15:12 Message: Logged In: YES user_id=1081828 You are right, I have misunderstood --build and --host signification. And I also forgotten to run autoconf partialy because I don't have autoconf installed on my system. So I didn't pay attention it didn't run. Thanks for your help. I'll let you know if this works in a few days. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 14:51 Message: Logged In: YES user_id=843814 Did you run autoconf after patching as instructed? Also, your --build and --host options seem backwards. host is the arch you want python to run on, build is the arch you build python on. Cheers, Dan. ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 12:38 Message: Logged In: YES user_id=1081828 Hi, I try to cross compile Python-2.4.2 for an etrax processor. I have successfully applied the patch to Python sources. I then cd to a "MyPython" directory. I call ../Python-2.4.2/configure --build cris --host i386-linux It works ok (did not see an error) I all make I get the following error after a while : make : *** No rule to make target '@BUILDPGEN@', needed by '../Python-2.4.2/Include/graminit.h'. Stop. Any Idea ? Nicolas ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 14:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 11:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 10:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 17:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 16:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 16:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 15:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 14:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 14:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 02:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 11:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 17:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 20:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 16:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-21 01:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Tue Jul 4 13:15:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Jul 2006 04:15:40 -0700 Subject: [Patches] [ python-Patches-1516912 ] OpenVMS patches Modules directory Message-ID: Patches item #1516912, was opened at 2006-07-04 13:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516912&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Pi?ronne Jean-Fran?ois (pieronne) Assigned to: Nobody/Anonymous (nobody) Summary: OpenVMS patches Modules directory Initial Comment: All the patches are delimited by #if defined(__VMS) #endif or some variant of this 8 files are patches: bz2module.c OpenVMS don't support univ_newline so set f_univ_newline to 0 cryptmodule.c OpenVMS don't have a crypt routine, so use the openssl routine instead dlmodule.c OpenVMS CRTL dlopen routine doesn't do any check so in routine dl_open add a test for file accessibility fpectlmodule.c Add the correct setting for Alpha and IA64 processor getpath.c remove old patch and add default PREFIX posixmodule.c OpenVMS don't have any urandom routine, so use the openssl routine instead selectmodule.c clean an old previous patch, move most of the specific VMS code to specific routine (would be probably cleaner) Regards, Jean-Fran??ois ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516912&group_id=5470 From noreply at sourceforge.net Tue Jul 4 18:39:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Jul 2006 09:39:01 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 12:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Tue Jul 4 18:48:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Jul 2006 09:48:45 -0700 Subject: [Patches] [ python-Patches-1006238 ] cross compile patch Message-ID: Patches item #1006238, was opened at 2004-08-09 17:05 Message generated for change (Comment added) made by goertzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Daniel Goertzen (goertzen) Assigned to: Nobody/Anonymous (nobody) Summary: cross compile patch Initial Comment: Here's a cross compile patch I prepared a while ago but never got around to submitting. I've been using it happily for months to cross compile python for embedded systems. Below is a descriptive excerpt from the patch. Also note that the patch modifies configure.in, but not configure. You will need to regenerate configure with something like autoconf configure.in >configure This patch is inpsired from work by Klaus Reimer at http://www.ailis.de/~k/docs/crosscompiling/python.php + Cross Compiling + --------------- + + Python can be cross compiled by supplying different --host and --build + parameters to configure. (Python is compiled on the "build" system + and executed on the "host" system, in case you forgot :). Python is + tricky to cross compile because it needs to execute parts of itself + during construction. To work around this, make's VPATH feature is + used to compile a native python in the subdirectory "buildpython". + When parts of python need to be executed during construction, the + "buildpython" versions are used. + + A consequence of using the VPATH feature is that you may not do a + cross compile build in the source directory. In other words, do this: + + mkdir mydir + cd mydir + ../Python/configure --host=powerpc-405-linux-gnu --build=i686-pc-linux-gnu + make + + Cross compiling works well under linux, mileage may vary for other + platforms. + + A few reminders on using configure to cross compile: + - Cross compile tools must be in the PATH. + - Cross compile tools must be prefixed with the host type + (ie powerpc-405-linux-gnu-cc, powerpc-405-linux-gnu-ranlib, ...) + - CC, CXX, AR, and RANLIB must be undefined when running configure and + make. Configure will detect them. + + If you need a cross compiler, check out Dan Kegel's crosstool: + http://www.kegel.com/crosstool + + ---------------------------------------------------------------------- >Comment By: Daniel Goertzen (goertzen) Date: 2006-07-04 11:48 Message: Logged In: YES user_id=843814 This stuff is becoming hazy for me, but I'll try to offer some ideas: - Does it help if you put your build directory outside of the source directory? - Why is the system looking for struct.so when you told it to be static? I suspect static support is broken for a lot of modules. Does it go better when you take the static switch out? Assuming you have a few other apps in your system besides python (a shell, busybox maybe), I question wether static would actually save any memory. It perhaps is a little more complex to get all the libraries in their correct location, but I'll bet coaxing a python system to be static is way harder. - It is normal for some things to bomb out while compiling because the python build scripts always check the build system for library availability. In many cases you don't need those broken libraries. It is also often possible to hack up the install scripts to work properly for a cross compiled system. That said, simple things like struct should be working properly without hackery. Cheers, Dan. ---------------------------------------------------------------------- Comment By: matt (mattcomms) Date: 2006-07-04 04:08 Message: Logged In: YES user_id=1543599 Hello, Wondering if your still offering some support. As people have reported success with 2.4.2 I decided to use that version. I have been carefull to follow the steps as described but still having some difficulty. The steps I take are: patch -p3 < ../python-patch autoconf configure.in >configure mkdir cross-build cd cross-build ../configure --host=cris-axis-linux-gnu --build=i486-slackware-linux I also edit the LINKCC line in the makefile and include -static (as I want to run on devboard with limited memory and not to worry about shared libraries) make throws lots of errors like: *** WARNING: renaming "struct" since importing it failed: build/lib.linux-i686-2.4/struct.so: cannot open shared object file: No such file or directory building 'regex' extension cris-axis-linux-gnu-gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/root/Python-2.4.2/./Include -I/usr/local/include -I/root/Python-2.4.2/cross-build/Include -I/root/Python-2.4.2/cross-build/buildpython -c /root/Python-2.4.2/Modules/regexmodule.c -o build/temp.linux-i686-2.4/regexmodule.o cris-axis-linux-gnu-gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/root/Python-2.4.2/./Include -I/usr/local/include -I/root/Python-2.4.2/cross-build/Include -I/root/Python-2.4.2/cross-build/buildpython -c /root/Python-2.4.2/Modules/regexpr.c -o build/temp.linux-i686-2.4/regexpr.o cris-axis-linux-gnu-gcc -shared build/temp.linux-i686-2.4/regexmodule.o build/temp.linux-i686-2.4/regexpr.o -L/usr/local/lib -o build/lib.linux-i686-2.4/regex.so and cris-axis-linux-gnu-gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -I. -I/root/Python-2.4.2/./Include -I/usr/local/include -I/root/Python-2.4.2/cross-build/Include -I/root/Python-2.4.2/cross-build/buildpython -c /root/Python-2.4.2/Modules/_ssl.c -o build/temp.linux-i686-2.4/_ssl.o /root/Python-2.4.2/Modules/_ssl.c:30:25: openssl/rsa.h: No such file or directory make install prefix=/root/Python-2.4.2/cross-build throws the same errors but finishes. I then mount cross-build via nfs and run python Python 2.4.2 (#2, Jun 28 2006, 18:35:28) [GCC 3.2.1 Axis release R61/1.61] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time import time Traceback (most recent call last): File "", line 1, in ? ImportError: /mnt/flash/Python/lib/python2.4/lib-dynload/time.so: undefined symbol: PyExc_IOError >>> >>> import socket import socket Traceback (most recent call last): File "", line 1, in ? File "/mnt/flash/Python/lib/python2.4/socket.py", line 45, in ? import _socket ImportError: /mnt/flash/Python/lib/python2.4/lib-dynload/_socket.so: undefined symbol: PyObject_GenericGetAttr Any hint as to what might be causing these errors would be most appreciated. Cheers Matthew ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-03-07 15:45 Message: Logged In: YES user_id=843814 I use this command: make install prefix=/my/temp/dir ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-03-07 15:30 Message: Logged In: YES user_id=1330285 Hi again, It seems I'm successfull in cross-compiling python. But I'm not sure of what I have to save on the host platform. There is python executable of course. But there is no lib directory with .so files and .py files in the directory where python is built. Can you tell me what files/directories you save on your host platform ? Thanks again for your support. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-03-06 09:12 Message: Logged In: YES user_id=843814 Hi hugo. The problems you are having are less python related and more system-building/cross-development issues, and this is the wrong forum for hashing out this stuff out. I recommend building a linux-from-scratch system (http://www.linuxfromscratch.org/) on an ordinary PC to learn how the insides of linux machine works and how to fix things when they go wrong. Good luck, Dan. ---------------------------------------------------------------------- Comment By: hugo (hugo_koopmans) Date: 2006-03-04 14:02 Message: Logged In: YES user_id=1229536 Hi there, I am trying to cross compile python on the fox board (etrax). now everything seemed to go well but when running the python binary is says: ./python: error while loading shared libraries: libstdc++.so.5: cannot load shared object file: No such file or directory I only ftp-ed the python bin not the (much bigger) libpython2.4a .... seems this is a library archive of some kind ? do i need it? how do i use it then? thanx a million if you can help me out. hugo ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 16:32 Message: Logged In: YES user_id=843814 You didn't apply the patch properly. See the other messages about the use of the -p option. Start with a fresh source tree and use: cd Python-2.4.2 patch -p3 <../python-patch.txt ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 15:37 Message: Logged In: YES user_id=1330285 If I try to aplly the patch again, I get messages saying a patch has allready been applied. To apply the patch I executed the following : cd Python-2.4.2 patch <../python-patch.txt ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:30 Message: Logged In: YES user_id=843814 The build system python should be in "MyPython/buildpython", and the host python should just be in "MyPython" Are you sure you applied the patch right? What you're getting is what would happen if you didn't apply the patch at all. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 15:19 Message: Logged In: YES user_id=1330285 Yes I guess. But it seems that all I get is for the build system. If I try to execute on the build system ./python it runs. Also, there is no hostbuild subdirectory. Is it ok ? Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 15:14 Message: Logged In: YES user_id=843814 > I then cd to a "MyPython" directory. > I call ../Python-2.4.2/configure ... Then your files should be in your "MyPython" directory. ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 14:54 Message: Logged In: YES user_id=1330285 Me again, sorry... What Should I get after compilation has finished ? Where are the files for my target ? Nicolas ---------------------------------------------------------------------- Comment By: Nicolas (nico0438) Date: 2006-02-24 13:55 Message: Logged In: YES user_id=1330285 Hi again, I finaly dad enought time to work on my project. So, I compiled autoconf tools for my system. Then, I rerun all the steps successfully. Thanks again for your help. Nicolas ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 09:12 Message: Logged In: YES user_id=1081828 You are right, I have misunderstood --build and --host signification. And I also forgotten to run autoconf partialy because I don't have autoconf installed on my system. So I didn't pay attention it didn't run. Thanks for your help. I'll let you know if this works in a few days. Nicolas ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-02-24 08:51 Message: Logged In: YES user_id=843814 Did you run autoconf after patching as instructed? Also, your --build and --host options seem backwards. host is the arch you want python to run on, build is the arch you build python on. Cheers, Dan. ---------------------------------------------------------------------- Comment By: nicolas pinault (nico38) Date: 2006-02-24 06:38 Message: Logged In: YES user_id=1081828 Hi, I try to cross compile Python-2.4.2 for an etrax processor. I have successfully applied the patch to Python sources. I then cd to a "MyPython" directory. I call ../Python-2.4.2/configure --build cris --host i386-linux It works ok (did not see an error) I all make I get the following error after a while : make : *** No rule to make target '@BUILDPGEN@', needed by '../Python-2.4.2/Include/graminit.h'. Stop. Any Idea ? Nicolas ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-10 08:45 Message: Logged In: YES user_id=1420135 I have resolved my question,now I can run python on the mips machine,and can run some binary build by python.Can I also cross compile pygame for python?But the pygame source does't has 'configure' and 'Makefiel' files,setup.py instead in source package.How should I do? Thanks :-) ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 05:08 Message: Logged In: YES user_id=1420135 If you have accounts of MSN,please add me.My accounts is xudong_888 at hotmail.com. I am very impatient.I hope I can get some help from you.Thanks. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-06 04:57 Message: Logged In: YES user_id=1420135 Thank you for your rapid answer.But I still can't solve my question.I can't find the whole instructions. Can you give me the whole instructions by EMAIL,my email is xudong888 at 163.com,thanks. My "host" system is mips embbed_linux,the release of the linux kernel is 2.4.xx and the CPU type is MIPS 4Kc.There are no python installed on this system.My "build" system is i86 and operate system is RedHat9.0,and has installed python2.4.1 and cross-compiling Tools mipsel-linux-gcc.I can cross compile C program for the "host" system.I have writed some program with python language.I can get the binary from python script by use freeze.py on the "build" system. Now I want to run the binary on the "host" system.Can you tell me how should I do. in addition,I don't know what parameter I should input to use this patch. finally,I'm sorry for my poor English.I like python very much,but I can't get help in chinese. ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2006-01-05 11:24 Message: Logged In: YES user_id=843814 After configure you run "make". But did you use configure as the instructions say? You cannot just use "./configure". Good luck, Dan. ---------------------------------------------------------------------- Comment By: xudong (xudong888) Date: 2006-01-05 10:55 Message: Logged In: YES user_id=1420135 I am a Chinese and my English is very poor.I'm sorry if what I said is wrong.My question is What should I do after './configure'.Before this I have done patch and autoconf. Thanks :-) ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 10:06 Message: Logged In: YES user_id=845425 Oops! All works fine now. Thanks :-) ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 09:09 Message: Logged In: YES user_id=843814 patch isn't lying about wrong -p options. Use -p3 instead of -p0. Cheers, Dan. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-08 08:26 Message: Logged In: YES user_id=845425 Thanks for the quick reply, and sorry for the confusion. I DID try the cross compile in a sub directory. That failed with the same error. I then tried a non-cross build in the main directory, that also failed (which was my previous post). Here is my complete transcript after untarring Python: [dlambert at lambsys Python-2.4.2]$ patch -p0 < ../python-patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/README Fri Mar 5 08:33:21 2004 |--- python/dist/src/README Mon Apr 5 14:30:23 2004 -------------------------- File to patch: README patching file README Hunk #1 succeeded at 1130 (offset 30 lines). can't find file to patch at input line 48 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/configure.in Sun Mar 21 17:45:41 2004 |--- python/dist/src/configure.in Mon Apr 5 16:15:07 2004 -------------------------- File to patch: configure.in patching file configure.in Hunk #2 succeeded at 609 (offset 58 lines). Hunk #3 succeeded at 3072 (offset 112 lines). can't find file to patch at input line 113 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/Makefile.pre.in Thu Mar 18 01:51:27 2004 |--- python/dist/src/Makefile.pre.in Mon Apr 5 15:56:00 2004 -------------------------- File to patch: Makefile.pre.in patching file Makefile.pre.in Hunk #2 succeeded at 163 (offset 3 lines). Hunk #4 succeeded at 309 (offset 5 lines). Hunk #6 succeeded at 470 (offset 5 lines). Hunk #7 succeeded at 624 (offset 1 line). Hunk #8 succeeded at 839 (offset 7 lines). Hunk #9 succeeded at 923 (offset 1 line). Hunk #10 succeeded at 969 (offset 7 lines). can't find file to patch at input line 309 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** python-cvs-pristine/dist/src/setup.py Sun Mar 21 12:59:46 2004 |--- python/dist/src/setup.py Mon Apr 5 15:20:55 2004 -------------------------- File to patch: setup.py patching file setup.py Hunk #1 succeeded at 198 (offset -2 lines). patching file python/dist/src/config.guess patching file python/dist/src/config.sub [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ [dlambert at lambsys Python-2.4.2]$ autoconf configure.in > configure [dlambert at lambsys Python-2.4.2]$ mkdir cross-build [dlambert at lambsys Python-2.4.2]$ cd cross-build [dlambert at lambsys cross-build]$ ../configure --host=arm-linux --build=i686-pc-li nux-gnu configure: error: cannot run /bin/sh ../config.sub [dlambert at lambsys cross-build]$ ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-11-08 08:05 Message: Logged In: YES user_id=843814 You can't configure in the source directory with the cross compile patch. This is explained in the directions. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2005-11-07 20:12 Message: Logged In: YES user_id=845425 Hmm. not so much luck here. I get the following error after patching then autoconf. I am running on Fedora Core 4. Any suggestions? [dlambert at lambsys Python-2.4.2]$ autoconf configure.in >configure [dlambert at lambsys Python-2.4.2]$ ./configure configure: error: cannot run /bin/sh ./config.sub [dlambert at lambsys Python-2.4.2]$ ---------------------------------------------------------------------- Comment By: Robsa (robsa) Date: 2005-10-13 06:54 Message: Logged In: YES user_id=1277505 Just thought I'd let you know that this patch works against Python 2.4.2. I had Python running on my custom AT91RM9200 board (ARM920T core) in about 20 minutes. *snaps* for Daniel!! ---------------------------------------------------------------------- Comment By: Daniel Goertzen (goertzen) Date: 2005-04-13 12:36 Message: Logged In: YES user_id=843814 It still works for me, so I've had limited interest in working on it further. I think a "real" cross compile patch will involve significant refactoring of distutils and the main setup.py script. Should this start with a PEP? ---------------------------------------------------------------------- Comment By: Ned Ludd (solarx) Date: 2005-04-09 15:43 Message: Logged In: YES user_id=148412 Any progress with this on? python and perl are two of the last major things to overcome in the x-compile world. ---------------------------------------------------------------------- Comment By: Mike Frysinger (vapier) Date: 2004-10-26 11:00 Message: Logged In: YES user_id=114429 we've been using this with uClibc for a while now and it works great ... ive personally built (on amd64) & deployed (on x86/ppc/arm/mips/sh4) python ... would great if this finally made it into the official sources :) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2004-10-20 20:08 Message: Logged In: YES user_id=2772 This patch applies cleanly to today's CVS head. If building in the source directory while cross compiling fails, please make configure complain about it. This patch makes the build process invoke make recursively, which is a big minus. I'd rather see pgen built with a HOSTCC and just assume python is available on $PATH for the setup.py step. There's no reason to build all the shared modules in buildpython, either, which would speed things up a fair bit. On to how it worked for me: Not cross-compiling, this produces no unexpected test failures in "make test". (redhat9) Cross compiling for i386-pc-bsdi2.1 everything goes fine until it tries to run buildpython and make shared modules, but shared modules don't work in the first place on bsdi2. I did not test the resulting Python binary. Cross compiling for i386-redhat-linux (libc6) some extensions fail to build, but this could be because my header files for the cross-development environment are not complete. Running "make test" tries to invoke the "buildpython/python" and doesn't work. Running it manually I get some skips due to modules that did not build, but everything that did build seems to pass. (OK, so I wrote this before the tests completed, but they're off to a good start) I currently cross-compile python 2.3 for win32 (mingw), and until recently cross-compiled it for bsdi2 and redhat6. However, I did not use configure or the included makefiles to do this (in order to integrate in a non-recursive build procedure that builds several packages), so this patch is unlikely to benefit me directly. I don't think this patch is ready to be applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470 From noreply at sourceforge.net Wed Jul 5 00:04:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Jul 2006 15:04:55 -0700 Subject: [Patches] [ python-Patches-1484695 ] tarfile.py fix for #1471427 and updates Message-ID: Patches item #1484695, was opened at 2006-05-09 06:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Pending Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for #1471427 and updates Initial Comment: I have assembled a patch that adds some features from my own development path of tarfile.py (http://www.gustaebel.de/lars/tarfile/) and fixes #1471427 which made some restructuring necessary. The patch affects Lib/tarfile.py, Lib/test/test_tarfile.py and Doc/lib/libtarfile.tex. The changes the patch makes are as follows: Sets the version to 0.8.0. Support for base256 encoding of number fields (nti() and itn()). Up to now this was hardcoded for the filesize field to allow filesizes greater than 8 GB but it is applicable to all number fields. TarInfo.tobuf() has a boolean argument "posix" which controls how number fields are written (base256 is non-posix). Both unsigned and signed (Sun and NeXT) checksums are calculated. Header validation moves from TarFile.next() to TarInfo.frombuf(). A header is valid only if its checksum is okay, in the past the checksum was calculated but ignored. The TarFile.next() method was rearranged which makes header processing clearer and more abstract and fixes bug #1471427. However, this change breaks the interface for subclassing in order to implement custom member types but makes it much easier at the same time. The mapping TYPE_METH was removed. A new test ReadGNULongTest was added to test_tarfile.py and testtar.tar was updated to be able to test the GNU extensions LONGNAME and LONGLINK. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-04 15:04 Message: Logged In: YES user_id=33168 Lars, I don't see the debug (_dbg) call. Which version are you using? I didn't see r46040 in Lib/tafile.py for either 2.5 or 2.4. Could you point me to file/line/version where there's a problem (or just make a patch)? Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-03 01:59 Message: Logged In: YES user_id=642936 I would like to emphasize on point (2) of my previous post, which should be resolved before 2.5 comes out. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-18 03:00 Message: Logged In: YES user_id=642936 On (1): agreed. On (2): There is still a debug message emitted for a bad checksum: In TarInfo.frombuf() at the bottom a ValueError is raised if they don't match and is passed on to TarFile.next() where it is put out as a debug message using the _dbg() method in the except clause. The debug message where it is now (r46040) is senseless because the try-block will be left when TarInfo.frombuf() fails . On (3): You're right, I attached a patch that adds another Exception HeaderError which is raised in TarInfo.frombuf() instead of ValueError in case of a bad header. I hope that is acceptable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 23:11 Message: Logged In: YES user_id=849994 Jim: I agree with your comments and have committed an improved version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-17 15:25 Message: Logged In: YES user_id=764593 (1) Why change the exception style? When raising an instance, the style guide (PEP-8, http:// www.python.org/dev/peps/pep-0008/) prefers to construct that instance; the older form is left over from String exceptions and will be removed in Python 3. I could understand leaving them as they were, but if you're going to change them to make them consistent, why not use the current format? (2) Why get rid of the debug messages (such as the checksum check) entirely? Guarding them in if self.debug, I would understand. (3) I wouldn't count on str(e) (where e is any ValueError instance) being as meaningful as the (current version's) ReadError("empty, unreadable or compressed file") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-10 09:26 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 45954. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-09 06:52 Message: Logged In: YES user_id=642936 Here is testtar.tar to replace Lib/test/testtar.tar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 From noreply at sourceforge.net Wed Jul 5 00:56:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 04 Jul 2006 15:56:36 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 09:39 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Wed Jul 5 15:14:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 06:14:54 -0700 Subject: [Patches] [ python-Patches-1517490 ] Improve docs for builtin filter() Message-ID: Patches item #1517490, was opened at 2006-07-05 08:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517490&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Improve docs for builtin filter() Initial Comment: The current (r47237) docs for the filter() builtin say "If list is a string or a tuple, the result also has that type". On first reading, it's unclear if "string" means "str" or "str and unicode". The attached patch for Doc/lib/libfuncs.tex makes this clear. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-07-05 09:14 Message: Logged In: YES user_id=1344176 The docs also state (misleadingly) that "all elements of list that are false (zero or empty) are removed". The patch has been updated to remove the "(zero or empty)" remark. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517490&group_id=5470 From noreply at sourceforge.net Wed Jul 5 17:31:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 08:31:25 -0700 Subject: [Patches] [ python-Patches-1517586 ] Patch to commands.py to enable callback support Message-ID: Patches item #1517586, was opened at 2006-07-05 08:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517586&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brad Doctor (bdoctor) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to commands.py to enable callback support Initial Comment: This is a patch to commands.py to enable callback support, which is very useful for long-running commands. Whenever there is stdout from the process the callback is fed whatever it got. Example usage: import commands cmd = 'top -b -n2' def fancy(out): print 'GOT(%s)' % out.strip() commands.cb = fancy (s,o) = commands.getstatusoutput(cmd) print 'OUTPUT (%s)' % o Please consider adding this. The existing API is not changed, however as you can see it is simple to use the callback. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517586&group_id=5470 From noreply at sourceforge.net Wed Jul 5 19:36:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 10:36:44 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 12:39 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-07-05 13:36 Message: Logged In: YES user_id=1344176 The improve_gc_inspection.patch file has been superseded by a patch attached to bug #1517663. The bug details another interpreter crash in the same vein as the one fix in tuple() by this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Wed Jul 5 22:39:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 13:39:43 -0700 Subject: [Patches] [ python-Patches-1517790 ] Patch for ctypes to enable custom objects in function calls Message-ID: Patches item #1517790, was opened at 2006-07-05 22:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Thomas Heller (theller) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for ctypes to enable custom objects in function calls Initial Comment: This patch allows to use custom objects as parameters in foreign function calls. The patch is very simple (actually it is more like a simple bug fix). Tests and documentation included. The patch is against the SF CVS ctypes repository, because it is simple to read imo. I'm requesting permission to apply this patch to Python current SVN before the next beta release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 From noreply at sourceforge.net Thu Jul 6 03:44:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 18:44:55 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 04:11 Message generated for change (Comment added) made by kap4020 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-05 20:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 11:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Thu Jul 6 04:25:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 19:25:00 -0700 Subject: [Patches] [ python-Patches-1517891 ] Patch for bug #1514451 Message-ID: Patches item #1517891, was opened at 2006-07-06 12:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for bug #1514451 Initial Comment: '[ 1514451 ] zipfile "append" mode should create a file if not present' I thought this was a logical suggestion. Here's a patch, including tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517891&group_id=5470 From noreply at sourceforge.net Thu Jul 6 04:28:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 19:28:53 -0700 Subject: [Patches] [ python-Patches-1517891 ] Bug 1514451: zipfile "append" mode should create a file ... Message-ID: Patches item #1517891, was opened at 2006-07-06 12:25 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Bug 1514451: zipfile "append" mode should create a file ... Initial Comment: '[ 1514451 ] zipfile "append" mode should create a file if not present' I thought this was a logical suggestion. Here's a patch, including tests. ---------------------------------------------------------------------- >Comment By: Thomas Lee (krumms) Date: 2006-07-06 12:28 Message: Logged In: YES user_id=315535 It should be noted that the decision not to modify self.mode (i.e. change it to 'w', which is effectively what we're doing) was a conscious decision: existing code may depend on the mode attribute (however unlikely that might be). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517891&group_id=5470 From noreply at sourceforge.net Thu Jul 6 05:50:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 20:50:40 -0700 Subject: [Patches] [ python-Patches-1517790 ] Patch for ctypes to enable custom objects in function calls Message-ID: Patches item #1517790, was opened at 2006-07-05 13:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Thomas Heller (theller) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for ctypes to enable custom objects in function calls Initial Comment: This patch allows to use custom objects as parameters in foreign function calls. The patch is very simple (actually it is more like a simple bug fix). Tests and documentation included. The patch is against the SF CVS ctypes repository, because it is simple to read imo. I'm requesting permission to apply this patch to Python current SVN before the next beta release. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 20:50 Message: Logged In: YES user_id=33168 Is i a Py_ssize_t? If so the format string should use %zd. This patch is acceptable for 2.5. Please update Misc/NEWS when you checkin. Also, please try to get this in ASAP so we get as much testing as possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 From noreply at sourceforge.net Thu Jul 6 05:51:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 20:51:04 -0700 Subject: [Patches] [ python-Patches-1517790 ] Patch for ctypes to enable custom objects in function calls Message-ID: Patches item #1517790, was opened at 2006-07-05 13:39 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted >Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: Patch for ctypes to enable custom objects in function calls Initial Comment: This patch allows to use custom objects as parameters in foreign function calls. The patch is very simple (actually it is more like a simple bug fix). Tests and documentation included. The patch is against the SF CVS ctypes repository, because it is simple to read imo. I'm requesting permission to apply this patch to Python current SVN before the next beta release. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 20:50 Message: Logged In: YES user_id=33168 Is i a Py_ssize_t? If so the format string should use %zd. This patch is acceptable for 2.5. Please update Misc/NEWS when you checkin. Also, please try to get this in ASAP so we get as much testing as possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 From noreply at sourceforge.net Thu Jul 6 06:24:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 21:24:53 -0700 Subject: [Patches] [ python-Patches-1515609 ] Alternative fix for ImportWarning (fix for 1515169) Message-ID: Patches item #1515609, was opened at 2006-07-01 11:05 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Sergey (sergeyli) >Assigned to: Neal Norwitz (nnorwitz) Summary: Alternative fix for ImportWarning (fix for 1515169) Initial Comment: Similarly to http://www.python.org/sf/1515361, tries to change the way ImportWarning behaves. The difference between tha patches is that this one does not try to produce a full list of all possible directories that have not been imported. Instead, this patch only provides number of candidate directories found, and prints the first one, which hopefully is the most likely candidate. Full description follows. I tried to implement Jean-Paul Calderone's idea for the following patch, plagiarizing Ralf W. Grosse-Kunstleve's error text. It delays import warning until end of search for modules, but remembers how many potential modules (candidates without __init__.py) it didn't import. I didn't really try to analyze any conditions, instead I simply assumed that wherever ImportWarning would be issued, we have a suitable candidate, and saved it on the stack. If nothing is found, Python emits ImportWarning right before ImportError, and explains what happened. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 21:24 Message: Logged In: YES user_id=33168 Thank you for the patch. The decision was made to simply ignore the warning by default. There's nothing necessarily wrong with this patch, although I didn't review it. I'm closing because we are taking a different approach at this time. We will revisit the decision for 2.6. I hope you continue reading python-dev and help us fix this better for 2.6, whatever that may be. Perhaps this patch will be revived at that time. I have added a link to this patch in PEP 361. ---------------------------------------------------------------------- Comment By: Sergey (sergeyli) Date: 2006-07-01 11:11 Message: Logged In: YES user_id=141494 This one also doesn't have the memory leak fix mentioned in python.org/sf/1515361. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515609&group_id=5470 From noreply at sourceforge.net Thu Jul 6 06:29:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 21:29:07 -0700 Subject: [Patches] [ python-Patches-1515361 ] 1515169 fix (ImportWarning flood) Message-ID: Patches item #1515361, was opened at 2006-06-30 16:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515361&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Shane Hathaway (hathawsh) >Assigned to: Neal Norwitz (nnorwitz) Summary: 1515169 fix (ImportWarning flood) Initial Comment: This patch to import.c only generates ImportWarnings if the import fails. It also fixes what appear to be memory leaks involving the "copy" variable. This patch applies to Python 2.5b1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 21:29 Message: Logged In: YES user_id=33168 Shane, thanks for the patch. The decision was made to simply ignore the warning by default. I'm closing it because we are taking a different approach at this time. We will revisit the decision for 2.6. I hope you continue reading python-dev and help us fix this better for 2.6, whatever that may be. Perhaps this patch will be revived at that time. I have added a link to this patch in PEP 361. I agree with the memory leaks wrt to copy and have checked in changes that should address all the leaks. Let me know if you spot other ones (or I made a mistake). ---------------------------------------------------------------------- Comment By: Sergey (sergeyli) Date: 2006-07-01 11:10 Message: Logged In: YES user_id=141494 See also an alternative python.org/sf/1515609. Mine doesn't have the memory leak fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515361&group_id=5470 From noreply at sourceforge.net Thu Jul 6 07:05:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 22:05:32 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 11:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-06 07:05 Message: Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 06:54 Message: Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-06 03:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 18:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Thu Jul 6 08:28:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 23:28:53 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 09:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 2 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 23:28 Message: Logged In: YES user_id=33168 Note that the declaration of item needs to be moved to the top of the scope so it can compile with C89. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-05 15:31 Message: Logged In: YES user_id=80475 Crashers based on gc.get_referrers() should not be considered real bugs. It is certainly not worth complexifying the code or slowing it down just to preclude these little perverse safe-cracking exercises. Also, it is not worth the risk of introducing a real bug when the code was working fine. That being said, if the code is genuinely defective and has potential to cause real-world problems, then it should be fixed. I would think that if there were a long- standing problem with tuples, it would have manifested itself long ago. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-05 10:36 Message: Logged In: YES user_id=1344176 The improve_gc_inspection.patch file has been superseded by a patch attached to bug #1517663. The bug details another interpreter crash in the same vein as the one fix in tuple() by this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Thu Jul 6 08:43:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 05 Jul 2006 23:43:20 -0700 Subject: [Patches] [ python-Patches-1517947 ] assert for NULL in Py_INCREF Py_DECREF Message-ID: Patches item #1517947, was opened at 2006-07-06 06:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rene Dudfield (illume) Assigned to: Nobody/Anonymous (nobody) Summary: assert for NULL in Py_INCREF Py_DECREF Initial Comment: Since Py_INCREF and Py_DECREF should not be able to take NULLs they should do an assert check for this. This would have caught at least one bug earlier in cPickle.loads() http://sourceforge.net/tracker/index.php?func=detail&aid=1512695&group_id=5470&atid=105470 It will also help other extension module authors find this error in their code more easily. Include/object.h #define Py_INCREF(op) ( \ (assert((op) != NULL)) , \ _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ (op)->ob_refcnt++) #define Py_DECREF(op) \ if ((assert((op) != NULL)) , _Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --(op)->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517947&group_id=5470 From noreply at sourceforge.net Thu Jul 6 10:42:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Jul 2006 01:42:44 -0700 Subject: [Patches] [ python-Patches-1517891 ] Bug 1514451: zipfile "append" mode should create a file ... Message-ID: Patches item #1517891, was opened at 2006-07-06 04:25 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517891&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Lee (krumms) Assigned to: Nobody/Anonymous (nobody) Summary: Bug 1514451: zipfile "append" mode should create a file ... Initial Comment: '[ 1514451 ] zipfile "append" mode should create a file if not present' I thought this was a logical suggestion. Here's a patch, including tests. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-06 10:42 Message: Logged In: YES user_id=580910 This patch looks sane. What I don't know is if this qualifies as a bugfix or if this is a new feature (however minor). ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2006-07-06 04:28 Message: Logged In: YES user_id=315535 It should be noted that the decision not to modify self.mode (i.e. change it to 'w', which is effectively what we're doing) was a conscious decision: existing code may depend on the mode attribute (however unlikely that might be). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517891&group_id=5470 From noreply at sourceforge.net Thu Jul 6 10:43:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Jul 2006 01:43:30 -0700 Subject: [Patches] [ python-Patches-1517790 ] Patch for ctypes to enable custom objects in function calls Message-ID: Patches item #1517790, was opened at 2006-07-05 22:39 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: Patch for ctypes to enable custom objects in function calls Initial Comment: This patch allows to use custom objects as parameters in foreign function calls. The patch is very simple (actually it is more like a simple bug fix). Tests and documentation included. The patch is against the SF CVS ctypes repository, because it is simple to read imo. I'm requesting permission to apply this patch to Python current SVN before the next beta release. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-07-06 10:43 Message: Logged In: YES user_id=11105 No, i is an int. As it counts items (the number of args passed to a function call) maybe unsigned would be better but its not worth to change it. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 05:50 Message: Logged In: YES user_id=33168 Is i a Py_ssize_t? If so the format string should use %zd. This patch is acceptable for 2.5. Please update Misc/NEWS when you checkin. Also, please try to get this in ASAP so we get as much testing as possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517790&group_id=5470 From noreply at sourceforge.net Thu Jul 6 10:44:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Jul 2006 01:44:49 -0700 Subject: [Patches] [ python-Patches-1491759 ] IDLE L&F on MacOSX Message-ID: Patches item #1491759, was opened at 2006-05-19 19:39 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491759&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Nobody/Anonymous (nobody) Summary: IDLE L&F on MacOSX Initial Comment: The attached patch fixes some L&F issues on MacOSX: - IDLE now reacts to file-open AppleEvents, which means that if a user associates IDLE.app with .py files IDLE will open .py files when the user double-clicks on them - Hide the tcl/tk console window that gets opened by default when IDLE is in an application bundle (that's a misfeature of aquatk) - Patch the menu's to make sure they better conform to the HIG. - PyShell/EditorWindow status_bar no longer overlaps with the resize widget in the lower-left corner of the window Open issues: - When you double-click on a file and IDLE is not yet open the file will be opened, but IDLE will open the default shell window just above it :-( - I'm not terribly happy with the code changes that implement the updated menu structure. - The default keybindings on OSX are the windows keybindings. I haven't checked yet if that can be fixed programmaticly, I also haven't verified if the macos keybindings are fully correct for OSX. - The general L&F is still wrong, but that isn't really IDLE's fault: tcl/tk doesn't fully conform to the HIG yet (dialogs without title bars, wrong default dinwos background, wrong widget for tabbed windows, ...). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-06 10:44 Message: Logged In: YES user_id=580910 This patch was applied before 2.5b1 came out, closing. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-06 08:21 Message: Logged In: YES user_id=580910 Actually upload the new patch. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-05 22:12 Message: Logged In: YES user_id=580910 I've updated the patch slightly: - ZoomHeight placed the top of the window behind the menubar - Keybindings that use the Alt don't work with AquaTk, automaticly replace those by bindings that use the Option key (which is basically the same key on OSX). This is needed because not all key-bindings are part of config- keys.def, some are in config-extensions.def. The annoying bit is that this doesn't actually solve the entire problem, now zooms windows as the menu suggests, but also still inserts the TM character (which is the default binding for in OSX text views). - Rename the Windows menu to Window (singular) to be more consistent with OSX naming of menus. I haven't found a nice way to override the default keybindings yet. I'm very tempted to patch the various configfiles when running a framework-install. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 14:28 Message: Logged In: YES user_id=580910 I've currently worked around the default keybindings issue by copying a mac- specific copy of config-main.def into the library directory when doing a framework install of python. That's obviously not a good solution, but I wouldn't know how to do it better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1491759&group_id=5470 From noreply at sourceforge.net Fri Jul 7 00:53:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Jul 2006 15:53:56 -0700 Subject: [Patches] [ python-Patches-1492704 ] distinct error type from shutil.move() Message-ID: Patches item #1492704, was opened at 2006-05-22 03:08 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: distinct error type from shutil.move() Initial Comment: I need to call shutil.move() and be able to tell the difference between an error such as access denied and an error due to the two arguments being the same file. --- old-dw/src/Lib/shutil.py 2006-05-22 00:06:02.000000000 -0300 +++ new-dw/src/Lib/shutil.py 2006-05-22 00:06:02.000000000 -0300 @@ -16,6 +16,9 @@ class Error(exceptions.EnvironmentError): pass +class SameFileError(Error): + pass + def copyfileobj(fsrc, fdst, length=16*1024): """copy data from file-like object fsrc to file-like object fdst""" while 1: @@ -39,7 +42,7 @@ def copyfile(src, dst): """Copy data from src to dst""" if _samefile(src, dst): - raise Error, "`%s` and `%s` are the same file" % (src, dst) + raise SameFileError, "`%s` and `%s` are the same file" % (src, dst) fsrc = None fdst = None ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2006-07-06 22:53 Message: Logged In: YES user_id=52562 Please apply. This patch is completely backwards-compatible and makes possible some uses of shutil.move(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470 From noreply at sourceforge.net Fri Jul 7 00:55:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Jul 2006 15:55:47 -0700 Subject: [Patches] [ python-Patches-1492704 ] distinct error type from shutil.move() Message-ID: Patches item #1492704, was opened at 2006-05-22 03:08 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) >Assigned to: Anthony Baxter (anthonybaxter) Summary: distinct error type from shutil.move() Initial Comment: I need to call shutil.move() and be able to tell the difference between an error such as access denied and an error due to the two arguments being the same file. --- old-dw/src/Lib/shutil.py 2006-05-22 00:06:02.000000000 -0300 +++ new-dw/src/Lib/shutil.py 2006-05-22 00:06:02.000000000 -0300 @@ -16,6 +16,9 @@ class Error(exceptions.EnvironmentError): pass +class SameFileError(Error): + pass + def copyfileobj(fsrc, fdst, length=16*1024): """copy data from file-like object fsrc to file-like object fdst""" while 1: @@ -39,7 +42,7 @@ def copyfile(src, dst): """Copy data from src to dst""" if _samefile(src, dst): - raise Error, "`%s` and `%s` are the same file" % (src, dst) + raise SameFileError, "`%s` and `%s` are the same file" % (src, dst) fsrc = None fdst = None ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2006-07-06 22:55 Message: Logged In: YES user_id=52562 I'm not sure how to draw attention to my patch, so I will try assigning it to anthonybaxter. That ought to get attention. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2006-07-06 22:53 Message: Logged In: YES user_id=52562 Please apply. This patch is completely backwards-compatible and makes possible some uses of shutil.move(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1492704&group_id=5470 From noreply at sourceforge.net Fri Jul 7 02:21:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 06 Jul 2006 17:21:27 -0700 Subject: [Patches] [ python-Patches-1517947 ] assert for NULL in Py_INCREF Py_DECREF Message-ID: Patches item #1517947, was opened at 2006-07-05 23:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517947&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rene Dudfield (illume) Assigned to: Nobody/Anonymous (nobody) Summary: assert for NULL in Py_INCREF Py_DECREF Initial Comment: Since Py_INCREF and Py_DECREF should not be able to take NULLs they should do an assert check for this. This would have caught at least one bug earlier in cPickle.loads() http://sourceforge.net/tracker/index.php?func=detail&aid=1512695&group_id=5470&atid=105470 It will also help other extension module authors find this error in their code more easily. Include/object.h #define Py_INCREF(op) ( \ (assert((op) != NULL)) , \ _Py_INC_REFTOTAL _Py_REF_DEBUG_COMMA \ (op)->ob_refcnt++) #define Py_DECREF(op) \ if ((assert((op) != NULL)) , _Py_DEC_REFTOTAL _Py_REF_DEBUG_COMMA \ --(op)->ob_refcnt != 0) \ _Py_CHECK_REFCNT(op) \ else \ _Py_Dealloc((PyObject *)(op)) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-07-06 17:21 Message: Logged In: YES user_id=357491 I don't think that the cPickle bug would have been any sooner. The segfault happens just as early as an assertion would have since both going to access bad memory. Regardless, the adding of the assert() in Py_DECREF might warrant using ``while{} do(0)`` to simplify the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517947&group_id=5470 From noreply at sourceforge.net Fri Jul 7 10:39:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Jul 2006 01:39:37 -0700 Subject: [Patches] [ python-Patches-1518569 ] 'import foo as bar' not checking for 'as' Message-ID: Patches item #1518569, was opened at 2006-07-07 08:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1518569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Parser/Compiler >Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: 'import foo as bar' not checking for 'as' Initial Comment: 'import foo as bar' doesn't check if the 'as' is really 'as', allowing for 'import foo feeble bar' to mean the same thing. I probably broke this somehow when making 'as' a future-keyword. Adding a bug to remind myself to fix it (next week or so) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-07 08:39 Message: Logged In: YES user_id=849994 Preliminary patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1518569&group_id=5470 From noreply at sourceforge.net Fri Jul 7 16:02:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Jul 2006 07:02:05 -0700 Subject: [Patches] [ python-Patches-1518772 ] ext/win-cookbook.html has a broken link to distutils Message-ID: Patches item #1518772, was opened at 2006-07-07 16:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1518772&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Johannes Gijsbers (jlgijsbers) Assigned to: Nobody/Anonymous (nobody) Summary: ext/win-cookbook.html has a broken link to distutils Initial Comment: http://docs.python.org/ext/win-cookbook.html has a link to distutils which points to http://docs.python.org/ext/module-distutils.html. It should point to http://docs.python.org/lib/module-distutils.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1518772&group_id=5470 From noreply at sourceforge.net Sat Jul 8 01:02:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Jul 2006 16:02:41 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 19:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Sat Jul 8 01:03:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 07 Jul 2006 16:03:52 -0700 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 06:37 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-07 19:03 Message: Logged In: YES user_id=1356214 I've submitted a new patch as 1519025. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 15:37 Message: Logged In: YES user_id=1356214 Ehh, we can stop worrying. From ceval.h: "For convenience, that the value of 'errno' is restored across Py_END_ALLOW_THREADS and Py_BLOCK_THREADS." This means that I can remove from my patch the extra code to restore errno. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 15:22 Message: Logged In: YES user_id=1356214 Hmm, not me, but yes, socketmodule.c wraps its system calls in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, and then does its error checking. Here's a small function (from trunk): static PyObject * sock_connect(PySocketSockObject *s, PyObject *addro) { struct sockaddr *addr; int addrlen; int res; int timeout; if (!getsockaddrarg(s, addro, &addr, &addrlen)) return NULL; Py_BEGIN_ALLOW_THREADS res = internal_connect(s, addr, addrlen, &timeout); Py_END_ALLOW_THREADS if (timeout) { PyErr_SetString(socket_timeout, "timed out"); return NULL; } if (res != 0) return s->errorhandler(); Py_INCREF(Py_None); return Py_None; } Note that both the check for timeout and also the s->errorhandler() call (which defaults to set_error() and probably pre-dates timeout) use errno, everywhere. If this is wrong, I'll bring it up on python-dev. Do you have an example of a properly-coded module? For example, the first one I checked, fctlmodule.c, does it the same way. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-18 14:23 Message: Logged In: YES user_id=21627 If I understand correctly, you have Py_END_ALLOW_THREADS between the system call and the access to errno. Py_END_ALLOW_THREADS expands to PyEval_RestoreThread, which calls PyThread_acquire_lock, which (on pthreads) calls sem_wait, which may set errno to EINTR. It may well be that the same mistake is made in other places. That the code is in Python is no proof that it is "acceptable" - only that earlier reviewers did not catch the mistake. If so, this should perhaps be discussed on python-dev: if we want an explicit guarantee that errno won't change across these macros, we should change the functions to provide that guarantee. In general, you should assume that any C library call may change errno, unless it does not document the values that errno may receive due to this system call. So for any library call between the original call and the usage of errno, you have to analyse whether it may change errno (directly or indirectly). ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 14:00 Message: Logged In: YES user_id=1356214 Martin, I'm working on an update to this patch so that it will finally get fixed. I have a question about your answer to #4. You say that errno is read "much too late", but that's the same way that errorhandler() does it, and it seems acceptable there. I don't see any calls in between that would trash errno (at least after my patch is applied :). Is there really a problem? I do have it fixed, by returning errno from internal_select(), but if it isn't needed I'd like to simplify the patch. BTW, I'm handling #1 (internal_connect()). There is still more work to do -- I think that it would be better to handle Ctl-C as the interpreter does on its periodic checks, so that it becomes KeyboardInterrupt instead of some other error with a ' (4, ' in it. Umm, I need to do more research on that. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-02-24 15:42 Message: Logged In: YES user_id=21627 Thanks for the patch. 1) I could not see where you dealt with internal_connect in the patch. However, as a connect can also be cancelled with Ctrl-C, I think you need to deal with it, too. 2) I agree, renaming it would be good 3) you could come up with a macro to avoid code duplication (relying on consistent naming of variables, but that might confure more than help 4) This is almost right. The critical thing is that you read errno much too late. errno is meant to be read immediately after the system call. Any later system call can modify the value - including all of the pthread calls that we do in-between. So the right solution is to copy errno right after select, into a local variable of the caller, and read *that* variable. In order to avoid modifying SetFromErrno, you can assign back to errno before calling it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Sat Jul 8 12:44:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Jul 2006 03:44:30 -0700 Subject: [Patches] [ python-Patches-1518569 ] 'import foo as bar' not checking for 'as' Message-ID: Patches item #1518569, was opened at 2006-07-07 10:15 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1518569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Thomas Wouters (twouters) Assigned to: Thomas Wouters (twouters) Summary: 'import foo as bar' not checking for 'as' Initial Comment: 'import foo as bar' doesn't check if the 'as' is really 'as', allowing for 'import foo feeble bar' to mean the same thing. I probably broke this somehow when making 'as' a future-keyword. Adding a bug to remind myself to fix it (next week or so) ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-07-08 12:44 Message: Logged In: YES user_id=34209 Neal fixed this in r50489 (#1519018 was a dupe of this, but he saw that first, apparently :) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-07 10:39 Message: Logged In: YES user_id=849994 Preliminary patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1518569&group_id=5470 From noreply at sourceforge.net Sat Jul 8 14:17:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 08 Jul 2006 05:17:00 -0700 Subject: [Patches] [ python-Patches-1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice Message-ID: Patches item #1102879, was opened at 2005-01-15 11:37 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for 926423: socket timeouts + Ctrl-C don't play nice Initial Comment: Please have a close look at the attached patch. Essentially, it fixes internal_select to not return zero on error condition, and also adds a test for errno at all calls to internal_select. A few remarks: 1) as indicated in the patch, I'm not sure if errno should also be tested in the internal_connect function; 2) 'timeout' is no longer a boolean indicating a timeout condition, it should probably be renamed to 'selectresult' or something similar; 3) I'm not too happy with the fact that the if(timeout==-1 && erro) test must be duplicated in a lot of functions; 4) does it do the right thing? The check for timeout==-1 MUST be there otherwise a lot of errors turn up in the regression tests. With this patch they run fine, btw ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-07 23:03 Message: Logged In: YES user_id=1356214 I've submitted a new patch as 1519025. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 19:37 Message: Logged In: YES user_id=1356214 Ehh, we can stop worrying. From ceval.h: "For convenience, that the value of 'errno' is restored across Py_END_ALLOW_THREADS and Py_BLOCK_THREADS." This means that I can remove from my patch the extra code to restore errno. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 19:22 Message: Logged In: YES user_id=1356214 Hmm, not me, but yes, socketmodule.c wraps its system calls in Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS, and then does its error checking. Here's a small function (from trunk): static PyObject * sock_connect(PySocketSockObject *s, PyObject *addro) { struct sockaddr *addr; int addrlen; int res; int timeout; if (!getsockaddrarg(s, addro, &addr, &addrlen)) return NULL; Py_BEGIN_ALLOW_THREADS res = internal_connect(s, addr, addrlen, &timeout); Py_END_ALLOW_THREADS if (timeout) { PyErr_SetString(socket_timeout, "timed out"); return NULL; } if (res != 0) return s->errorhandler(); Py_INCREF(Py_None); return Py_None; } Note that both the check for timeout and also the s->errorhandler() call (which defaults to set_error() and probably pre-dates timeout) use errno, everywhere. If this is wrong, I'll bring it up on python-dev. Do you have an example of a properly-coded module? For example, the first one I checked, fctlmodule.c, does it the same way. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-18 18:23 Message: Logged In: YES user_id=21627 If I understand correctly, you have Py_END_ALLOW_THREADS between the system call and the access to errno. Py_END_ALLOW_THREADS expands to PyEval_RestoreThread, which calls PyThread_acquire_lock, which (on pthreads) calls sem_wait, which may set errno to EINTR. It may well be that the same mistake is made in other places. That the code is in Python is no proof that it is "acceptable" - only that earlier reviewers did not catch the mistake. If so, this should perhaps be discussed on python-dev: if we want an explicit guarantee that errno won't change across these macros, we should change the functions to provide that guarantee. In general, you should assume that any C library call may change errno, unless it does not document the values that errno may receive due to this system call. So for any library call between the original call and the usage of errno, you have to analyse whether it may change errno (directly or indirectly). ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-06-18 18:00 Message: Logged In: YES user_id=1356214 Martin, I'm working on an update to this patch so that it will finally get fixed. I have a question about your answer to #4. You say that errno is read "much too late", but that's the same way that errorhandler() does it, and it seems acceptable there. I don't see any calls in between that would trash errno (at least after my patch is applied :). Is there really a problem? I do have it fixed, by returning errno from internal_select(), but if it isn't needed I'd like to simplify the patch. BTW, I'm handling #1 (internal_connect()). There is still more work to do -- I think that it would be better to handle Ctl-C as the interpreter does on its periodic checks, so that it becomes KeyboardInterrupt instead of some other error with a ' (4, ' in it. Umm, I need to do more research on that. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-02-24 20:42 Message: Logged In: YES user_id=21627 Thanks for the patch. 1) I could not see where you dealt with internal_connect in the patch. However, as a connect can also be cancelled with Ctrl-C, I think you need to deal with it, too. 2) I agree, renaming it would be good 3) you could come up with a macro to avoid code duplication (relying on consistent naming of variables, but that might confure more than help 4) This is almost right. The critical thing is that you read errno much too late. errno is meant to be read immediately after the system call. Any later system call can modify the value - including all of the pthread calls that we do in-between. So the right solution is to copy errno right after select, into a local variable of the caller, and read *that* variable. In order to avoid modifying SetFromErrno, you can assign back to errno before calling it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1102879&group_id=5470 From noreply at sourceforge.net Sun Jul 9 10:01:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 01:01:16 -0700 Subject: [Patches] [ python-Patches-1484695 ] tarfile.py fix for #1471427 and updates Message-ID: Patches item #1484695, was opened at 2006-05-09 15:51 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Open Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for #1471427 and updates Initial Comment: I have assembled a patch that adds some features from my own development path of tarfile.py (http://www.gustaebel.de/lars/tarfile/) and fixes #1471427 which made some restructuring necessary. The patch affects Lib/tarfile.py, Lib/test/test_tarfile.py and Doc/lib/libtarfile.tex. The changes the patch makes are as follows: Sets the version to 0.8.0. Support for base256 encoding of number fields (nti() and itn()). Up to now this was hardcoded for the filesize field to allow filesizes greater than 8 GB but it is applicable to all number fields. TarInfo.tobuf() has a boolean argument "posix" which controls how number fields are written (base256 is non-posix). Both unsigned and signed (Sun and NeXT) checksums are calculated. Header validation moves from TarFile.next() to TarInfo.frombuf(). A header is valid only if its checksum is okay, in the past the checksum was calculated but ignored. The TarFile.next() method was rearranged which makes header processing clearer and more abstract and fixes bug #1471427. However, this change breaks the interface for subclassing in order to implement custom member types but makes it much easier at the same time. The mapping TYPE_METH was removed. A new test ReadGNULongTest was added to test_tarfile.py and testtar.tar was updated to be able to test the GNU extensions LONGNAME and LONGLINK. ---------------------------------------------------------------------- >Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-09 10:01 Message: Logged In: YES user_id=642936 I attached a tar with two diffs: only-tarfile.diff only removes the debug message. complete-with-headererror.diff removes the debug message and adds the HeaderError exception to TarInfo.frombuf() mentioned below. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-05 00:04 Message: Logged In: YES user_id=33168 Lars, I don't see the debug (_dbg) call. Which version are you using? I didn't see r46040 in Lib/tafile.py for either 2.5 or 2.4. Could you point me to file/line/version where there's a problem (or just make a patch)? Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-03 10:59 Message: Logged In: YES user_id=642936 I would like to emphasize on point (2) of my previous post, which should be resolved before 2.5 comes out. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-18 12:00 Message: Logged In: YES user_id=642936 On (1): agreed. On (2): There is still a debug message emitted for a bad checksum: In TarInfo.frombuf() at the bottom a ValueError is raised if they don't match and is passed on to TarFile.next() where it is put out as a debug message using the _dbg() method in the except clause. The debug message where it is now (r46040) is senseless because the try-block will be left when TarInfo.frombuf() fails . On (3): You're right, I attached a patch that adds another Exception HeaderError which is raised in TarInfo.frombuf() instead of ValueError in case of a bad header. I hope that is acceptable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-18 08:11 Message: Logged In: YES user_id=849994 Jim: I agree with your comments and have committed an improved version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:25 Message: Logged In: YES user_id=764593 (1) Why change the exception style? When raising an instance, the style guide (PEP-8, http:// www.python.org/dev/peps/pep-0008/) prefers to construct that instance; the older form is left over from String exceptions and will be removed in Python 3. I could understand leaving them as they were, but if you're going to change them to make them consistent, why not use the current format? (2) Why get rid of the debug messages (such as the checksum check) entirely? Guarding them in if self.debug, I would understand. (3) I wouldn't count on str(e) (where e is any ValueError instance) being as meaningful as the (current version's) ReadError("empty, unreadable or compressed file") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-10 18:26 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 45954. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-09 15:52 Message: Logged In: YES user_id=642936 Here is testtar.tar to replace Lib/test/testtar.tar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 From noreply at sourceforge.net Sun Jul 9 16:07:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 07:07:16 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 12:11 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2006-07-09 17:07 Message: Logged In: YES user_id=358087 IIRC (the patch was done a long time ago), Python uses the process handle as the process id, I've tested the code and it worked. I agree that the patch need more work, mainly the error return value. At least on Python 2.4.3, TerminateProcess is not exposed by _subprocss (or subprocess). I still think that having a way to kill a process OOTB on win32 is very important, pretty swamped right now but I'll try to improve the patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-06 08:05 Message: Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 07:54 Message: Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-06 04:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 19:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Sun Jul 9 16:42:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 07:42:07 -0700 Subject: [Patches] [ python-Patches-1519566 ] turtle.py: correcting begin_fill Message-ID: Patches item #1519566, was opened at 2006-07-09 14:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: turtle.py: correcting begin_fill Initial Comment: In the current version of turtle.py begin_fill behaves exactly like fill(True). That means, that a call begin_fill() does a filling if another call begin_fill() has been issued before. To see this, try: >>> from turtle import * >>> begin_fill() >>> forward(100) >>> left(50) >>> forward(100) >>> begin_fill() >>> Imho this is not very plausible. (Of course, calling begin_fill twice is also not very plausible, but may be done by beginners inadvertedly). I encountered this problem first in a course for teachers I gave today. I propose that begin_fill should behave differently, namely start a new filling (as it's stated in the docs, which are - as you see- in fact for this function incomplete) and discard the butlast call to begin_fill. If one really needed the current functionality , one could resort to fill(). I discussed this with Vern Ceder at edupython list and he replied: Personally, my vote would be to fix it as you suggest and submit the patch as soon as possible - it may just be possible for it to make it into the 2.5 release. --- Please note, that begin_fill was just added to 2.5, so this slight change of functionality shouldn't create problems. So I submit a patch, which does this. This patch also eliminates the attribute _tofill, which is not needed anymore. (I think it was needed in the old circle method). Moreover the forward(0) call at the end of the definition of the fill method is eliminated as it does nothing but unnecessarily duplicate a pair of coordinates to the _path list The patch contains also a short addition to the demo() function, which shows that now concave forms can be filled. Subsequently I'll add a short patch to the turtle.py Documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519566&group_id=5470 From noreply at sourceforge.net Sun Jul 9 16:45:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 07:45:26 -0700 Subject: [Patches] [ python-Patches-1519566 ] turtle.py: correcting begin_fill Message-ID: Patches item #1519566, was opened at 2006-07-09 14:42 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) >Assigned to: Martin v. L??wis (loewis) Summary: turtle.py: correcting begin_fill Initial Comment: In the current version of turtle.py begin_fill behaves exactly like fill(True). That means, that a call begin_fill() does a filling if another call begin_fill() has been issued before. To see this, try: >>> from turtle import * >>> begin_fill() >>> forward(100) >>> left(50) >>> forward(100) >>> begin_fill() >>> Imho this is not very plausible. (Of course, calling begin_fill twice is also not very plausible, but may be done by beginners inadvertedly). I encountered this problem first in a course for teachers I gave today. I propose that begin_fill should behave differently, namely start a new filling (as it's stated in the docs, which are - as you see- in fact for this function incomplete) and discard the butlast call to begin_fill. If one really needed the current functionality , one could resort to fill(). I discussed this with Vern Ceder at edupython list and he replied: Personally, my vote would be to fix it as you suggest and submit the patch as soon as possible - it may just be possible for it to make it into the 2.5 release. --- Please note, that begin_fill was just added to 2.5, so this slight change of functionality shouldn't create problems. So I submit a patch, which does this. This patch also eliminates the attribute _tofill, which is not needed anymore. (I think it was needed in the old circle method). Moreover the forward(0) call at the end of the definition of the fill method is eliminated as it does nothing but unnecessarily duplicate a pair of coordinates to the _path list The patch contains also a short addition to the demo() function, which shows that now concave forms can be filled. Subsequently I'll add a short patch to the turtle.py Documentation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519566&group_id=5470 From noreply at sourceforge.net Sun Jul 9 19:45:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 10:45:56 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 11:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-09 19:45 Message: Logged In: YES user_id=21627 "Python uses the process handle as process id" makes no real sense - Win32 works differently. You can't terminate a process without a handle, and you can't just "use" the process id as the handle. Perhaps some use cases for the API would need to be defined first. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-07-09 16:07 Message: Logged In: YES user_id=358087 IIRC (the patch was done a long time ago), Python uses the process handle as the process id, I've tested the code and it worked. I agree that the patch need more work, mainly the error return value. At least on Python 2.4.3, TerminateProcess is not exposed by _subprocss (or subprocess). I still think that having a way to kill a process OOTB on win32 is very important, pretty swamped right now but I'll try to improve the patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-06 07:05 Message: Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 06:54 Message: Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-06 03:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 18:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Sun Jul 9 21:21:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 12:21:54 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 05:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-07-09 15:21 Message: Logged In: YES user_id=31435 Martin, FYI, on Windows the os.spawn() functions return the process handle, so that's the natural use case: killing a process spawned by Python's os.spawn*(). This is a little confusing because the spawn() functions are documented as returning "the process ID", and verbiage inside the spawn docs explains that it doesn't really mean "process ID" on Windows. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-09 13:45 Message: Logged In: YES user_id=21627 "Python uses the process handle as process id" makes no real sense - Win32 works differently. You can't terminate a process without a handle, and you can't just "use" the process id as the handle. Perhaps some use cases for the API would need to be defined first. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-07-09 10:07 Message: Logged In: YES user_id=358087 IIRC (the patch was done a long time ago), Python uses the process handle as the process id, I've tested the code and it worked. I agree that the patch need more work, mainly the error return value. At least on Python 2.4.3, TerminateProcess is not exposed by _subprocss (or subprocess). I still think that having a way to kill a process OOTB on win32 is very important, pretty swamped right now but I'll try to improve the patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-06 01:05 Message: Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 00:54 Message: Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-05 21:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 12:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Sun Jul 9 23:20:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 14:20:39 -0700 Subject: [Patches] [ python-Patches-1446922 ] Patch for bug 1441486: bad unary minus folding in compiler Message-ID: Patches item #1446922, was opened at 2006-03-10 02:33 Message generated for change (Settings changed) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Grant Olson (logistix) >Assigned to: Neil Schemenauer (nascheme) Summary: Patch for bug 1441486: bad unary minus folding in compiler Initial Comment: In the old compiler, there was a optimization in com_factor that folded a unary minus against a constant. In the new AST, it looks like numbers are converted from strings into PyObjects earlier in the pipeline. The compiler does fold a unary minus against a constant, but since the PyObject has already been created, it may return a PyLong when a PyInt is sufficient. This patch adds a check that will convert a PyLong object back into a PyInt if possible. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 21:20 Message: Logged In: YES user_id=35752 Fixed in SVN rev 50495. I did the folding in the CST->AST phase, similar to how it was done in the old compiler. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 07:39 Message: Logged In: YES user_id=33168 Thanks! Unfortunately, this patch leaves the long in co_consts: >>> def foo(): ... x = -9223372036854775808 ... >>> foo.func_code.co_consts (None, 9223372036854775808L, -9223372036854775808) This is a 64-bit system. On 2.4, there is only sys.minint: Python 2.4.2 (#1, Oct 30 2005, 21:35:48) >>> def foo(): ... x = -9223372036854775808 ... >>> foo.func_code.co_consts (None, -9223372036854775808) Can you revise the patch to fix this? I cleaned up some things. Attached is an updated version I was using. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446922&group_id=5470 From noreply at sourceforge.net Sun Jul 9 23:30:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 14:30:34 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 11:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-09 23:30 Message: Logged In: YES user_id=21627 Ah, ok. Given that _subprocess already offers that functionality, I'm still -1 on adding it to "nt". Adding some kind of OpenProcess might be more useful, but then, people can get to all these functions through ctypes, as well. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-09 21:21 Message: Logged In: YES user_id=31435 Martin, FYI, on Windows the os.spawn() functions return the process handle, so that's the natural use case: killing a process spawned by Python's os.spawn*(). This is a little confusing because the spawn() functions are documented as returning "the process ID", and verbiage inside the spawn docs explains that it doesn't really mean "process ID" on Windows. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-09 19:45 Message: Logged In: YES user_id=21627 "Python uses the process handle as process id" makes no real sense - Win32 works differently. You can't terminate a process without a handle, and you can't just "use" the process id as the handle. Perhaps some use cases for the API would need to be defined first. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-07-09 16:07 Message: Logged In: YES user_id=358087 IIRC (the patch was done a long time ago), Python uses the process handle as the process id, I've tested the code and it worked. I agree that the patch need more work, mainly the error return value. At least on Python 2.4.3, TerminateProcess is not exposed by _subprocss (or subprocess). I still think that having a way to kill a process OOTB on win32 is very important, pretty swamped right now but I'll try to improve the patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-06 07:05 Message: Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 06:54 Message: Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-06 03:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 18:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Mon Jul 10 00:02:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 15:02:40 -0700 Subject: [Patches] [ python-Patches-1220212 ] os.kill on windows Message-ID: Patches item #1220212, was opened at 2005-06-14 05:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: os.kill on windows Initial Comment: This patch enables os.kill on windows. This way there will be an "out of the box" way to kill process on windows. Basically kill calls TerminateProcess and the "signal" paramer will be the process return code. Don't have CVS access today so I'm sending the whole files in a zip (sorry). Also some config wizard need to change the winsows configuration and set HAVE_KILL. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-07-09 18:02 Message: Logged In: YES user_id=31435 Well, os.waitpid() on Windows also takes a process handle. This was (of course) deliberate, so that os.waitpid() could use the thingie returned by os.spawn() on Windows. If os.kill() were ever added to Windows, I think it would be quite natural for it to take a process handle too, and for the same reason (Python code mixing os.{spawn,waitpid,kill} could be the same across platforms). Zope's ZODB relies on mixing spawn and waitpid this way, and Zope's ZRS implements its own kill function on Windows so that the rest of the Python code can just do kill(id) on all platforms (where `id` is always something obtained from os.spawn()). ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-09 17:30 Message: Logged In: YES user_id=21627 Ah, ok. Given that _subprocess already offers that functionality, I'm still -1 on adding it to "nt". Adding some kind of OpenProcess might be more useful, but then, people can get to all these functions through ctypes, as well. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-09 15:21 Message: Logged In: YES user_id=31435 Martin, FYI, on Windows the os.spawn() functions return the process handle, so that's the natural use case: killing a process spawned by Python's os.spawn*(). This is a little confusing because the spawn() functions are documented as returning "the process ID", and verbiage inside the spawn docs explains that it doesn't really mean "process ID" on Windows. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-09 13:45 Message: Logged In: YES user_id=21627 "Python uses the process handle as process id" makes no real sense - Win32 works differently. You can't terminate a process without a handle, and you can't just "use" the process id as the handle. Perhaps some use cases for the API would need to be defined first. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2006-07-09 10:07 Message: Logged In: YES user_id=358087 IIRC (the patch was done a long time ago), Python uses the process handle as the process id, I've tested the code and it worked. I agree that the patch need more work, mainly the error return value. At least on Python 2.4.3, TerminateProcess is not exposed by _subprocss (or subprocess). I still think that having a way to kill a process OOTB on win32 is very important, pretty swamped right now but I'll try to improve the patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-06 01:05 Message: Logged In: YES user_id=21627 As is, the patch has two major problems: - TerminateProcess expects a process handle, not a process ID. This makes the patch pretty useless: To kill a process other than yourself, you need to call OpenProcess first (or obtain a process handle in some other way, e.g. by having created it). - if the call fails, it uses posix_error to report the problem. However, posix_error expects that errno is set, which isn't the case here. Furthermore, this patch would duplicate _subprocess.TerminateProcess, which already exposes TerminateProcess (plus allowing to specify the exit code). So in its current form, I think the patch should be rejected. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 00:54 Message: Logged In: YES user_id=33168 Karl, can you test this patch and verify it works? It would be especially helpful to test on Win9x and WinNT variants. Are there tests included? Is there a doc patch? These are some of the potential reasons this isn't included. As for me, I can't test this patch (no windows), so it's a non-starter. If you'd like to help out, we could use the help. ---------------------------------------------------------------------- Comment By: Karl Pietrzak (kap4020) Date: 2006-07-05 21:44 Message: Logged In: YES user_id=1537118 So is there a reason this isn't in the latest Python? The patch is tiny. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2005-07-11 12:30 Message: Logged In: YES user_id=21627 Converted to unified diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220212&group_id=5470 From noreply at sourceforge.net Mon Jul 10 02:23:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 17:23:28 -0700 Subject: [Patches] [ python-Patches-1484695 ] tarfile.py fix for #1471427 and updates Message-ID: Patches item #1484695, was opened at 2006-05-09 06:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) >Group: Python 2.6 Status: Open >Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.py fix for #1471427 and updates Initial Comment: I have assembled a patch that adds some features from my own development path of tarfile.py (http://www.gustaebel.de/lars/tarfile/) and fixes #1471427 which made some restructuring necessary. The patch affects Lib/tarfile.py, Lib/test/test_tarfile.py and Doc/lib/libtarfile.tex. The changes the patch makes are as follows: Sets the version to 0.8.0. Support for base256 encoding of number fields (nti() and itn()). Up to now this was hardcoded for the filesize field to allow filesizes greater than 8 GB but it is applicable to all number fields. TarInfo.tobuf() has a boolean argument "posix" which controls how number fields are written (base256 is non-posix). Both unsigned and signed (Sun and NeXT) checksums are calculated. Header validation moves from TarFile.next() to TarInfo.frombuf(). A header is valid only if its checksum is okay, in the past the checksum was calculated but ignored. The TarFile.next() method was rearranged which makes header processing clearer and more abstract and fixes bug #1471427. However, this change breaks the interface for subclassing in order to implement custom member types but makes it much easier at the same time. The mapping TYPE_METH was removed. A new test ReadGNULongTest was added to test_tarfile.py and testtar.tar was updated to be able to test the GNU extensions LONGNAME and LONGLINK. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 17:23 Message: Logged In: YES user_id=33168 Ah, I see. I checked in the patch to remove the debug message since it's dead code. We are in feature freeze for 2.5, so I've updated the patch, attached it, set the group to 2.6. We can add the patch after 2.5 is out in a month or so. Committed revision 50503. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-09 01:01 Message: Logged In: YES user_id=642936 I attached a tar with two diffs: only-tarfile.diff only removes the debug message. complete-with-headererror.diff removes the debug message and adds the HeaderError exception to TarInfo.frombuf() mentioned below. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-04 15:04 Message: Logged In: YES user_id=33168 Lars, I don't see the debug (_dbg) call. Which version are you using? I didn't see r46040 in Lib/tafile.py for either 2.5 or 2.4. Could you point me to file/line/version where there's a problem (or just make a patch)? Thanks. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-07-03 01:59 Message: Logged In: YES user_id=642936 I would like to emphasize on point (2) of my previous post, which should be resolved before 2.5 comes out. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-18 03:00 Message: Logged In: YES user_id=642936 On (1): agreed. On (2): There is still a debug message emitted for a bad checksum: In TarInfo.frombuf() at the bottom a ValueError is raised if they don't match and is passed on to TarFile.next() where it is put out as a debug message using the _dbg() method in the except clause. The debug message where it is now (r46040) is senseless because the try-block will be left when TarInfo.frombuf() fails . On (3): You're right, I attached a patch that adds another Exception HeaderError which is raised in TarInfo.frombuf() instead of ValueError in case of a bad header. I hope that is acceptable. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 23:11 Message: Logged In: YES user_id=849994 Jim: I agree with your comments and have committed an improved version. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-17 15:25 Message: Logged In: YES user_id=764593 (1) Why change the exception style? When raising an instance, the style guide (PEP-8, http:// www.python.org/dev/peps/pep-0008/) prefers to construct that instance; the older form is left over from String exceptions and will be removed in Python 3. I could understand leaving them as they were, but if you're going to change them to make them consistent, why not use the current format? (2) Why get rid of the debug messages (such as the checksum check) entirely? Guarding them in if self.debug, I would understand. (3) I wouldn't count on str(e) (where e is any ValueError instance) being as meaningful as the (current version's) ReadError("empty, unreadable or compressed file") ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-10 09:26 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 45954. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2006-05-09 06:52 Message: Logged In: YES user_id=642936 Here is testtar.tar to replace Lib/test/testtar.tar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1484695&group_id=5470 From noreply at sourceforge.net Mon Jul 10 03:19:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 18:19:08 -0700 Subject: [Patches] [ python-Patches-1516912 ] OpenVMS patches Modules directory Message-ID: Patches item #1516912, was opened at 2006-07-04 04:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516912&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Pi?ronne Jean-Fran?ois (pieronne) >Assigned to: Neal Norwitz (nnorwitz) Summary: OpenVMS patches Modules directory Initial Comment: All the patches are delimited by #if defined(__VMS) #endif or some variant of this 8 files are patches: bz2module.c OpenVMS don't support univ_newline so set f_univ_newline to 0 cryptmodule.c OpenVMS don't have a crypt routine, so use the openssl routine instead dlmodule.c OpenVMS CRTL dlopen routine doesn't do any check so in routine dl_open add a test for file accessibility fpectlmodule.c Add the correct setting for Alpha and IA64 processor getpath.c remove old patch and add default PREFIX posixmodule.c OpenVMS don't have any urandom routine, so use the openssl routine instead selectmodule.c clean an old previous patch, move most of the specific VMS code to specific routine (would be probably cleaner) Regards, Jean-Fran??ois ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 18:19 Message: Logged In: YES user_id=33168 Thanks! I made some minor modifications. Committed revision 50504. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1516912&group_id=5470 From noreply at sourceforge.net Mon Jul 10 04:37:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 09 Jul 2006 19:37:04 -0700 Subject: [Patches] [ python-Patches-1504046 ] Rough documentation for xml.etree.ElementTree Message-ID: Patches item #1504046, was opened at 2006-06-10 09:30 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Neal Norwitz (nnorwitz) Summary: Rough documentation for xml.etree.ElementTree Initial Comment: Here's a text version (based on the existing PythonDoc documentation). Feel free to grab it and convert it to Latex. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 19:37 Message: Logged In: YES user_id=33168 I left it as it is which I think is xml.etree. I don't know which is correct, but at least we have something in svn that is better than nothing. Feel free to change it to whatever you want. Thanks Engelbert. Committed revision 50506. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2006-06-30 04:36 Message: Logged In: YES user_id=147070 http://members.chello.at/engelbert.gruber/python/elementtree -docpy.tar.gz contains the modified (for docpy-writer) documentation and a translation into latex. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 12:30 Message: Logged In: YES user_id=3066 There's an open question on whether this should be documented as xml.etree or xmlcore.etree. With the introduction of the xmlcore package in Python 2.5, should we document xml.etree or xmlcore.etree? If someone installs PyXML with Python 2.5, I don't think they're going to get xml.etree, which will be really confusing. We can be sure that xmlcore.etree will be there. I'd rather not propogate the pain caused "xml" package insanity any further. Posted also to python-dev: http://mail.python.org/pipermail/python-dev/2006-June/065816.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1504046&group_id=5470 From noreply at sourceforge.net Mon Jul 10 09:32:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 00:32:10 -0700 Subject: [Patches] [ python-Patches-1519796 ] Fix for #1513611 and #1511497; xml.sax imports Message-ID: Patches item #1519796, was opened at 2006-07-10 09:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #1513611 and #1511497; xml.sax imports Initial Comment: Package xmlcore.sax currently uses a mix of realtive and absolute imports. This caused the following bugs: http://python.org/sf/1513611 http://python.org/sf/1511497 This patch fixes it, by using relative imports. I tried using absolute imports, but then some of the tests in the attached test_xml_importing module fail. The tests are separate because I don't know how to include setUp() and tearDown() methods into non unittest based tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 From noreply at sourceforge.net Mon Jul 10 09:59:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 00:59:31 -0700 Subject: [Patches] [ python-Patches-1519796 ] Fix for #1513611 and #1511497; xml.sax imports Message-ID: Patches item #1519796, was opened at 2006-07-10 09:32 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for #1513611 and #1511497; xml.sax imports Initial Comment: Package xmlcore.sax currently uses a mix of realtive and absolute imports. This caused the following bugs: http://python.org/sf/1513611 http://python.org/sf/1511497 This patch fixes it, by using relative imports. I tried using absolute imports, but then some of the tests in the attached test_xml_importing module fail. The tests are separate because I don't know how to include setUp() and tearDown() methods into non unittest based tests. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-07-10 09:59 Message: Logged In: YES user_id=1326842 Attaching a new patch and updated tests, since I missed that make_parser() uses __import__(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 From noreply at sourceforge.net Mon Jul 10 15:32:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 06:32:18 -0700 Subject: [Patches] [ python-Patches-1519796 ] Fix for #1513611 and #1511497; xml.sax imports Message-ID: Patches item #1519796, was opened at 2006-07-10 07:32 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) >Assigned to: Martin v. L??wis (loewis) Summary: Fix for #1513611 and #1511497; xml.sax imports Initial Comment: Package xmlcore.sax currently uses a mix of realtive and absolute imports. This caused the following bugs: http://python.org/sf/1513611 http://python.org/sf/1511497 This patch fixes it, by using relative imports. I tried using absolute imports, but then some of the tests in the attached test_xml_importing module fail. The tests are separate because I don't know how to include setUp() and tearDown() methods into non unittest based tests. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-10 07:59 Message: Logged In: YES user_id=1326842 Attaching a new patch and updated tests, since I missed that make_parser() uses __import__(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 From noreply at sourceforge.net Mon Jul 10 18:48:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 09:48:52 -0700 Subject: [Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling. Message-ID: Patches item #1520081, was opened at 2006-07-10 18:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ernest ter Kuile (ernestjwtk) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.py change to ease option handling. Initial Comment: Telnetlib.py has no automatic telnet option handling mechanism except for the possibility to register a callback function. If set, the callback is used for each option as they arrive. If not set, options are negated. Using this mechanisme is not elegant when extending the telnet class in a OO way, and there is currently no other way to handle this data. This patch adds to the callback mechanisme by also calling an internal function handle_option(), which by default doesn't do much. This function could then do something usefull when extending the telnet class. For backwards compatibility, the current callback mechanism has not been removed, and, if used, has priority over the internal function handle_option(), which is then ignored. Furthermore to explain the telnet option system, a lot of comments have been added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 From noreply at sourceforge.net Mon Jul 10 19:09:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 10:09:46 -0700 Subject: [Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling. Message-ID: Patches item #1520081, was opened at 2006-07-10 18:48 Message generated for change (Comment added) made by ernestjwtk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ernest ter Kuile (ernestjwtk) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib.py change to ease option handling. Initial Comment: Telnetlib.py has no automatic telnet option handling mechanism except for the possibility to register a callback function. If set, the callback is used for each option as they arrive. If not set, options are negated. Using this mechanisme is not elegant when extending the telnet class in a OO way, and there is currently no other way to handle this data. This patch adds to the callback mechanisme by also calling an internal function handle_option(), which by default doesn't do much. This function could then do something usefull when extending the telnet class. For backwards compatibility, the current callback mechanism has not been removed, and, if used, has priority over the internal function handle_option(), which is then ignored. Furthermore to explain the telnet option system, a lot of comments have been added. ---------------------------------------------------------------------- >Comment By: Ernest ter Kuile (ernestjwtk) Date: 2006-07-10 19:09 Message: Logged In: YES user_id=1552811 Changed Category to be Library instead of Modules. Telnetlib.py is not a module (sorry for confusion) Also attached is diff to latest svn telnetlib had some timeout patch had been applied. (as of 10 july) Actually, first look shows no difference between this one and the previous one, but just to be sure. Ernest ter Kuile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470 From noreply at sourceforge.net Mon Jul 10 19:26:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 10:26:13 -0700 Subject: [Patches] [ python-Patches-1494140 ] Documentation for new Struct object Message-ID: Patches item #1494140, was opened at 2006-05-24 18:26 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for new Struct object Initial Comment: The performance enhancements to the struct module (patch #1493701) are implemented by having a Struct object, which is a compiled structure. This text file documents these new struct objects. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-07-11 02:26 Message: Logged In: YES user_id=671362 Patch for the TeX style doc. Bob, can you work on updating the main section right after 2.5 b2? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-26 22:05 Message: Logged In: YES user_id=139309 We're going to need to revise this patch some more to document the new pack_to function (for Martin Blais' hotbuf work) Additionally we'll probably also want to revise the main struct documentation to talk about bounds checking and avoiding the creation of long objects. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 23:32 Message: Logged In: YES user_id=139309 That's clearly a typo. I've attached a new version of the patch that removes those two letters. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-25 06:03 Message: Logged In: YES user_id=764593 Shouldn't self.size be the number of bytes required to *pack * the structure? The number required to *unpack* seems like it ought to include tuple overhead and such... ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 00:35 Message: Logged In: YES user_id=139309 New patch attached, fixed unpack documentation, added unpack_from method. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 23:54 Message: Logged In: YES user_id=139309 Hold up on this patch, I need to revise it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 From noreply at sourceforge.net Mon Jul 10 23:03:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 14:03:23 -0700 Subject: [Patches] [ python-Patches-1519796 ] Fix for #1513611 and #1511497; xml.sax imports Message-ID: Patches item #1519796, was opened at 2006-07-10 09:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for #1513611 and #1511497; xml.sax imports Initial Comment: Package xmlcore.sax currently uses a mix of realtive and absolute imports. This caused the following bugs: http://python.org/sf/1513611 http://python.org/sf/1511497 This patch fixes it, by using relative imports. I tried using absolute imports, but then some of the tests in the attached test_xml_importing module fail. The tests are separate because I don't know how to include setUp() and tearDown() methods into non unittest based tests. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-10 23:03 Message: Logged In: YES user_id=21627 Assigning to Fred Drake, who introduced xmlcore. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-10 09:59 Message: Logged In: YES user_id=1326842 Attaching a new patch and updated tests, since I missed that make_parser() uses __import__(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 From noreply at sourceforge.net Tue Jul 11 00:12:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 15:12:01 -0700 Subject: [Patches] [ python-Patches-1519566 ] turtle.py: correcting begin_fill Message-ID: Patches item #1519566, was opened at 2006-07-09 16:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: turtle.py: correcting begin_fill Initial Comment: In the current version of turtle.py begin_fill behaves exactly like fill(True). That means, that a call begin_fill() does a filling if another call begin_fill() has been issued before. To see this, try: >>> from turtle import * >>> begin_fill() >>> forward(100) >>> left(50) >>> forward(100) >>> begin_fill() >>> Imho this is not very plausible. (Of course, calling begin_fill twice is also not very plausible, but may be done by beginners inadvertedly). I encountered this problem first in a course for teachers I gave today. I propose that begin_fill should behave differently, namely start a new filling (as it's stated in the docs, which are - as you see- in fact for this function incomplete) and discard the butlast call to begin_fill. If one really needed the current functionality , one could resort to fill(). I discussed this with Vern Ceder at edupython list and he replied: Personally, my vote would be to fix it as you suggest and submit the patch as soon as possible - it may just be possible for it to make it into the 2.5 release. --- Please note, that begin_fill was just added to 2.5, so this slight change of functionality shouldn't create problems. So I submit a patch, which does this. This patch also eliminates the attribute _tofill, which is not needed anymore. (I think it was needed in the old circle method). Moreover the forward(0) call at the end of the definition of the fill method is eliminated as it does nothing but unnecessarily duplicate a pair of coordinates to the _path list The patch contains also a short addition to the demo() function, which shows that now concave forms can be filled. Subsequently I'll add a short patch to the turtle.py Documentation ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-11 00:12 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r50553. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519566&group_id=5470 From noreply at sourceforge.net Tue Jul 11 03:45:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 18:45:07 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 21:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Georg Brandl (gbrandl) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Tue Jul 11 04:57:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 19:57:00 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 18:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Georg Brandl (gbrandl) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 19:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Tue Jul 11 05:07:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 10 Jul 2006 20:07:18 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 21:45 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Georg Brandl (gbrandl) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-10 23:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 22:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Tue Jul 11 09:04:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 00:04:38 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-11 01:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Georg Brandl (gbrandl) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 07:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-11 03:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 02:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Tue Jul 11 10:56:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 01:56:45 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-11 01:45 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 07:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-11 03:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 02:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Tue Jul 11 15:29:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 06:29:37 -0700 Subject: [Patches] [ python-Patches-1472257 ] pdb: fix for #1472251('run/runeval' commands bug) Message-ID: Patches item #1472257, was opened at 2006-04-18 12:22 Message generated for change (Comment added) made by jakamkon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 3 Submitted By: Kuba Ko??czyk (jakamkon) Assigned to: Nobody/Anonymous (nobody) Summary: pdb: fix for #1472251('run/runeval' commands bug) Initial Comment: This simple patch ensure that the first argument to the 'run/runeval' functions is string.See Bug #1472251 for more details. ---------------------------------------------------------------------- >Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-07-11 13:29 Message: Logged In: YES user_id=1491175 Arguments 2) and 3) convinced me that my patch is not proper solution.It simply introduces unnecessary restrictions to bdb.I'll set this to Closed/Rejected.Thanks for all your comments. ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-07-11 13:29 Message: Logged In: YES user_id=1491175 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-25 16:25 Message: Logged In: YES user_id=971153 ...1.Why?bdb.py prints informations about breakpoints to stdout in bpprint function.... I am not sure printing to stdout in bpprint was a good decision! Really, if bdb is intended to be a low-level debugging module, it should not print anything to stdout... ..I included new patch.What's your opinion?... A couple of comments: 1) the latest pdb's output goes through redirection. The patch does not.. 2) Is it really necessary to restrict pdb's run() to strings? Being able to pass a code object seems like a useful thing (I know that pdb docs explicitly say that the 1st arg must be a string) 3) finally, I guess I am not sure about the general approach to argument type checking in stdlib. (is it really pdb's business to check run() arguments? E.g if bdb's run() supports other types (say, UserString or file), pdb's type checking would have to change)... I guess, I am -0 on this patch.. ---------------------------------------------------------------------- Comment By: Kuba Ko??czyk (jakamkon) Date: 2006-06-19 14:44 Message: Logged In: YES user_id=1491175 1.Why?bdb.py prints informations about breakpoints to stdout in bpprint function. 2.This is correct.Comment right before run function should be updated to point that bdb.py's run could be used also with code objects. According to the pdb's documentation, run command should be invoked only with statement given as a string.Run's argument checking and error message could be placed in pdb's run function.I included new patch.What's your opinion? ---------------------------------------------------------------------- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 22:07 Message: Logged In: YES user_id=971153 I am not sure whether the original bug is indeed a bug. (see discussion of that bug)... And even if #1472251 is deemed a bug, the patch has a couple of unrelated problems: 1. bdb.py should not print anything on stdout 2. current bdb.py's run() accepts code objects, the patch breaks it. Should the patch be rejected? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1472257&group_id=5470 From noreply at sourceforge.net Tue Jul 11 15:37:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 06:37:09 -0700 Subject: [Patches] [ python-Patches-1515745 ] urllib2 redirection fix Message-ID: Patches item #1515745, was opened at 2006-07-02 07:35 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Petr Gladkikh (batyi) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 redirection fix Initial Comment: When redirecting to a new URL, new request is missing attached data (e.g. when redirecting POST or PUT). Thus redirected request will be different than original one. The patch fixes this problem. My environment is: OS: WindowsXP, Python version: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-07-11 14:37 Message: Logged In: YES user_id=261020 Jim's right that there's no bug here. Also, it already is optional if you're prepared to subclass or reimplement HTTPRedirectHandler. Method redirect_request is documented and can do whatever you like. This issue was discussed at length here: http://python.org/sf/549151 Could somebody close this patch? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-03 03:10 Message: Logged In: YES user_id=764593 With a POST (and presumably a PUT), this is required by the standard. I won't argue that it is sensible (why would you send the data to someone whose redirects you don't trust), but it is the standard. Making this a settable option would probably be OK, though. -jJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 From noreply at sourceforge.net Tue Jul 11 20:02:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 11:02:50 -0700 Subject: [Patches] [ python-Patches-1515745 ] urllib2 redirection fix Message-ID: Patches item #1515745, was opened at 2006-07-01 23:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Petr Gladkikh (batyi) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 redirection fix Initial Comment: When redirecting to a new URL, new request is missing attached data (e.g. when redirecting POST or PUT). Thus redirected request will be different than original one. The patch fixes this problem. My environment is: OS: WindowsXP, Python version: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 11:02 Message: Logged In: YES user_id=33168 Closed as requested. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-07-11 06:37 Message: Logged In: YES user_id=261020 Jim's right that there's no bug here. Also, it already is optional if you're prepared to subclass or reimplement HTTPRedirectHandler. Method redirect_request is documented and can do whatever you like. This issue was discussed at length here: http://python.org/sf/549151 Could somebody close this patch? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-02 19:10 Message: Logged In: YES user_id=764593 With a POST (and presumably a PUT), this is required by the standard. I won't argue that it is sensible (why would you send the data to someone whose redirects you don't trust), but it is the standard. Making this a settable option would probably be OK, though. -jJ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515745&group_id=5470 From noreply at sourceforge.net Tue Jul 11 22:27:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 13:27:53 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 17:49 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Anthony Baxter (anthonybaxter) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-07-11 16:27 Message: Logged In: YES user_id=764593 traceback.py.diff3.txt is the minimal fix. traceback.py.diff2.txt is a better fix. test_traceback.py.diff.txt strengthens the test cases (not just this bug; a few others tests as well.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-02 22:12 Message: Logged In: YES user_id=764593 I forgot to mention in this tracker that this is a regression against 2.4, so it should be fixed even post- beta, unless we decide to never fix it as part of deprecation. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-01 07:21 Message: Logged In: YES user_id=764593 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-01 07:19 Message: Logged In: NO ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:53 Message: Logged In: YES user_id=764593 For misc/news, I suggest something like "Fixed an obscure traceback regression when (deprecated) strings are raised." ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 17:52 Message: Logged In: YES user_id=764593 In order to fix it, I also broke out some repeated code into a subfunction, and switched some logic to a more modern idiom -- these parts *could* be separated if need be, but I won't be able to do it this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 From noreply at sourceforge.net Wed Jul 12 01:51:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 16:51:53 -0700 Subject: [Patches] [ python-Patches-1520877 ] Distutils bugfix: Read $AR from the environment/Makefile. Message-ID: Patches item #1520877, was opened at 2006-07-11 23:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils and setup.py Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: Distutils bugfix: Read $AR from the environment/Makefile. Initial Comment: Distutils reads CC, CFLAGS, etc, but fails to read AR. This seems like a simple oversight, which this small patch corrects. Tested on Redhat 9.0 on x86 Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520877&group_id=5470 From noreply at sourceforge.net Wed Jul 12 01:56:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 16:56:10 -0700 Subject: [Patches] [ python-Patches-1520879 ] make install change: Allow $DESTDIR to be relative Message-ID: Patches item #1520879, was opened at 2006-07-11 23:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: make install change: Allow $DESTDIR to be relative Initial Comment: This patch allows the $DESTDIR variable used in 'make install' to be a relative path. It also avoids constructing filenames starting with double slashes ('//') when DESTDIR is an absolute path. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520879&group_id=5470 From noreply at sourceforge.net Wed Jul 12 02:53:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 17:53:08 -0700 Subject: [Patches] [ python-Patches-1520904 ] Fix tests that assume they can write to Lib/test Message-ID: Patches item #1520904, was opened at 2006-07-12 00:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: Fix tests that assume they can write to Lib/test Initial Comment: A number of bsddb tests, as well as test_tarfile, create temporary files in Lib/ or {prefix}/lib/pythonX.Y/ . This change uses tempfile.gettempdir() instead. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520904&group_id=5470 From noreply at sourceforge.net Wed Jul 12 03:18:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 11 Jul 2006 18:18:42 -0700 Subject: [Patches] [ python-Patches-1520905 ] Don't produce core file in test_subprocess.py Message-ID: Patches item #1520905, was opened at 2006-07-12 01:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: Don't produce core file in test_subprocess.py Initial Comment: The test_run_abort() testcase in test_subprocess.py produces a core file on Unix systems, even though the test is successful. This can be confusing or alarming to someone who runs 'make test' and then finds that the Python interpreter apparently crashed. Tested on Red Hat Linux 9 on x86. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 From noreply at sourceforge.net Wed Jul 12 10:47:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Jul 2006 01:47:05 -0700 Subject: [Patches] [ python-Patches-1521051 ] Extra configurability for doctest TestCases Message-ID: Patches item #1521051, was opened at 2006-07-12 16:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Russell Keith-Magee (freakboy) Assigned to: Nobody/Anonymous (nobody) Summary: Extra configurability for doctest TestCases Initial Comment: DocTestRunner can be modified by end users to override default testing behaviour when executing doctests. Similarly, DocTestCase can be extended to override default setup/teardown behaviour. However, when a DocTestSuite is used to discover doctests, it is not possible to specify a user-modified Runner or TestCase. This patch (against svn revision 46884 of Lib/doctest.py) enables end users to specify the class that is used to construct DocTest test cases, and the runner that is used to run DocTest test cases. By default, DocTestSuite will continue to instantiate DocTestRunner and DocTestCase instances as before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521051&group_id=5470 From noreply at sourceforge.net Wed Jul 12 15:20:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Jul 2006 06:20:41 -0700 Subject: [Patches] [ python-Patches-1481112 ] Python long option support Message-ID: Patches item #1481112, was opened at 2006-05-03 13:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1481112&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Heiko Wundram (hwundram) Assigned to: Martin v. L??wis (loewis) Summary: Python long option support Initial Comment: The attached patch implements long option support for Python. It changes the optstring found in Modules/main.c, specifying brackets for the long name of a corresponding option name. The patch is backward compatible in that it doesn't change the behaviour of _PyOS_GetOpt for any old format string, except on [:()], which are explicitly excluded for matching an option. This shouldn't break any code, though. The patch is against Python 2.4.3. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-12 13:20 Message: Logged In: YES user_id=849994 Rejecting as per python-dev discussion. There was a pronouncement from Guido that only --help, --version and /? for Win should be added. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-04 20:21 Message: Logged In: YES user_id=791932 Small extension to completely conform to Microsoft long-opt semantics: --= is equivalent to: /: under Windows with the latest patch. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-04 19:16 Message: Logged In: YES user_id=791932 The latest patch takes into account all constructive ideas that have been proposed on python-dev for this enhancement. It implements / support on Windows for long options, and adds ? as a possible option to get help. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-04 06:14 Message: Logged In: YES user_id=791932 I just posted a mail to python-dev explaining my rationale behind this patch. Maybe you could answer there... ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-04 06:06 Message: Logged In: YES user_id=791932 The rationale behind this patch is to enable python to answer to --version and --help, which are pretty much standard command-line options with GNU utilities, and increasingly common amongst BSD utilities. I developed this patch, answering to a request on c.l.p where people were asking for Python to answer to --version, and thought I could generalize it a bit so that long options can also be used for other arguments. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-05-04 04:56 Message: Logged In: YES user_id=21627 I actually wonder what the rationale for this patch is. The command line options of Python seem very clear to me; I don't see the need for long options. This should be discussed on python-dev. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-03 19:32 Message: Logged In: YES user_id=791932 Final patch which should conform to PEP-7 completely. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-03 18:59 Message: Logged In: YES user_id=791932 I'll redo the patch with vim now, emacs doesn't like doing 8 spaces indents, at least as far as I can get it configured... Anyway, I assign the copyright to any code contained in this patch to the PSF. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-03 18:53 Message: Logged In: YES user_id=849994 Please update the patch to follow Python C style guidelines (PEP 7), especially use 8-space tabs to indent. Also, it might be good to send a copyright assignment to the PSF for a patch of this magnitude. Otherwise, I think that this is a desirable feature, at least for --help and --version. ---------------------------------------------------------------------- Comment By: Heiko Wundram (hwundram) Date: 2006-05-03 18:37 Message: Logged In: YES user_id=791932 The attached patch is against the current subversion trunk, and implements long options with possible arguments after an =-sign. It has partial matching for options, erroring out on ambiguous matches of the command line arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1481112&group_id=5470 From noreply at sourceforge.net Wed Jul 12 15:21:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Jul 2006 06:21:58 -0700 Subject: [Patches] [ python-Patches-1521179 ] --help and --version long options Message-ID: Patches item #1521179, was opened at 2006-07-12 13:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: --help and --version long options Initial Comment: As per BDFL pronouncement, here's a patch implementing --help, --version and /? for Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521179&group_id=5470 From noreply at sourceforge.net Wed Jul 12 15:32:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Jul 2006 06:32:50 -0700 Subject: [Patches] [ python-Patches-1521196 ] smtplib login fails with aol smtp server Message-ID: Patches item #1521196, was opened at 2006-07-12 09:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521196&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Peter (ps1956) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib login fails with aol smtp server Initial Comment: Sending email to AOL's smtp server fails with "501 INVALID SASL FORMAT OR LENGTH". This patch allows the default order (AUTH_CRAM_MD5, AUTH_PLAIN, AUTH_LOGIN) used to select the AUTH method to be overridden with a new optional preferred_auths parameter. By changing the order so that AUTH_LOGIN comes before AUTH_PLAIN, AOL's smtp server is happy. This patch may be useful for other stmp servers that fail on login when using the default AUTH selection order. Sample usage: if aol: auths = [smtplib.AUTH_CRAM_MD5, smtplib.AUTH_LOGIN, smtplib.AUTH_PLAIN] smtp.login(fromUser.split("@")[0], passwd, auths) else: smtp.login(fromUser, passwd) I tested the patch using python 2.4.3 on slackware 10.2 (kernel 2.4.32). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521196&group_id=5470 From noreply at sourceforge.net Wed Jul 12 17:32:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 12 Jul 2006 08:32:06 -0700 Subject: [Patches] [ python-Patches-1521179 ] --help and --version long options Message-ID: Patches item #1521179, was opened at 2006-07-12 13:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: --help and --version long options Initial Comment: As per BDFL pronouncement, here's a patch implementing --help, --version and /? for Windows. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-12 15:32 Message: Logged In: YES user_id=849994 Rev. 50607. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521179&group_id=5470 From noreply at sourceforge.net Thu Jul 13 15:21:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 06:21:21 -0700 Subject: [Patches] [ python-Patches-1521817 ] Reintroduce index checking in 1-element ctypes arrays Message-ID: Patches item #1521817, was opened at 2006-07-13 15:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Reintroduce index checking in 1-element ctypes arrays Initial Comment: This patch removes the special casing of 1-sized arrays in ctypes. Currently, 1-sized arrays do *no* index checking in indexing or slicing operations. The idea was to have 1-sized arrays operate as variable sized data types. It was a bad idea, as it turns out, since it breaks a very common pattern: iterating over arrays. All this code would have to be special cased when the size of the array is one. According to a RFC on the ctypes-users list it seems that nobody uses this feature, which is not astonishing since it was only very recently added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 From noreply at sourceforge.net Thu Jul 13 16:58:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 07:58:35 -0700 Subject: [Patches] [ python-Patches-1521874 ] Fix grammatical errors in Doc/howto/doanddont.tex Message-ID: Patches item #1521874, was opened at 2006-07-13 10:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix grammatical errors in Doc/howto/doanddont.tex Initial Comment: The attached patch fixes two grammatical errors in Doc/howto/doanddont.tex, present as of r50618. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521874&group_id=5470 From noreply at sourceforge.net Thu Jul 13 17:09:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 08:09:48 -0700 Subject: [Patches] [ python-Patches-1521882 ] Give Cookie.py its own _idmap Message-ID: Patches item #1521882, was opened at 2006-07-13 11:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521882&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Give Cookie.py its own _idmap Initial Comment: Currently, Lib/Cookie.py relies on being able to import _idmap -- an internal implementation detail -- from string.py. Given that string.py includes a comment "Note that Cookie.py bogusly uses _idmap :(", it seems this might be something worth fixing. The attached patch resolves this issue by having Cookie.py generate its own copy of _idmap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521882&group_id=5470 From noreply at sourceforge.net Thu Jul 13 18:05:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 09:05:34 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 21:45 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Georg Brandl (gbrandl) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-13 12:05 Message: Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 03:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-10 23:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 22:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Thu Jul 13 21:47:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 12:47:34 -0700 Subject: [Patches] [ python-Patches-1522038 ] Add some explication to PEP 3100 Message-ID: Patches item #1522038, was opened at 2006-07-13 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522038&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Add some explication to PEP 3100 Initial Comment: The attached patch adds notes to PEP 3100 explaining why operator.isCallable() and operator.sequenceIncludes() are to be removed come Python 3000. This patch is in reaction to this python-3000 thread: http://mail.python.org/pipermail/python-3000/2006-July/002488.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522038&group_id=5470 From noreply at sourceforge.net Thu Jul 13 22:10:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 13:10:57 -0700 Subject: [Patches] [ python-Patches-1522059 ] Remove operator.truth() and operator.abs() Message-ID: Patches item #1522059, was opened at 2006-07-13 16:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove operator.truth() and operator.abs() Initial Comment: operator.truth() and operator.abs() are both intended to be passed to higher-order function like map, reduce, filter, etc. However, both of these are redundant with the builtins bool() and abs(), respectively. The attached patch will remove operator.truth() and .abs() for Python 3000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522059&group_id=5470 From noreply at sourceforge.net Fri Jul 14 01:59:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 16:59:16 -0700 Subject: [Patches] [ python-Patches-1522211 ] Improve docs for filter() Message-ID: Patches item #1522211, was opened at 2006-07-13 19:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Improve docs for filter() Initial Comment: The attached patch augments the documentation for filter() by detailing how filter() treats subclasses of str, unicode and tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 From noreply at sourceforge.net Fri Jul 14 02:00:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 17:00:25 -0700 Subject: [Patches] [ python-Patches-1522211 ] Improve docs for filter() Message-ID: Patches item #1522211, was opened at 2006-07-13 19:59 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Improve docs for filter() Initial Comment: The attached patch augments the documentation for filter() by detailing how filter() treats subclasses of str, unicode and tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 From noreply at sourceforge.net Fri Jul 14 05:26:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 20:26:16 -0700 Subject: [Patches] [ python-Patches-1522211 ] Improve docs for filter() Message-ID: Patches item #1522211, was opened at 2006-07-13 18:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Improve docs for filter() Initial Comment: The attached patch augments the documentation for filter() by detailing how filter() treats subclasses of str, unicode and tuple. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-13 22:26 Message: Logged In: YES user_id=80475 Sorry, no thanks. This does not make the docs better. It makes it harder to understand the general operation of filter() and goes into implementation specific details which may not apply to other implementations of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 From noreply at sourceforge.net Fri Jul 14 05:45:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 13 Jul 2006 20:45:01 -0700 Subject: [Patches] [ python-Patches-1521817 ] Reintroduce index checking in 1-element ctypes arrays Message-ID: Patches item #1521817, was opened at 2006-07-13 23:21 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Reintroduce index checking in 1-element ctypes arrays Initial Comment: This patch removes the special casing of 1-sized arrays in ctypes. Currently, 1-sized arrays do *no* index checking in indexing or slicing operations. The idea was to have 1-sized arrays operate as variable sized data types. It was a bad idea, as it turns out, since it breaks a very common pattern: iterating over arrays. All this code would have to be special cased when the size of the array is one. According to a RFC on the ctypes-users list it seems that nobody uses this feature, which is not astonishing since it was only very recently added. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-14 13:45 Message: Logged In: YES user_id=29957 Sounds fine to checkin now. Please make sure to add a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 From noreply at sourceforge.net Fri Jul 14 09:13:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 00:13:08 -0700 Subject: [Patches] [ python-Patches-1521874 ] Fix grammatical errors in Doc/howto/doanddont.tex Message-ID: Patches item #1521874, was opened at 2006-07-13 14:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix grammatical errors in Doc/howto/doanddont.tex Initial Comment: The attached patch fixes two grammatical errors in Doc/howto/doanddont.tex, present as of r50618. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-14 07:13 Message: Logged In: YES user_id=849994 Fixed in rev. 50629. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521874&group_id=5470 From noreply at sourceforge.net Fri Jul 14 10:19:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 01:19:28 -0700 Subject: [Patches] [ python-Patches-1522400 ] irda socket support Message-ID: Patches item #1522400, was opened at 2006-07-14 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: ?????? (qyb) Assigned to: Nobody/Anonymous (nobody) Summary: irda socket support Initial Comment: the patch implements IrDA socket's getsockaddrarg() support under Linux and Win32 platform. Now we can connect to IrDA device from a socket object and build more flexible wireless application. I have test it under Windows XP. Simple test: connect a irda device from socket import * from struct import * s = socket(AF_IRDA, SOCK_STREAM) info = s.getsockopt(SOL_IRLMP, IRLMP_ENUMDEVICES, 1024) list = info[4:] list addr = unpack('I', list[:4])[0] s.connect((addr, "IrDA:IrCOMM")) s.close() Complex test: Get mobile phone's deviceinfo by OBEX protocol from struct import * from socket import * def obex_genheader_byte_stream(opcode, byte_stream): length = htons(3 + len(byte_stream)) return chr(opcode) + pack('h', length) + byte_stream def obex_genheader_unicode(opcode, unistr): unistr = unistr + '\x00\x00' length = htons(3 + len(unistr)) return chr(opcode) + pack('h', length) + unistr def obex_connect(sockobj, target): if (len(target)): header = obex_genheader_byte_stream(0x46, target) else: header = '' length = htons(7 + len(header)) cmd = chr(0x80) + pack('h', length) + chr(0x10) + chr(0) + pack('h', htons(1024)) + header sockobj.sendall(cmd) return True def obex_get(sockobj, filename): header = obex_genheader_unicode(0x01, filename) length = htons(3 + len(header)) cmd = chr(0x83) + pack('h', length) + header sockobj.sendall(cmd) return True s = socket(AF_IRDA, SOCK_STREAM) info = s.getsockopt(SOL_IRLMP, IRLMP_ENUMDEVICES, 1024) list = info[4:] addr = unpack('I', list[:4])[0] s.connect((addr, "IrDA:OBEX")) obex_connect(s, '') response = s.recv(4096) obex_get(s, "telecom/devinfo.txt".encode('utf-16be')) response = s.recv(4096) print response[6:] s.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522400&group_id=5470 From noreply at sourceforge.net Fri Jul 14 16:23:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 07:23:29 -0700 Subject: [Patches] [ python-Patches-1522587 ] Tix.Grid patch Message-ID: Patches item #1522587, was opened at 2006-07-14 16:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522587&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: klappnase (klappnase) Assigned to: Martin v. L??wis (loewis) Summary: Tix.Grid patch Initial Comment: This patch fixes some issues with the newly added Tix.Grid widget: - fixed entrycget() and entryconfigure() - fixed typo in yview_moveto() - replaced self with self._w in function calls - changed xview() and yview() to accept parameters, as in Tkinter - added _dummyGrid class and fixed the ScrolledGrid - added a few useful constants -added methods: - anchor_clear() - anchor_set() - bdtype() - dragsite_set(), _get() and _clear() and corresponding dropsite_() methods - edit_apply() and edit_set() - format_border() and format_grid() - geometryinfo() - index() - move_row() and move_column() - selection_set(), _get(). _clear(), _toggle() and _includes() - size_row() and size_column() - sort_row() and sort_column() - unset() I also added some (hopefully useful) docstrings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522587&group_id=5470 From noreply at sourceforge.net Fri Jul 14 20:02:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 11:02:58 -0700 Subject: [Patches] [ python-Patches-1522704 ] XML Test Runner for unittest module Message-ID: Patches item #1522704, was opened at 2006-07-14 20:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522704&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Rittau (srittau) Assigned to: Nobody/Anonymous (nobody) Summary: XML Test Runner for unittest module Initial Comment: JUnit features an XML Test Runner that enables test output in XML format. This is very useful for buildbots and similar automated setups. PyUnit (the unittest module) lacks this capability. The attached file implements such an XML Test Runner and the matching unit tests. I did not try to generate a patch to the current SVN version and leave that to more capable hand. I think the current unittest module should probably changed into a unittest package like this: unittest/__init__.py - the current unittest.py file unittest/xmlrunner.py - the new XML runner Later __init__.py could be split into even more files like textrunner.py etc. I would like to hear about any improvements that the patch needs (even minor ones). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522704&group_id=5470 From noreply at sourceforge.net Fri Jul 14 20:06:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 11:06:44 -0700 Subject: [Patches] [ python-Patches-1521817 ] Reintroduce index checking in 1-element ctypes arrays Message-ID: Patches item #1521817, was opened at 2006-07-13 15:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Reintroduce index checking in 1-element ctypes arrays Initial Comment: This patch removes the special casing of 1-sized arrays in ctypes. Currently, 1-sized arrays do *no* index checking in indexing or slicing operations. The idea was to have 1-sized arrays operate as variable sized data types. It was a bad idea, as it turns out, since it breaks a very common pattern: iterating over arrays. All this code would have to be special cased when the size of the array is one. According to a RFC on the ctypes-users list it seems that nobody uses this feature, which is not astonishing since it was only very recently added. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-07-14 20:06 Message: Logged In: YES user_id=11105 Thanks. Committed as revision 50643. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-14 05:45 Message: Logged In: YES user_id=29957 Sounds fine to checkin now. Please make sure to add a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 From noreply at sourceforge.net Fri Jul 14 20:07:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 11:07:07 -0700 Subject: [Patches] [ python-Patches-1521817 ] Reintroduce index checking in 1-element ctypes arrays Message-ID: Patches item #1521817, was opened at 2006-07-13 15:21 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: Reintroduce index checking in 1-element ctypes arrays Initial Comment: This patch removes the special casing of 1-sized arrays in ctypes. Currently, 1-sized arrays do *no* index checking in indexing or slicing operations. The idea was to have 1-sized arrays operate as variable sized data types. It was a bad idea, as it turns out, since it breaks a very common pattern: iterating over arrays. All this code would have to be special cased when the size of the array is one. According to a RFC on the ctypes-users list it seems that nobody uses this feature, which is not astonishing since it was only very recently added. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-14 20:06 Message: Logged In: YES user_id=11105 Thanks. Committed as revision 50643. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-14 05:45 Message: Logged In: YES user_id=29957 Sounds fine to checkin now. Please make sure to add a NEWS item. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1521817&group_id=5470 From noreply at sourceforge.net Sat Jul 15 03:14:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 18:14:59 -0700 Subject: [Patches] [ python-Patches-1522038 ] Add some explication to PEP 3100 Message-ID: Patches item #1522038, was opened at 2006-07-13 12:47 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522038&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Brett Cannon (bcannon) Summary: Add some explication to PEP 3100 Initial Comment: The attached patch adds notes to PEP 3100 explaining why operator.isCallable() and operator.sequenceIncludes() are to be removed come Python 3000. This patch is in reaction to this python-3000 thread: http://mail.python.org/pipermail/python-3000/2006-July/002488.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522038&group_id=5470 From noreply at sourceforge.net Sat Jul 15 08:30:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 14 Jul 2006 23:30:55 -0700 Subject: [Patches] [ python-Patches-1522400 ] irda socket support Message-ID: Patches item #1522400, was opened at 2006-07-14 16:19 Message generated for change (Settings changed) made by qyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Qiu Yingbo (qyb) Assigned to: Nobody/Anonymous (nobody) Summary: irda socket support Initial Comment: the patch implements IrDA socket's getsockaddrarg() support under Linux and Win32 platform. Now we can connect to IrDA device from a socket object and build more flexible wireless application. I have test it under Windows XP. Simple test: connect a irda device from socket import * from struct import * s = socket(AF_IRDA, SOCK_STREAM) info = s.getsockopt(SOL_IRLMP, IRLMP_ENUMDEVICES, 1024) list = info[4:] list addr = unpack('I', list[:4])[0] s.connect((addr, "IrDA:IrCOMM")) s.close() Complex test: Get mobile phone's deviceinfo by OBEX protocol from struct import * from socket import * def obex_genheader_byte_stream(opcode, byte_stream): length = htons(3 + len(byte_stream)) return chr(opcode) + pack('h', length) + byte_stream def obex_genheader_unicode(opcode, unistr): unistr = unistr + '\x00\x00' length = htons(3 + len(unistr)) return chr(opcode) + pack('h', length) + unistr def obex_connect(sockobj, target): if (len(target)): header = obex_genheader_byte_stream(0x46, target) else: header = '' length = htons(7 + len(header)) cmd = chr(0x80) + pack('h', length) + chr(0x10) + chr(0) + pack('h', htons(1024)) + header sockobj.sendall(cmd) return True def obex_get(sockobj, filename): header = obex_genheader_unicode(0x01, filename) length = htons(3 + len(header)) cmd = chr(0x83) + pack('h', length) + header sockobj.sendall(cmd) return True s = socket(AF_IRDA, SOCK_STREAM) info = s.getsockopt(SOL_IRLMP, IRLMP_ENUMDEVICES, 1024) list = info[4:] addr = unpack('I', list[:4])[0] s.connect((addr, "IrDA:OBEX")) obex_connect(s, '') response = s.recv(4096) obex_get(s, "telecom/devinfo.txt".encode('utf-16be')) response = s.recv(4096) print response[6:] s.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522400&group_id=5470 From noreply at sourceforge.net Sat Jul 15 18:33:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Jul 2006 09:33:51 -0700 Subject: [Patches] [ python-Patches-1038911 ] OS X: Can't use #!/usr/bin/pythonw Message-ID: Patches item #1038911, was opened at 2004-10-02 05:40 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nathan Gray (n8gray) Assigned to: Jack Jansen (jackjansen) Summary: OS X: Can't use #!/usr/bin/pythonw Initial Comment: At the moment, on OS X /usr/bin/pythonw2.x is a simple sh script that exec's a python interpreter within a valid OS X application bundle. The problem is that this prevents python scripts from using pythonw in the #! line. Darwin won't allow a script to act as an interpreter in a #! line. This patch replaces the shell script with a simple C program that does the same thing -- it just calls execv on the python interpreter within the OS X app bundle. Since it is a compiled executable it is allowed to act as an interpreter in #! lines. Your patch guidelines said you preferred multiple patches to be concatenated in a single file. My patch consists of a Makefile change and a new file, dist/src/Mac/OSX/pythonw.c. I've included both in the text file attached to this report. It would probably be prudent for somebody to review the Makefile change, since it's always tricky to find the right way to put a new file in someone else's build process. Thank you, -Nathan ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2006-07-15 12:33 Message: Logged In: YES user_id=139309 Python 2.5 solves this problem, but with a solution that does not descend from this patch. Additionally, the need for a python/pythonw distinction at all is solved in Python 2.5 with framework builds. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2006-04-03 12:48 Message: Logged In: YES user_id=265183 Is there a good reason why this patch has not been implemented ? It seems really strange to me that #!/usr/bin/pythonw doesn't work (but #!/usr/bin/python and #!/usr/bin/env pythonw do) because pythonw is made a shell script. Perhaps the root problem is that a symlink doesn't work, which is because of some other flaw in the interpreter somewhere? ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-04 16:16 Message: Logged In: YES user_id=121553 The issue is that sometimes you *do* care where python is installed, and you want to be sure to get the system python and not, for example, the Fink python. At the moment, the only solution is to use a gangly #! line like: #! /System/Library/Frameworks/Python.framework/Resources/ Python.app/Contents/MacOS/Python and you'll only figure that out if you're clever enough to understand why #!/usr/bin/python works but #!/usr/bin/pythonw doesn't. Mainly, it's just needlessly confusing to have a python interpreter that works from the command line but doesn't work in a #! line. It's unfortunate that the distinction between python and pythonw is necessary, but as long as it is then it would be nice if at least pythonw was able to act as a drop-in replacement for python. It's pretty simple to make it work as expected, so why not do it, for the sake of consistency? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-10-04 10:34 Message: Logged In: YES user_id=1038590 As described in the python tutorial, the recommended solution to this is to use the following on the shebang line: #! /usr/bin/env pythonw this also has benefit of not caring where python is installed. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-02 21:00 Message: Logged In: YES user_id=121553 Assigning to Jack Jansen as suggested by Bob Ippolito on pythonmac-sig. ---------------------------------------------------------------------- Comment By: Nathan Gray (n8gray) Date: 2004-10-02 05:43 Message: Logged In: YES user_id=121553 By the way, the patch is against CVS head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1038911&group_id=5470 From noreply at sourceforge.net Sat Jul 15 18:53:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Jul 2006 09:53:42 -0700 Subject: [Patches] [ python-Patches-1220874 ] update the binhex module for Mach-O Message-ID: Patches item #1220874, was opened at 2005-06-14 21:27 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: update the binhex module for Mach-O Initial Comment: The binhex module only understands resource forks if os.name == 'mac', which is only true for CFM builds of Python. We haven't maintained those in years, so this has been broken for quite some time. This patch is a partial fix that allows it to de-binhex the resource fork on Mach-O, but it still doesn't do the type/creator stuff. I'm currently only using it to create one of those pesky "Icon\r" files, so this is all I fixed and tested. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2006-07-15 12:53 Message: Logged In: YES user_id=139309 Committed revision 50667. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-22 17:11 Message: Logged In: YES user_id=139309 I definitely added it, but I forgot to click the stupid box. I hate sourceforge. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2005-06-22 06:45 Message: Logged In: YES user_id=580910 You forgot to add the patch. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-06-14 21:29 Message: Logged In: YES user_id=139309 this is also a backport candidate ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1220874&group_id=5470 From noreply at sourceforge.net Sat Jul 15 18:32:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 15 Jul 2006 09:32:44 -0700 Subject: [Patches] [ python-Patches-1056561 ] python / pythonw replacement in C Message-ID: Patches item #1056561, was opened at 2004-10-29 01:26 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1056561&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Michiel de Hoon (mdehoon) Assigned to: Jack Jansen (jackjansen) Summary: python / pythonw replacement in C Initial Comment: I rewrote the shell script pythonw2.4 (which usually lives in /usr/local/bin) in C. With a link from python to this C program, users can: a) Run "python" to use the framework version of Python, which exists in a valid application bundle (unlike the current python in /usr/local/bin); b) Use "#!/usr/local/bin/python" as the first line in python scripts (unlike the current pythonw in /usr/local/bin, which Mac OS X interprets to be a shell script). Hence, (I believe) this C program avoids the problems with python and pythonw that are in /usr/local/bin now. The setup in /usr/local/bin would be: lrwxr-xr-x python -> python2.4 -rwxr-xr-x python2.4 where python2.4 is the C program calling /Library/Frameworks/Python.framework/Versions/2.4/bin/python with the appropriate command-line arguments. Some modification of the C code may be needed for it to be consistent with the Python installation process. Note also that for the non-framework build, python2.4 can just be a link (as it is now). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2006-07-15 12:32 Message: Logged In: YES user_id=139309 This is a duplicate of http://python.org/sf/1038911 Python 2.5 has similar functionality (but does not descend from this patch) ---------------------------------------------------------------------- Comment By: Michiel de Hoon (mdehoon) Date: 2004-10-29 01:35 Message: Logged In: YES user_id=488897 I just noticed that Nathan Gray had already submitted a similar patch (my impression from the pythonmac-sig archive was that that hadn't happened yet, but I guess I should have checked existing patches before submitting one). Well I hope maybe it is still useful for something. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1056561&group_id=5470 From noreply at sourceforge.net Sun Jul 16 13:41:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Jul 2006 04:41:04 -0700 Subject: [Patches] [ python-Patches-1523356 ] (partial?) fix for Misc/python-config.in Message-ID: Patches item #1523356, was opened at 2006-07-16 07:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1523356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M. Levinson (levinsm) Assigned to: Nobody/Anonymous (nobody) Summary: (partial?) fix for Misc/python-config.in Initial Comment: I've found that the current output from python-config isn't quite right for compiling and linking an application with an embedded interpreter on platforms that need $(SYSLIBS). The attached patch removes extraneous directories from the include path and adds the missing libraries, which was enough to make it work for me in my limited testing. But even with these changes, I haven't quite managed to convince myself that python-config is currently general enough to work on all platforms. Couldn't $(LINKFORSHARED) also be required in some cases, for example? And perhaps there are other missing flags I haven't thought of. I feel it's worth double-checking because python-config strikes me as a potentially convenient tool, but only if its output is known to be correct: If a broken version ever became widely installed in the wild then even if it were to be fixed in some future release, the authors of other applications would forever after need to worry about distinguishing between good and bad versions of python-config before relying on its output, which would undermine its convenience. (Also: if/when it is included in a release, a man page and some mention of it in Doc/ext would be a plus. :-) I hope this is helpful. Thanks for all your great work! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1523356&group_id=5470 From noreply at sourceforge.net Sun Jul 16 19:23:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Jul 2006 10:23:52 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-05-31 13:41 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 05:22 Message: Logged In: YES user_id=1344176 I've updated the patch per jackdied's suggestion, plus improved the test suite a bit. The patch is now against r47103. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 16:13 Message: Logged In: YES user_id=591932 The patch can be simplified by always calling PySequence_Tuple() and doing the decref instead of special casing tuples. If you pass PySequence_Tuple() a tuple it will incref it and hand it back to you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-05-31 21:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Sun Jul 16 19:24:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Jul 2006 10:24:02 -0700 Subject: [Patches] [ python-Patches-1498363 ] Improve super() objects support for implicit method calls Message-ID: Patches item #1498363, was opened at 2006-05-31 13:31 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Improve super() objects support for implicit method calls Initial Comment: The attached patch lets super() objects pass on implicit __getitem__, __setitem__, __delitem__, __len__ and __hash__ calls. For example, to use len() with super() objects, one must currently do something like super(X, X()).__len__() Likewise for __getitem__, super(X, X()).__getitem__(item) That's ugly. This patch lets these be spelled as len(super(X, X())) and super(X, X())[item], respectively. The patch also includes documentation updates and tests for the new functionality. The patch was taken against r46582. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 08:22 Message: Logged In: YES user_id=1344176 The patch has been updated to reflect the current SVN state, r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 From noreply at sourceforge.net Sun Jul 16 19:24:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Jul 2006 10:24:24 -0700 Subject: [Patches] [ python-Patches-1473257 ] Add a gi_code attr to generators Message-ID: Patches item #1473257, was opened at 2006-04-19 17:39 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Phillip J. Eby (pje) Summary: Add a gi_code attr to generators Initial Comment: In the test suite for one of my packages, I've used something like gen.gi_frame.f_code.co_name to help make human-readable assertions about when certain generators are run deep inside the application. This was possible because Python 2.4 guaranteed that gi_frame was always a frame instance, even after the generator exhausted itself. In Python 2.5, however, gi_frame is None when the generator has run till exhaustion, meaning that I can't always get to f_code.co_name. I'd like to add a gi_code attribute to generators that would allow users to access the code object behind the generator, even when gi_frame is None. This attribute would be read-only and would follow this rule: >>> def f(): ... yield 5 ... >>> g = f() >>> g.gi_code is f.func_code True >>> The attached patch (against r45570) implements the proposed attribute (in Include/genobject.h and Objects/genobject.c) and adds test cases to Lib/test/test_generators.py for this attribute. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-05-18 13:13 Message: Logged In: YES user_id=1344176 In addition to updating the main patch to r46040, I've included a diff against Misc/NEWS to make mention of the gi_code attribute. Any thoughts on getting this into 2.5a3? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-04-30 07:17 Message: Logged In: YES user_id=849994 Phillip, do you have an opinion on this one? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-04-29 17:11 Message: Logged In: YES user_id=1344176 I've updated the patch; it's now against SVN r45808. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1473257&group_id=5470 From noreply at sourceforge.net Mon Jul 17 03:00:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 16 Jul 2006 18:00:19 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-05-31 12:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-16 20:00 Message: Logged In: YES user_id=80475 Since starmap() is documented to behave like "yield function(*iterable.next())", I think this fixup can be considered a bugfix. If Anthony is okay with this, it should into Py2.5. While Jack's suggested modification leads to a conceptually simpler patch, I prefer an alternate version that only calls PySequence_Tuple() if PyTuple_CheckExact() fails. That will make sure that we don't slow down the most common case. Also, I prefer slightly different updates to the docs and test suite. If Anthony approves for inclusion in Py2.5, I will upload my own version of a patch to starmap(). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 04:22 Message: Logged In: YES user_id=1344176 I've updated the patch per jackdied's suggestion, plus improved the test suite a bit. The patch is now against r47103. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 15:13 Message: Logged In: YES user_id=591932 The patch can be simplified by always calling PySequence_Tuple() and doing the decref instead of special casing tuples. If you pass PySequence_Tuple() a tuple it will incref it and hand it back to you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-05-31 20:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Mon Jul 17 09:45:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 00:45:19 -0700 Subject: [Patches] [ python-Patches-1475523 ] patch fixing #1448060 (gettext.py bug) Message-ID: Patches item #1475523, was opened at 2006-04-24 15:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 7 Submitted By: Thenault Sylvain (syt) Assigned to: Martin v. L??wis (loewis) Summary: patch fixing #1448060 (gettext.py bug) Initial Comment: Here is a patch for the bug described in https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470 It follows the latest Martin followup as I understand it. I'm not sure if multi-lines field handling should be totally discarded while reading metadata headers (as implemented), or if it should only be discarded for the content-type and plural-forms header. If one think this patch isn't correct, please comment so I can fix it. Notice that if the second solution was intended, lines such as "#-#-#-#-# fr.po #-#-#-#-#\n" inserted by msgcat/msgmerge will have to be treated differently (i.e. multi-lines support but skip lines begining with a #). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-17 09:45 Message: Logged In: YES user_id=21627 The patch is wrong; it breaks the existing test case WeirdMetadataTest. I think the "just a single line" rule should be restricted to Plural-Forms; not sure whether it should apply to content-type also (but why not). I'll attach another patch that adds a test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470 From noreply at sourceforge.net Mon Jul 17 14:26:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 05:26:22 -0700 Subject: [Patches] [ python-Patches-1522211 ] Improve docs for filter() Message-ID: Patches item #1522211, was opened at 2006-07-13 19:59 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Improve docs for filter() Initial Comment: The attached patch augments the documentation for filter() by detailing how filter() treats subclasses of str, unicode and tuple. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-07-17 08:26 Message: Logged In: YES user_id=1344176 Would you support adding this information as a footnote to filter(), or perhaps somewhere else in the manual (if so, where?), or would you prefer that this part of filter()'s behaviour remain undocumented? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-13 23:26 Message: Logged In: YES user_id=80475 Sorry, no thanks. This does not make the docs better. It makes it harder to understand the general operation of filter() and goes into implementation specific details which may not apply to other implementations of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522211&group_id=5470 From noreply at sourceforge.net Mon Jul 17 14:27:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 05:27:04 -0700 Subject: [Patches] [ python-Patches-1522059 ] Remove operator.truth() and operator.abs() Message-ID: Patches item #1522059, was opened at 2006-07-13 16:10 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522059&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 3000 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Guido van Rossum (gvanrossum) Summary: Remove operator.truth() and operator.abs() Initial Comment: operator.truth() and operator.abs() are both intended to be passed to higher-order function like map, reduce, filter, etc. However, both of these are redundant with the builtins bool() and abs(), respectively. The attached patch will remove operator.truth() and .abs() for Python 3000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522059&group_id=5470 From noreply at sourceforge.net Mon Jul 17 15:05:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 06:05:24 -0700 Subject: [Patches] [ python-Patches-1498363 ] Improve super() objects support for implicit method calls Message-ID: Patches item #1498363, was opened at 2006-05-31 17:31 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Raymond Hettinger (rhettinger) Summary: Improve super() objects support for implicit method calls Initial Comment: The attached patch lets super() objects pass on implicit __getitem__, __setitem__, __delitem__, __len__ and __hash__ calls. For example, to use len() with super() objects, one must currently do something like super(X, X()).__len__() Likewise for __getitem__, super(X, X()).__getitem__(item) That's ugly. This patch lets these be spelled as len(super(X, X())) and super(X, X())[item], respectively. The patch also includes documentation updates and tests for the new functionality. The patch was taken against r46582. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 13:05 Message: Logged In: YES user_id=849994 Why only these methods? Why not __add__, __call__ etc.? Implementing all of these methods is a pain and adds considerable complexity to typeobject.c. Frankly, I don't see an improvement since you normally only call super.__getitem__ in __getitem__, and explicit is better than implicit. Raymond, do you have a second opinion? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 12:22 Message: Logged In: YES user_id=1344176 The patch has been updated to reflect the current SVN state, r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 From noreply at sourceforge.net Mon Jul 17 15:13:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 06:13:23 -0700 Subject: [Patches] [ python-Patches-1498363 ] Improve super() objects support for implicit method calls Message-ID: Patches item #1498363, was opened at 2006-05-31 13:31 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Improve super() objects support for implicit method calls Initial Comment: The attached patch lets super() objects pass on implicit __getitem__, __setitem__, __delitem__, __len__ and __hash__ calls. For example, to use len() with super() objects, one must currently do something like super(X, X()).__len__() Likewise for __getitem__, super(X, X()).__getitem__(item) That's ugly. This patch lets these be spelled as len(super(X, X())) and super(X, X())[item], respectively. The patch also includes documentation updates and tests for the new functionality. The patch was taken against r46582. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-07-17 09:13 Message: Logged In: YES user_id=1344176 I only added these particular methods because they were a) the only ones I needed at the time, b) the only ones I really had time to implement. I've now got a few more tuits freed up, so I'd be happy to implement more of these methods. As for "explicit is better than implicit", I don't see how that applies here. The same case could be made for all of Python's syntax-assisted method calls. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 09:05 Message: Logged In: YES user_id=849994 Why only these methods? Why not __add__, __call__ etc.? Implementing all of these methods is a pain and adds considerable complexity to typeobject.c. Frankly, I don't see an improvement since you normally only call super.__getitem__ in __getitem__, and explicit is better than implicit. Raymond, do you have a second opinion? ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 08:22 Message: Logged In: YES user_id=1344176 The patch has been updated to reflect the current SVN state, r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498363&group_id=5470 From noreply at sourceforge.net Mon Jul 17 15:17:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 06:17:20 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-11 01:45 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 13:17 Message: Logged In: YES user_id=849994 Looks fine, I noticed a few things: - perhaps GetSet should be named GetSetDescriptor for consistency with DataDescriptor and MemberDescriptor - in pydoc, shouldn't "data descriptor" be tested with "inspectisdatadescriptor"? - in the docs, false should be False - test_twelve should now be called test_thirteen ;) and the comment in it should be adapted - is the test suite expected to pass in implementations without the newly tested descriptor types? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-13 16:05 Message: Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 07:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-11 03:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-11 02:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Mon Jul 17 15:24:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 06:24:00 -0700 Subject: [Patches] [ python-Patches-1500609 ] Remove dependencies on the sets module Message-ID: Patches item #1500609, was opened at 2006-06-04 20:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500609&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Remove dependencies on the sets module Initial Comment: The attached patch removes several lingering dependencies on the deprecated sets module, replacing them with usages of the now-builtin set type. The patch is against r46648. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 13:23 Message: Logged In: YES user_id=849994 Committed rev. 50688. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 12:31 Message: Logged In: YES user_id=1344176 The patch has been updated to reflect SVN as of r47124. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500609&group_id=5470 From noreply at sourceforge.net Mon Jul 17 20:02:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 11:02:18 -0700 Subject: [Patches] [ python-Patches-1522704 ] XML Test Runner for unittest module Message-ID: Patches item #1522704, was opened at 2006-07-14 14:02 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522704&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Rittau (srittau) Assigned to: Nobody/Anonymous (nobody) Summary: XML Test Runner for unittest module Initial Comment: JUnit features an XML Test Runner that enables test output in XML format. This is very useful for buildbots and similar automated setups. PyUnit (the unittest module) lacks this capability. The attached file implements such an XML Test Runner and the matching unit tests. I did not try to generate a patch to the current SVN version and leave that to more capable hand. I think the current unittest module should probably changed into a unittest package like this: unittest/__init__.py - the current unittest.py file unittest/xmlrunner.py - the new XML runner Later __init__.py could be split into even more files like textrunner.py etc. I would like to hear about any improvements that the patch needs (even minor ones). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-17 14:02 Message: Logged In: YES user_id=1344176 I'd recommend that you release this somewhere like PyPI (http://cheeseshop.python.org/pypi) and see how well it does. If it flies off the shelf, then it could be considered for inclusion in the stdlib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1522704&group_id=5470 From noreply at sourceforge.net Tue Jul 18 00:07:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 15:07:28 -0700 Subject: [Patches] [ python-Patches-1479219 ] ColorDelegator - Several bug fixes Message-ID: Patches item #1479219, was opened at 2006-04-30 03:48 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Kurt B. Kaiser (kbk) Summary: ColorDelegator - Several bug fixes Initial Comment: This patch fixes the following bugs in the Bug Tracker: [ 1325071 ] "as" keyword sometimes highlighted in strings This patch fixes the following undocumented bugs: * "as" keyword colored as a keyword even in comments on the 'import' line * Comments such as "#False identity", which start with a keyword immediatly after the '#' character, aren't colored as comments. * In unicode string literals (e.g. u"bob"), the preceding 'u' character isn't colored as part of the string. But the preceding 'r' of raw string literals is. I have only added/fixed minor details, no logic changes. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-17 18:07 Message: Logged In: YES user_id=149084 rev 50692. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-06-29 11:55 Message: Logged In: YES user_id=1330769 Replaced patch file: Fixed a minor bug caused by faulty use of the "and/or trick". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1479219&group_id=5470 From noreply at sourceforge.net Tue Jul 18 05:42:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 17 Jul 2006 20:42:34 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-05-31 13:41 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-07-17 23:42 Message: Logged In: YES user_id=591932 Raymond's intuition for bare metal is correct. My suggested simplifaction slowed down the tuple case by most of a percent (I benchmarked it but left it out of the comment). Preternatural, I tell you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-16 21:00 Message: Logged In: YES user_id=80475 Since starmap() is documented to behave like "yield function(*iterable.next())", I think this fixup can be considered a bugfix. If Anthony is okay with this, it should into Py2.5. While Jack's suggested modification leads to a conceptually simpler patch, I prefer an alternate version that only calls PySequence_Tuple() if PyTuple_CheckExact() fails. That will make sure that we don't slow down the most common case. Also, I prefer slightly different updates to the docs and test suite. If Anthony approves for inclusion in Py2.5, I will upload my own version of a patch to starmap(). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 05:22 Message: Logged In: YES user_id=1344176 I've updated the patch per jackdied's suggestion, plus improved the test suite a bit. The patch is now against r47103. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-09 16:13 Message: Logged In: YES user_id=591932 The patch can be simplified by always calling PySequence_Tuple() and doing the decref instead of special casing tuples. If you pass PySequence_Tuple() a tuple it will incref it and hand it back to you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-05-31 21:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Tue Jul 18 13:08:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 04:08:57 -0700 Subject: [Patches] [ python-Patches-1524429 ] Var-default patch undid part of backtick to repr() patch Message-ID: Patches item #1524429, was opened at 2006-07-18 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Var-default patch undid part of backtick to repr() patch Initial Comment: Patch #763580, rev 46998 (Add name and value arguments to Tkinter variable classes) backed out a change made by patch #852334, rev 35267 (Replace backticks with repr() or "%r") by mistake. This patch re-replaces one instance of the persistent little backticks with repr(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524429&group_id=5470 From noreply at sourceforge.net Tue Jul 18 14:37:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 05:37:09 -0700 Subject: [Patches] [ python-Patches-1446489 ] zipfile: support for ZIP64 Message-ID: Patches item #1446489, was opened at 2006-03-09 15:58 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: zipfile: support for ZIP64 Initial Comment: The attached patch implements support for ZIP64, that is zipfiles containing very large (>4GByte) files and zipfiles that are larger than 4GByte themselves. The output of this patch can be read by pkzip (see below for the actual version I used for testing). ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-18 14:37 Message: Logged In: YES user_id=580910 this is part of 2.5, no need to keep this item open. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-11 23:09 Message: Logged In: YES user_id=580910 * The import of zipfile itself is a bug * The limit should indead be raised to (1<<31-1). * the diskno and nodisks assertions are present in the current version of zipfiles, but I agree that those should be changed into exceptions. * I've updated main to document and actually allow the -t option * TestZip64InSmallFiles restores the ZIP64_LIMIT in the tearDown method, isn't that good enough? I sure hope that nobody actually uses the file_offset. The only usecase I can think of for that is to reimplement the read method. If it turns out that this change does break existing code we could add yet another option, but lets wait with that until someone actually complains. I've uploaded a new version of the patch that fixes all these issues. BTW. Thanks for the review. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-06-11 22:33 Message: Logged In: YES user_id=413 reading zipfile64-version64.patch: * why does the zipfile module import itself? * Why is the default ZIP64 limit 1 << 30? shouldn't that be 1 << 31 - 1 (or slightly less) for maximum compatibility on existing <2GiB zip files or zips with data just under 2GiB. Don't force zip64's use unless the size actually exceeds a 32bit signed integer. * assert diskno == 0 and assert nodisks == 1 should be turned into BadZipFile exceptions with an explanation that multi-disk zip files aren't supported. * in main() document the -t option in the usage string. * TestZip64InSmallFiles changes zipfile.ZIP64_LIMIT but will not restore the value if a test fails (that could lead to other unrelated test failures). not a problem in the hopefully normal case of all tests passing. use a try: finally: to make sure that gets reset. * documentation: "Is does optionally handle" is awkward. how about "It can handle" The removal of the file_offset attribute makes sense but does make me wonder how much existing code that could break. I suggest leaving file_offset out and if any python 2.5 beta tester complains, restoring it or making scanning to look file offsets up a ZipFile option (defaulting to True). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-30 15:28 Message: Logged In: YES user_id=580910 I've added some more tests for pre-existing functionality. The unittests are still far from comprehensive, but at least touch upon most functionality of zipfile. Does anyone feel like reviewing this? I'd like to get this into python2.5. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-26 10:26 Message: Logged In: YES user_id=580910 I've attached yet another version, this version reintroduces some functionalitity that was unintentionally removed and fixes a lame bug that caused test_zipimport to fail. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-23 15:10 Message: Logged In: YES user_id=580910 I've found some time to work on this. I've added zipfile-zip64- version2.patch, this version: * Makes zip64 behaviour optional (defaults to off because zip(1) doesn't support zip64) * Is significantly faster for large zipfiles because it doesn't scan the entire zipfile just to check that the file headers are consistent with the central directory w.r.t. filename (this check is now done when trying to read a file) * Updates the reference documentation. * Adds unittests. There are two sets of tests: one set tests the behaviour of zip64 extensions using small files by lowering the zip64 cutoff point and is run every time, the other set do tests with huge zipfiles and are run when the largefile feature is enabled when running the tests. There one backward incompatible change: ZipInfo objects no longer have a file_offset attribute. That was the other reason for scanning the entire zipfile when opening it. IMNSHO this should have been a private attribute and the cost of this feature is not worth its *very* limited usefulness. As an indication of its cost: I got a 6x speedup when I removed the calculation of the file_offset attribute, something that adds up when you are dealing with huge zipfiles (I wrote this patch because I'm dealing with 10+GByte zipfiles with tens of thousands of files at work). I noticed that zipfile raises RuntimeError in some places. I've changed one of those to zipfile.BadZipfile, but others remain. I don't like this, most of them should be replaced by TypeError or ValueError exceptions. BTW. This patch also supports storing files >4GByte in the zipfile, but that feature isn't very useful because zipfile doesn't have an API for reading file data incrementally. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-05-16 09:55 Message: Logged In: YES user_id=580910 I haven't had time to work on this, all time I had to work on python related stuff has been eaten by finishing PyObjC's port to intel macs and universal binary patches. The former is now done, the latter almost so I'll have some time to work on this again especially because I'm using this patch at work and might be able to claim some time to work on this during work-hours. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-16 09:41 Message: Logged In: YES user_id=849994 Since 2.5 beta is coming close, have you made progress on the tests/docs? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-02 21:13 Message: Logged In: YES user_id=580910 The "don't use the ZIP64 extension" flag is a good idea, zipfiles that use this extension aren't readable by the infozip tools (zip and unzip on most unix systems). I'll add tests and documentation in the near future. The version of zipfile that I'm currently using also contains a patch for speeding up the opening of zipfiles, for the type of files I'm dealing with (about 11GByte large with tens of thousands of files) the speedup is very significant. I suppose it's better to file that as a separate patch after this has been approved. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-02 07:02 Message: Logged In: YES user_id=29957 I'd like to see a testcase and possibly a note for the documentation about the new semantics. Also, should it be possible to say "don't use the ZIP64 extension, instead raise an Error" for people who don't want to generate these? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-03-09 16:28 Message: Logged In: YES user_id=580910 Oops, I've uploaded the wrong file. zipfile-zip64.patch is the correct one. I've tested the correctness of created archives using this version of pkzip: pkzipc -version PKZIP(R) Server Version 8 ZIP Compression Utility for Linux X86 Copyright (C) 1989-2005 PKWARE, Inc. All Rights Reserved. Evaluation Version PKZIP Reg. U.S. Pat. and Tm. Off. Patent No. 5,051,745 Patent Pending Version 8.40.66 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1446489&group_id=5470 From noreply at sourceforge.net Tue Jul 18 18:00:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 09:00:51 -0700 Subject: [Patches] [ python-Patches-1524639 ] Fix Tkinter Tcl-commands memory-leaks Message-ID: Patches item #1524639, was opened at 2006-07-18 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Fix Tkinter Tcl-commands memory-leaks Initial Comment: Fix 8 memory-leaks by cleaning up created Tcl commands automatically. I attach a patch against Tkinter 47021. === Long explanation === I was bitten by a memory leak in Tkinter - 25MB per day on a long-running process. A net search found a couple unrelated Tkinter leaks, and gave me some clues. Investigation using the tracing feature in tkleak.py (see link) found the bug. I searched for more similar leaks, and fixed them too. The reasoning for patch #1121234 gives the reason for the changes to _register() and deletecommand(). See http://www.uk.debian.org/~graham/python/tkleak.py for my leak tracing and test script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 From noreply at sourceforge.net Tue Jul 18 18:18:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 09:18:30 -0700 Subject: [Patches] [ python-Patches-1524639 ] Fix Tkinter Tcl-commands memory-leaks Message-ID: Patches item #1524639, was opened at 2006-07-18 17:00 Message generated for change (Comment added) made by grahamh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Fix Tkinter Tcl-commands memory-leaks Initial Comment: Fix 8 memory-leaks by cleaning up created Tcl commands automatically. I attach a patch against Tkinter 47021. === Long explanation === I was bitten by a memory leak in Tkinter - 25MB per day on a long-running process. A net search found a couple unrelated Tkinter leaks, and gave me some clues. Investigation using the tracing feature in tkleak.py (see link) found the bug. I searched for more similar leaks, and fixed them too. The reasoning for patch #1121234 gives the reason for the changes to _register() and deletecommand(). See http://www.uk.debian.org/~graham/python/tkleak.py for my leak tracing and test script. ---------------------------------------------------------------------- >Comment By: Graham Horler (grahamh) Date: 2006-07-18 17:18 Message: Logged In: YES user_id=543663 The python version I am using in production is 2.1 (for historical reasons), however the memory leak bugs are in 2.1 through to 2.5. I can generate a patch against any of the older versions (e.g. 2.4) if anyone is interested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 From noreply at sourceforge.net Tue Jul 18 19:48:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 10:48:13 -0700 Subject: [Patches] [ python-Patches-1524429 ] Var-default patch undid part of backtick to repr() patch Message-ID: Patches item #1524429, was opened at 2006-07-18 13:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524429&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Var-default patch undid part of backtick to repr() patch Initial Comment: Patch #763580, rev 46998 (Add name and value arguments to Tkinter variable classes) backed out a change made by patch #852334, rev 35267 (Replace backticks with repr() or "%r") by mistake. This patch re-replaces one instance of the persistent little backticks with repr(). ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-18 19:48 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 50704 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524429&group_id=5470 From noreply at sourceforge.net Tue Jul 18 19:51:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 10:51:55 -0700 Subject: [Patches] [ python-Patches-1524724 ] Fix --without-threads build error Message-ID: Patches item #1524724, was opened at 2006-07-18 17:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix --without-threads build error Initial Comment: This patch fixes the compile error reported in #1524317. Please review this patch as I have no idea if it's the right thing to do. Thanks, Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 From noreply at sourceforge.net Tue Jul 18 20:02:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 11:02:07 -0700 Subject: [Patches] [ python-Patches-1524724 ] Fix --without-threads build error Message-ID: Patches item #1524724, was opened at 2006-07-18 13:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix --without-threads build error Initial Comment: This patch fixes the compile error reported in #1524317. Please review this patch as I have no idea if it's the right thing to do. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-07-18 14:02 Message: Logged In: YES user_id=31435 The correct way to repair this is to move the body of _PyThread_CurrentFrames above: /* Python "auto thread state" API. */ #ifdef WITH_THREAD _PyThread_CurrentFrames() should be able to return a dict regardless of whether WITH_THREAD is defined. If WITH_THREAD is not defined, sys._current_frames() should return a single-element dict, mapping the integer 0 to the main thread's frame. That should happen "by magic", but the test case will have to be changed to pass then. I have no idea how to build Python without threads on Windows, so I'm probably not the best person to try this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 From noreply at sourceforge.net Tue Jul 18 21:18:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 12:18:46 -0700 Subject: [Patches] [ python-Patches-1524724 ] Fix --without-threads build error Message-ID: Patches item #1524724, was opened at 2006-07-18 19:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix --without-threads build error Initial Comment: This patch fixes the compile error reported in #1524317. Please review this patch as I have no idea if it's the right thing to do. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-07-18 21:18 Message: Logged In: YES user_id=11105 > I have no idea how to build Python without threads on > Windows, so I'm probably not the best person to try this. Tim, you can uncomment '#define WITH_THREAD' in PC/pyconfig.h, and exclude 'threadmodule.c' from the build, for a start (this will give you the compile error that the patch is supposed to fix, plus others in _ctypes and sqlite3 code, for example ;-). Or you downgrade to linux... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-18 20:02 Message: Logged In: YES user_id=31435 The correct way to repair this is to move the body of _PyThread_CurrentFrames above: /* Python "auto thread state" API. */ #ifdef WITH_THREAD _PyThread_CurrentFrames() should be able to return a dict regardless of whether WITH_THREAD is defined. If WITH_THREAD is not defined, sys._current_frames() should return a single-element dict, mapping the integer 0 to the main thread's frame. That should happen "by magic", but the test case will have to be changed to pass then. I have no idea how to build Python without threads on Windows, so I'm probably not the best person to try this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 From noreply at sourceforge.net Tue Jul 18 21:20:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 12:20:45 -0700 Subject: [Patches] [ python-Patches-1524724 ] Fix --without-threads build error Message-ID: Patches item #1524724, was opened at 2006-07-18 17:51 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix --without-threads build error Initial Comment: This patch fixes the compile error reported in #1524317. Please review this patch as I have no idea if it's the right thing to do. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-07-18 19:20 Message: Logged In: YES user_id=1126061 Another patch coming up.. all tests pass for my on Linux with and without threads. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-18 19:18 Message: Logged In: YES user_id=11105 > I have no idea how to build Python without threads on > Windows, so I'm probably not the best person to try this. Tim, you can uncomment '#define WITH_THREAD' in PC/pyconfig.h, and exclude 'threadmodule.c' from the build, for a start (this will give you the compile error that the patch is supposed to fix, plus others in _ctypes and sqlite3 code, for example ;-). Or you downgrade to linux... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-18 18:02 Message: Logged In: YES user_id=31435 The correct way to repair this is to move the body of _PyThread_CurrentFrames above: /* Python "auto thread state" API. */ #ifdef WITH_THREAD _PyThread_CurrentFrames() should be able to return a dict regardless of whether WITH_THREAD is defined. If WITH_THREAD is not defined, sys._current_frames() should return a single-element dict, mapping the integer 0 to the main thread's frame. That should happen "by magic", but the test case will have to be changed to pass then. I have no idea how to build Python without threads on Windows, so I'm probably not the best person to try this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 From noreply at sourceforge.net Tue Jul 18 23:17:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 14:17:06 -0700 Subject: [Patches] [ python-Patches-1524825 ] ConfigParser: accept leading whitespace on options+comments Message-ID: Patches item #1524825, was opened at 2006-07-18 17:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524825&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser: accept leading whitespace on options+comments Initial Comment: ConfigParser considers leading white space before options and comments to be syntax errors, which is a bit harsh, and limits the utility of the module when parsing files originally written for other programs, such as Samba's smb.conf. The attached patch ignores leading white space on options, and skips comments with leading w.s. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524825&group_id=5470 From noreply at sourceforge.net Wed Jul 19 02:09:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 18 Jul 2006 17:09:03 -0700 Subject: [Patches] [ python-Patches-1524724 ] Fix --without-threads build error Message-ID: Patches item #1524724, was opened at 2006-07-18 13:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix --without-threads build error Initial Comment: This patch fixes the compile error reported in #1524317. Please review this patch as I have no idea if it's the right thing to do. Thanks, Matt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-07-18 20:09 Message: Logged In: YES user_id=31435 Sorry, I didn't notice the change here, and checked in the suggested kind of fix in rev 50708. Unsurprisingly, it's very much like your fix :-) test_sys still fails in a build without threads, but for an unrelated reason. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-18 15:20 Message: Logged In: YES user_id=1126061 Another patch coming up.. all tests pass for my on Linux with and without threads. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-18 15:18 Message: Logged In: YES user_id=11105 > I have no idea how to build Python without threads on > Windows, so I'm probably not the best person to try this. Tim, you can uncomment '#define WITH_THREAD' in PC/pyconfig.h, and exclude 'threadmodule.c' from the build, for a start (this will give you the compile error that the patch is supposed to fix, plus others in _ctypes and sqlite3 code, for example ;-). Or you downgrade to linux... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-18 14:02 Message: Logged In: YES user_id=31435 The correct way to repair this is to move the body of _PyThread_CurrentFrames above: /* Python "auto thread state" API. */ #ifdef WITH_THREAD _PyThread_CurrentFrames() should be able to return a dict regardless of whether WITH_THREAD is defined. If WITH_THREAD is not defined, sys._current_frames() should return a single-element dict, mapping the integer 0 to the main thread's frame. That should happen "by magic", but the test case will have to be changed to pass then. I have no idea how to build Python without threads on Windows, so I'm probably not the best person to try this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524724&group_id=5470 From noreply at sourceforge.net Wed Jul 19 12:33:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Jul 2006 03:33:34 -0700 Subject: [Patches] [ python-Patches-1524639 ] Fix Tkinter Tcl-commands memory-leaks Message-ID: Patches item #1524639, was opened at 2006-07-18 17:00 Message generated for change (Comment added) made by grahamh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Fix Tkinter Tcl-commands memory-leaks Initial Comment: Fix 8 memory-leaks by cleaning up created Tcl commands automatically. I attach a patch against Tkinter 47021. === Long explanation === I was bitten by a memory leak in Tkinter - 25MB per day on a long-running process. A net search found a couple unrelated Tkinter leaks, and gave me some clues. Investigation using the tracing feature in tkleak.py (see link) found the bug. I searched for more similar leaks, and fixed them too. The reasoning for patch #1121234 gives the reason for the changes to _register() and deletecommand(). See http://www.uk.debian.org/~graham/python/tkleak.py for my leak tracing and test script. ---------------------------------------------------------------------- >Comment By: Graham Horler (grahamh) Date: 2006-07-19 11:33 Message: Logged In: YES user_id=543663 I fixed a bug in the original patch: when destroying a window which had Variable instances attached which in turn had trace commands bound, Tkinter.py was trying to delete the commands twice, as the command was mentioned in Variable instance _tclCommands and _root()._tcl_Commands. Also fixed 4 more leaks occurring when TclError is raised after a callback has been created. I have added 6 tests to tkleak.py to test the additional 4 fixes. The patch is against 50704, hope it helps. Thanks for your hard work, and for accepting my other Tkinter.py patch. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2006-07-18 17:18 Message: Logged In: YES user_id=543663 The python version I am using in production is 2.1 (for historical reasons), however the memory leak bugs are in 2.1 through to 2.5. I can generate a patch against any of the older versions (e.g. 2.4) if anyone is interested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 From noreply at sourceforge.net Wed Jul 19 14:21:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Jul 2006 05:21:34 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 21:45 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-19 08:21 Message: Logged In: YES user_id=12800 Thanks for the comments. - I've changed it to GetSetDescriptorType - 'data descriptor' is just what Python itself prints for the type(getset_descriptor) so that's what I chose, but the test should still be with isgetsetdescriptor(). Although it's inconsistent with type(), I changed inspect.py's text to read 'getset descriptor' since I think that's more accurate. - I've changed false to \code{False} in the docs, but libinspect.text uses "true" all over the place. I am not changing that. :) - updated the test and tried to make it pass in other implementations. Since no one else has really commented either for or against, and the RM hasn't pronounced, I'm going to take silence as approval and commit these changes later today. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 09:17 Message: Logged In: YES user_id=849994 Looks fine, I noticed a few things: - perhaps GetSet should be named GetSetDescriptor for consistency with DataDescriptor and MemberDescriptor - in pydoc, shouldn't "data descriptor" be tested with "inspectisdatadescriptor"? - in the docs, false should be False - test_twelve should now be called test_thirteen ;) and the comment in it should be adapted - is the test suite expected to pass in implementations without the newly tested descriptor types? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-13 12:05 Message: Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 03:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-10 23:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 22:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Thu Jul 20 05:18:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 19 Jul 2006 20:18:19 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 18:45 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-19 20:18 Message: Logged In: YES user_id=33168 I know that Anthony has been busy. I'm -0 on the patch moreso because of the added _types.c. It's not the code that I have a problem with, but the direction we are going. At various points, we've talked about doing away with types.py. This makes that a bit messier. it's a little like the idea of adding __module_name__ at the last minute. Once this is in, it's next to impossible to remove if incorrect. Also, I'm a little concerned about how this affects other impls (PyPy, IronPython, Jython). Would you mind posting more of the impl details on py-dev and see if anyone still has an opinion? I don't recall any support pro or con. I suspect most don't really care and few people have read the patch. If you mention the impl details, I don't know if that would change anything. What is the impact of waiting? These features have been in since 2.2, right? Also, unlike Tim's threading changes, these can be exposed with a third party extension module can't they? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-19 05:21 Message: Logged In: YES user_id=12800 Thanks for the comments. - I've changed it to GetSetDescriptorType - 'data descriptor' is just what Python itself prints for the type(getset_descriptor) so that's what I chose, but the test should still be with isgetsetdescriptor(). Although it's inconsistent with type(), I changed inspect.py's text to read 'getset descriptor' since I think that's more accurate. - I've changed false to \code{False} in the docs, but libinspect.text uses "true" all over the place. I am not changing that. :) - updated the test and tried to make it pass in other implementations. Since no one else has really commented either for or against, and the RM hasn't pronounced, I'm going to take silence as approval and commit these changes later today. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 06:17 Message: Logged In: YES user_id=849994 Looks fine, I noticed a few things: - perhaps GetSet should be named GetSetDescriptor for consistency with DataDescriptor and MemberDescriptor - in pydoc, shouldn't "data descriptor" be tested with "inspectisdatadescriptor"? - in the docs, false should be False - test_twelve should now be called test_thirteen ;) and the comment in it should be adapted - is the test suite expected to pass in implementations without the newly tested descriptor types? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-13 09:05 Message: Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 00:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-10 20:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 19:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Thu Jul 20 10:29:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 01:29:23 -0700 Subject: [Patches] [ python-Patches-1525766 ] pkgutil.walk_packages ignores onerror arg Message-ID: Patches item #1525766, was opened at 2006-07-20 04:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525766&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: pkgutil.walk_packages ignores onerror arg Initial Comment: pkgutil.walk_packages doesn't properly pass the onerror argument to recursive calls. Also, the docstrings are quite lacking. Finally, it doesn't pass the name of the thing it was trying to import to the onerror handler, making using the handler for error reporting a bit difficult. This patch fixes all three of those. If the change to the onerror handler signature is controversial, I can make another patch without that at least the clearly bugfix part of this can go in py2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525766&group_id=5470 From noreply at sourceforge.net Thu Jul 20 12:28:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 03:28:26 -0700 Subject: [Patches] [ python-Patches-1525806 ] Tkdnd mouse cursor handling patch Message-ID: Patches item #1525806, was opened at 2006-07-20 12:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: klappnase (klappnase) Assigned to: Martin v. L??wis (loewis) Summary: Tkdnd mouse cursor handling patch Initial Comment: This patch improves two things I always found annoying with Tkdnd. First, it is not possible to change the default cursor ("hand2") that is used for drag and drop operations, second, this cursor always shows up on events and not on events, as I think it should. This has the ugly effect that if for example you use Tkdnd to drag items from a Listbox, each time the user selects a new item from the Listbox, the "hand2" cursor pops up. To fix the first issue I added a "dndcursor" option to the dnd_start() function, which defaults to "hand2" to keep the "classic" behavior intact. Second I added a self.dndcursor attribute to the DnDHandler class that stores this dndcursor's value; then I moved the call that actually changes the widget's cursor into the DnDHandler.on_motion() method to make sure that this cursor only shows when actually some drag occurs. self.dndcursor is set to None then, to avoid multiple calls to "widget['cursor'] == ...". I know that this is a slight change to the original behavior, however I doubt that anyone will miss it. Regards Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525806&group_id=5470 From noreply at sourceforge.net Thu Jul 20 12:43:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 03:43:13 -0700 Subject: [Patches] [ python-Patches-1500773 ] wm_attributes doesn't take keyword arguments Message-ID: Patches item #1500773, was opened at 2006-06-05 08:35 Message generated for change (Comment added) made by klappnase You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500773&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Martin v. L??wis (loewis) Summary: wm_attributes doesn't take keyword arguments Initial Comment: The Tk wm attributes command takes option arguments (from the Tk wm manual page): wm attributes window ?option value option value...? And option arguments are normally given with keyword arguments in Tkinter (most if not all widget creation functions and widget commands). The attached patch changes the wm_attributes method to take keyword arguments, so top.wm_attributes(alpha=.8) will work as expected (on Windows XP and Mac OS X). ---------------------------------------------------------------------- Comment By: klappnase (klappnase) Date: 2006-07-20 12:43 Message: Logged In: YES user_id=797929 I do not have winXP or OSX available to actually test it, but I doubt that top.wm_attributes('alpha',.8) will work; from Tk documentation it looks like you will have to write top.wm_attributes('-alpha',.8) which is in fact not what one would expect. Maybe a better solution than Greg's patch was to change wm_attributes() to accept both ways, like: def wm_attributes(self, *args, **kw): args = ('wm', 'attributes', self._w) + args + self._options({}, kw) return self.tk.call(args) so that old code will not break and the more intuitive version that Greg suggested is also legal. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-17 11:30 Message: Logged In: YES user_id=21627 This is an incompatible change. I also don't see the point; top.wm_attributes('alpha',.8) should work just fine, no? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1500773&group_id=5470 From noreply at sourceforge.net Thu Jul 20 13:03:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 04:03:55 -0700 Subject: [Patches] [ python-Patches-1525817 ] calltip awkwardly shortened Message-ID: Patches item #1525817, was opened at 2006-07-20 11:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Nobody/Anonymous (nobody) Summary: calltip awkwardly shortened Initial Comment: Because of the fact, that calltips are truncated, if the overall length exceeds some value (75), the second line is shortened too much, if the parameterlist (i. e. first line) is relatively long. Example: for the function: def setup(self, width=0.5, height=0.75, startx=None, starty=None): """ Set the size and position of the main window. ... The second line only displays Set the size and positio... although even unshortended it would be shorter than the first line. This seems counterproductive. I submit a patch, which lets both lines be at most as long as they would be with the former code. (Of course one could think of different solutions.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525817&group_id=5470 From noreply at sourceforge.net Thu Jul 20 13:12:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 04:12:43 -0700 Subject: [Patches] [ python-Patches-1525817 ] calltip awkwardly shortened Message-ID: Patches item #1525817, was opened at 2006-07-20 11:03 Message generated for change (Settings changed) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lingl (gregorlingl) >Assigned to: Martin v. L??wis (loewis) Summary: calltip awkwardly shortened Initial Comment: Because of the fact, that calltips are truncated, if the overall length exceeds some value (75), the second line is shortened too much, if the parameterlist (i. e. first line) is relatively long. Example: for the function: def setup(self, width=0.5, height=0.75, startx=None, starty=None): """ Set the size and position of the main window. ... The second line only displays Set the size and positio... although even unshortended it would be shorter than the first line. This seems counterproductive. I submit a patch, which lets both lines be at most as long as they would be with the former code. (Of course one could think of different solutions.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525817&group_id=5470 From noreply at sourceforge.net Thu Jul 20 21:28:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 12:28:46 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 21:45 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-20 15:28 Message: Logged In: YES user_id=12800 I've posted this to python-dev: http://mail.python.org/pipermail/python-dev/2006-July/067590.html Hope it helps. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-19 23:18 Message: Logged In: YES user_id=33168 I know that Anthony has been busy. I'm -0 on the patch moreso because of the added _types.c. It's not the code that I have a problem with, but the direction we are going. At various points, we've talked about doing away with types.py. This makes that a bit messier. it's a little like the idea of adding __module_name__ at the last minute. Once this is in, it's next to impossible to remove if incorrect. Also, I'm a little concerned about how this affects other impls (PyPy, IronPython, Jython). Would you mind posting more of the impl details on py-dev and see if anyone still has an opinion? I don't recall any support pro or con. I suspect most don't really care and few people have read the patch. If you mention the impl details, I don't know if that would change anything. What is the impact of waiting? These features have been in since 2.2, right? Also, unlike Tim's threading changes, these can be exposed with a third party extension module can't they? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-19 08:21 Message: Logged In: YES user_id=12800 Thanks for the comments. - I've changed it to GetSetDescriptorType - 'data descriptor' is just what Python itself prints for the type(getset_descriptor) so that's what I chose, but the test should still be with isgetsetdescriptor(). Although it's inconsistent with type(), I changed inspect.py's text to read 'getset descriptor' since I think that's more accurate. - I've changed false to \code{False} in the docs, but libinspect.text uses "true" all over the place. I am not changing that. :) - updated the test and tried to make it pass in other implementations. Since no one else has really commented either for or against, and the RM hasn't pronounced, I'm going to take silence as approval and commit these changes later today. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 09:17 Message: Logged In: YES user_id=849994 Looks fine, I noticed a few things: - perhaps GetSet should be named GetSetDescriptor for consistency with DataDescriptor and MemberDescriptor - in pydoc, shouldn't "data descriptor" be tested with "inspectisdatadescriptor"? - in the docs, false should be False - test_twelve should now be called test_thirteen ;) and the comment in it should be adapted - is the test suite expected to pass in implementations without the newly tested descriptor types? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-13 12:05 Message: Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 03:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-10 23:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 22:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Thu Jul 20 21:36:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 12:36:00 -0700 Subject: [Patches] [ python-Patches-1061803 ] Source code encoding in IDLE console Message-ID: Patches item #1061803, was opened at 2004-11-07 03:19 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 Status: Open Resolution: None >Priority: 4 Submitted By: Hye-Shik Chang (perky) >Assigned to: Martin v. L??wis (loewis) Summary: Source code encoding in IDLE console Initial Comment: Source code encoding is ignored in IDLE console sessions currently. To allow to use encodings other than Latin-1, encoding marker must be added before passing it to tokenizers. (see the attached patch) current behavior: >>> u'한글' u'\xc7\xd1\xb1\xdb' this must be like ... >>> u'한글' u'\ud55c\uae00' ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-11-07 08:01 Message: Logged In: YES user_id=55188 Surprisingly, it doesn't affect source code lines. But, I'm still wondering why it isn't counted as a distinct line. :) >>> raise ValueError Traceback (most recent call last): File "", line 1, in -toplevel- raise ValueError ValueError >>> if 1: pass raise ValueError Traceback (most recent call last): File "", line 3, in -toplevel- raise ValueError ValueError Okay. I agree that it's too late to change behavior, but it may need to write some errata item about this inconsistency of IDLE vs terminal interactive mode on documentation. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2004-11-07 05:20 Message: Logged In: YES user_id=21627 I think the patch is wrong, as it messes with the source code typed. At a minimum, line number will be off by one, no? I'm currently working on a different solution, allowing compile() to accept an encoding. However, it is too late to add this to 2.4 now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1061803&group_id=5470 From noreply at sourceforge.net Fri Jul 21 00:23:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 15:23:57 -0700 Subject: [Patches] [ python-Patches-1407280 ] ParenMatch: workaround for misinterpreting of closing parens Message-ID: Patches item #1407280, was opened at 2006-01-16 06:58 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407280&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE >Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tal Einat (taleinat) >Assigned to: Kurt B. Kaiser (kbk) Summary: ParenMatch: workaround for misinterpreting of closing parens Initial Comment: ParenMatch sometimes misinterprets closing parenthesis because it is given a bad keysym. The real bug is probably somewhere in the event handling mechanism or something. Somehow the text widget gets the right signal and the appropriate closing paren is written there. This simple patch checks the last inserted character in the text widget insted of the generated keysym, and acts accordingly. Since the function where the workaround is applied reads text from the text widget from the same index anyways, I think this workaround is actually much cleaner than checking the keysym! Works like a charm on my Python2.4 WinXP installation. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-20 18:23 Message: Logged In: YES user_id=149084 Rev 50739. Thanks for the patch! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1407280&group_id=5470 From noreply at sourceforge.net Fri Jul 21 00:26:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 20 Jul 2006 15:26:45 -0700 Subject: [Patches] [ python-Patches-906702 ] Syntax-related improvements to IDLE Message-ID: Patches item #906702, was opened at 2004-02-28 20:40 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Kurt B. Kaiser (kbk) Summary: Syntax-related improvements to IDLE Initial Comment: Yes! It's finally here! The big bunch of syntax-related improvements to IDLE! Here are a few highlights: * Completion in Visual C++ style! * CallTip windows now disappear when you don't want them! * ParenMatch now works! And in a more general way: * The MultiCall class enables one event to trigger multiple actions, so that you extensions can do whatever they want without fighting who'll know when a key is being released (for example). * The HyperParser class gives extensions a better understanding of Python code, so that CallTips and ParenMatch can now be shown from anywhere in the code (not only after opening/closing parens), and CallTips and AutoCompletion is available for complex expressions, not just for expressions which look like identifier1.identifer2. IDLE with these changes was tested by about 15 people for a few months, and beside some minor inconviniences (for example, concerning when AutoComplete chooses to complete), no critical bugs were found. Here's a complete description of all the changes to files: * Used MultiCall In order to allow multiple actions to happen when one event happens (for example, when closing a bracket, show the opening bracket and close the calltip), I wrote a class called MultiCall, which, in this case, inherits from the Text widget, and overrides binding functions, so that all matching functions will be called when an event takes place. New file: MultiCall.py EditorWindow.py: diff 1, line 8: importing MultiCall diff 2, line 89: Use MultiCallCreator(Text) instead of Text diff 3, line 226: bind set_line_and_column using virtual events, so that it will be handled by MultiCall diff 4, line 333: Control+C, in Windows keys, means both copy and break. The three lines added solve the conflict. diff 5,6,7, line 524: When changing key configuration, first the current keys must be unbinded, then the new ones binded. configDialog.py: diffs 1,2,3: When changing key configuration, first the current keys must be unbinded, then the new ones binded. * Improved parsing abilities - HyperParser The new HyperParser class uses PyParse to find information about the bracketing structure of a Python code, and to find the expression which should be evaluated in CallTips and AutoComplete. New file: HyperParser.py EditorWindow.py: diff 8, 9, line 1072: Previously, the prompt was detected textually, by searching for ">>>". This is not generic, and I changed it to look for a text tagged by the "console" tag. PyParse.py: diff 1, line 16: 'if' and 'for' can't be considered block openers now, since list comprehension was introduced. diff 2-5, line 147: using the "prompt" tag instead of searching for ">>>". diff 6-15, line 357: Now, _study2 also saves information about the bracketing structure of the code. PyShell.py: diff 1, line 1049: use the "prompt" tag instead of searching for ">>>" * Added the AutoComplete extension: This extension opens a completion window after typing a dot or when requesting a completion using tab or control+space. It will evaluate code with function calls only when requested by control+space. New file: AutoComplete.py New file: AutoCompleteWindow.py config-extensions.def: diff 5: three new bindings - force-open-completions opens a completion win and is ready to evaluate functions. autocomplete tries to complete the current word, and if fails, opens a completion window (happens on tab). try-open-completions will open a completion window when no functions calls need to be done. run.py: diffs 1,2,3: Added functions in run.py for fetching the available completions, in a method copied from the method CallTips used when fetching the call tip. * Improved the CallTips extension: This extension is greatly improved, by using HyperParser: CallTips now work for multi-lined function calls, they can be opened from anywhere inside a function brackets, and can evaluate expressions which result in functions. CallTips.py: diff 1, line 6: The future plans are already here. diff 2, line 11: no need to import string diff 3, line 14: import HyperParser diff 4, line 20: Now there's a menu command to open a calltip. diff 5, line 39: cosmetical diff 6-11, line 44: Now there's no paren_open_event and paren_close_event, since you can open CallTips without typing parens. There's force_open_calltip_event, which opens a calltip and is ready to make function calls, and try_open_calltip_event, which will not agree to do such a thing. We also use HyperParser, instead of finding the function by ourselves. diff 12, line 153: It makes more sense to show the repr of default arguments in calltips, not the str of them. CallTipWindow.py: Now, the CallTipWindow is smart - it binds events to hide itself and to position itself. Hiding occurs when the cursor gets out of the parens. config-extensions.def: diffs 1,2, line 42: We have three new bindings: force-open-calltip opens a calltip and make function calls, if needed. try-open-calltip opens a calltip if it doesn't need to make function calls. refresh-calltip will close a calltip if not needed, and change it to another one if needed. It is binded both to parenright and 0, because if the shift was raised before the zero/parenright key, the event generated is KeyRelease-0. * Improved the ParenMatch extension: First, it now works, thanks to MultiCall. Also, it now can be invoked without closing a paren, and the surrounding parens will be highlighted. ParenMatch.py: All the code for event handling and finding the paren area was rewritten, using HyperParser, and relying on MultiCall. config-extensions.def: diff 3, line 50: enable it again diff 4,5: changed the binding so we now have flash-paren, which shows the surrounding parens, and paren-closed, which is instead of flash-open-paren. Patch and enjoy! Noam Raphael ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-18 17:09 Message: Logged In: YES user_id=149084 Merged to svn trunk. Further changes to this line of development should be submitted as diffs against the trunk. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-10 00:02 Message: Logged In: YES user_id=149084 Checked in idlesyntax.10Jul05.diff on a branch: IDLE-syntax-branch. To switch to this branch: cvs up -r IDLE-syntax-branch To switch back to the IDLE trunk: cvs up -A Further changes to this line of development should be submitted as diffs against the branch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-10-09 14:30 Message: Logged In: YES user_id=149084 Add Noam Raphael's patch dated 10Jul05 ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2004-04-26 17:49 Message: Logged In: YES user_id=679426 I made a small usability bug, because I didn't parenthesize a boolean expression correctly. Line 298 should be changed to: and (self.mode==AutoComplete.COMPLETE_ATTRIBUTES or self.start): Happy Israel Independence Day! Noam Raphael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=906702&group_id=5470 From noreply at sourceforge.net Fri Jul 21 11:39:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Jul 2006 02:39:44 -0700 Subject: [Patches] [ python-Patches-1526367 ] str.__iter__ and unicode.__iter__ Message-ID: Patches item #1526367, was opened at 2006-07-21 11:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter D??rwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: str.__iter__ and unicode.__iter__ Initial Comment: This patch add iterator classes for str and unicode, as discussed here: http://mail.python.org/pipermail/python-3000/2006-July/002650.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526367&group_id=5470 From noreply at sourceforge.net Fri Jul 21 15:25:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Jul 2006 06:25:49 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 13:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Fri Jul 21 17:43:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Jul 2006 08:43:29 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 22:25 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2006-07-22 00:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Fri Jul 21 18:06:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 21 Jul 2006 09:06:30 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 13:25 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-07-21 16:06 Message: Logged In: YES user_id=1126061 Woa, my bad. That second changeset wasn't supposed to be there. That'll teach me for not scrutinizing my patches more. New version attached. Matt ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-07-21 15:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Sun Jul 23 20:22:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Jul 2006 11:22:48 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 06:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:22 Message: Logged In: YES user_id=33168 Matt, the patch isn't maintainable. For example what happens when NetBSD does support bluetooth, how could both situations be dealt with? It would be much better to verify that the bluetooth header(s) were usable at configure time. If not, the HAVE_BLUETOOTH* macros should not be defined. This would probably take a AC_TRY_COMPILE command in configure.in. Do you think you could try to work on a patch that does that? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-21 09:06 Message: Logged In: YES user_id=1126061 Woa, my bad. That second changeset wasn't supposed to be there. That'll teach me for not scrutinizing my patches more. New version attached. Matt ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-07-21 08:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Sun Jul 23 20:36:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Jul 2006 11:36:47 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 16:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) >Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Mon Jul 24 03:58:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Jul 2006 18:58:10 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 19:02 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 21:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 14:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Mon Jul 24 08:15:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 23 Jul 2006 23:15:39 -0700 Subject: [Patches] [ python-Patches-1524639 ] Fix Tkinter Tcl-commands memory-leaks Message-ID: Patches item #1524639, was opened at 2006-07-18 18:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Fix Tkinter Tcl-commands memory-leaks Initial Comment: Fix 8 memory-leaks by cleaning up created Tcl commands automatically. I attach a patch against Tkinter 47021. === Long explanation === I was bitten by a memory leak in Tkinter - 25MB per day on a long-running process. A net search found a couple unrelated Tkinter leaks, and gave me some clues. Investigation using the tracing feature in tkleak.py (see link) found the bug. I searched for more similar leaks, and fixed them too. The reasoning for patch #1121234 gives the reason for the changes to _register() and deletecommand(). See http://www.uk.debian.org/~graham/python/tkleak.py for my leak tracing and test script. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-24 08:15 Message: Logged In: YES user_id=21627 The patch looks wrong. Why are you deleting the _tkcommands of the master widget if the variable is deleted? The master could live much longer, and the commands might still be needed. What is the purpose of the changes to trace_variable? You are supposed to invoke trace_vdelete to release the callback. Why are you catching TclError in so many cases? Under what circumstances can you even get an error? I think I would prefer if this patch was split into many individual ones, each one fixing only a single bug (assuming there are multiple bugs in Tkinter). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2006-07-19 12:33 Message: Logged In: YES user_id=543663 I fixed a bug in the original patch: when destroying a window which had Variable instances attached which in turn had trace commands bound, Tkinter.py was trying to delete the commands twice, as the command was mentioned in Variable instance _tclCommands and _root()._tcl_Commands. Also fixed 4 more leaks occurring when TclError is raised after a callback has been created. I have added 6 tests to tkleak.py to test the additional 4 fixes. The patch is against 50704, hope it helps. Thanks for your hard work, and for accepting my other Tkinter.py patch. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2006-07-18 18:18 Message: Logged In: YES user_id=543663 The python version I am using in production is 2.1 (for historical reasons), however the memory leak bugs are in 2.1 through to 2.5. I can generate a patch against any of the older versions (e.g. 2.4) if anyone is interested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 From noreply at sourceforge.net Mon Jul 24 09:02:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 00:02:14 -0700 Subject: [Patches] [ python-Patches-1523356 ] (partial?) fix for Misc/python-config.in Message-ID: Patches item #1523356, was opened at 2006-07-16 13:41 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1523356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M. Levinson (levinsm) >Assigned to: Georg Brandl (gbrandl) Summary: (partial?) fix for Misc/python-config.in Initial Comment: I've found that the current output from python-config isn't quite right for compiling and linking an application with an embedded interpreter on platforms that need $(SYSLIBS). The attached patch removes extraneous directories from the include path and adds the missing libraries, which was enough to make it work for me in my limited testing. But even with these changes, I haven't quite managed to convince myself that python-config is currently general enough to work on all platforms. Couldn't $(LINKFORSHARED) also be required in some cases, for example? And perhaps there are other missing flags I haven't thought of. I feel it's worth double-checking because python-config strikes me as a potentially convenient tool, but only if its output is known to be correct: If a broken version ever became widely installed in the wild then even if it were to be fixed in some future release, the authors of other applications would forever after need to worry about distinguishing between good and bad versions of python-config before relying on its output, which would undermine its convenience. (Also: if/when it is included in a release, a man page and some mention of it in Doc/ext would be a plus. :-) I hope this is helpful. Thanks for all your great work! ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-24 09:02 Message: Logged In: YES user_id=21627 Georg, can you please take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1523356&group_id=5470 From noreply at sourceforge.net Mon Jul 24 09:43:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 00:43:51 -0700 Subject: [Patches] [ python-Patches-1527597 ] New module: miniconf Message-ID: Patches item #1527597, was opened at 2006-07-24 03:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: S.Fourmanoit (syfou) Assigned to: Nobody/Anonymous (nobody) Summary: New module: miniconf Initial Comment: Find enclosed a new data persistence module: miniconf, that basically allows the casual creation and reading of configuration files and similar simple data sets. I ended-up using part of this code in many projects I did in Python (such as adesklets), and many other fellow developers borrowed it from me, so I though it could be nice to have it as a part of the standard library. So I cleaned it up, re-factored it as a simple, standalone module, and here it is, complete with documentation and its test module. Find enclosed a patch against svn trunck (Python 2.5b2, revision 50794). It changes nothing to the tree, besides adding a one-liner to Doc/lib/lib.tex to reference the new documentation. The module also works untouched on Python 2.4.3; I will be glad to provide a patch against any other tree if you want me too; all comments are of course welcomed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 From noreply at sourceforge.net Mon Jul 24 11:29:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 02:29:53 -0700 Subject: [Patches] [ python-Patches-1524639 ] Fix Tkinter Tcl-commands memory-leaks Message-ID: Patches item #1524639, was opened at 2006-07-18 17:00 Message generated for change (Comment added) made by grahamh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Martin v. L??wis (loewis) Summary: Fix Tkinter Tcl-commands memory-leaks Initial Comment: Fix 8 memory-leaks by cleaning up created Tcl commands automatically. I attach a patch against Tkinter 47021. === Long explanation === I was bitten by a memory leak in Tkinter - 25MB per day on a long-running process. A net search found a couple unrelated Tkinter leaks, and gave me some clues. Investigation using the tracing feature in tkleak.py (see link) found the bug. I searched for more similar leaks, and fixed them too. The reasoning for patch #1121234 gives the reason for the changes to _register() and deletecommand(). See http://www.uk.debian.org/~graham/python/tkleak.py for my leak tracing and test script. ---------------------------------------------------------------------- >Comment By: Graham Horler (grahamh) Date: 2006-07-24 10:29 Message: Logged In: YES user_id=543663 > The patch looks wrong. Why are you deleting the > _tkcommands of the master widget if the variable > is deleted? The master could live much longer, > and the commands might still be needed. AIUI, Tkinter callbacks (Button and Scrollbar commands, Text [xy]view, event, protocol and variable bindings, after callbacks etc) should always be given a Python callable, and not the Tcl name of an already bound Python command. Example: b1 = Button(root, command=pressed) b2 = Button(root, command=b1['command']) # Share command b1.destroy() b2.invoke() # Callback is invalid, and rightly so Given that, when a Variable is deleted, is needs to clean up the Tcl commands it created, as no other widget has a reference to them, and they are no longer needed, and there will be no other way of deleting them. By the time __del__() deletes any 'u' callbacks, they have already been called, as globalunsetvar is called first, so this is safe. > What is the purpose of the changes to trace_variable? > You are supposed to invoke trace_vdelete to release the > callback. Is it the aim for Tkinter to work in a similar way to Python's reference counted and garbage collected mem-man? I assume it is, so the changes track commands associated with the variable, for cleanup on collection. See next comment below for explanation of TclError. > Why are you catching TclError in so many cases? Under what > circumstances can you even get an error? The following all raise TclError: w.after("spam", eggs) # bad argument "spam": must be cancel, idle, info, or a number w.bind("", eggs) # bad event type or keysym "spam" w.bind_all("", eggs) # bad event type or keysym "spam" w.bind_class("Button", "", eggs) # bad event type or keysym "spam" w.config(spam=eggs) # unknown option "-spam" v.trace_variable("spam", eggs) # bad operations "spam": should be one or more of rwu When the exception is raised, the 'eggs' Tcl command for the 'spam' callback has already been created. The exception means the "command-id" is never returned for use in cleaning up manually. So, the patch cleans up on exception automatically. I don't think the argument that it's OK for incorrect use to result in memory leaks holds any water :-) I may of course be missing the obvious. > I think I would prefer if this patch was split into many > individual ones, each one fixing only a single > bug (assuming there are multiple bugs in Tkinter). Sorry for the rushed patch, I noticed the release schedule for Python2.5 and just put together the patch from monkey-patch code I had already been using, tested it and uploaded. The tkleak.py program mentioned tests all the fixes, but I did not have time to add them to the Python test suite. I realise you probably have many demands on your time (fielding loads of patches like this one :-), like I do (baby imminent! work demands etc.), so I hope the explanations above help (I should have explained all this before), if not I may be able to submit separate patches and tests at a later date. Many thanks, Graham Horler ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-24 07:15 Message: Logged In: YES user_id=21627 The patch looks wrong. Why are you deleting the _tkcommands of the master widget if the variable is deleted? The master could live much longer, and the commands might still be needed. What is the purpose of the changes to trace_variable? You are supposed to invoke trace_vdelete to release the callback. Why are you catching TclError in so many cases? Under what circumstances can you even get an error? I think I would prefer if this patch was split into many individual ones, each one fixing only a single bug (assuming there are multiple bugs in Tkinter). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2006-07-19 11:33 Message: Logged In: YES user_id=543663 I fixed a bug in the original patch: when destroying a window which had Variable instances attached which in turn had trace commands bound, Tkinter.py was trying to delete the commands twice, as the command was mentioned in Variable instance _tclCommands and _root()._tcl_Commands. Also fixed 4 more leaks occurring when TclError is raised after a callback has been created. I have added 6 tests to tkleak.py to test the additional 4 fixes. The patch is against 50704, hope it helps. Thanks for your hard work, and for accepting my other Tkinter.py patch. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2006-07-18 17:18 Message: Logged In: YES user_id=543663 The python version I am using in production is 2.1 (for historical reasons), however the memory leak bugs are in 2.1 through to 2.5. I can generate a patch against any of the older versions (e.g. 2.4) if anyone is interested. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524639&group_id=5470 From noreply at sourceforge.net Mon Jul 24 12:33:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 03:33:14 -0700 Subject: [Patches] [ python-Patches-1448199 ] ConnectRegistry blocks all threads Message-ID: Patches item #1448199, was opened at 2006-03-12 09:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448199&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars L (larslj) Assigned to: Nobody/Anonymous (nobody) Summary: ConnectRegistry blocks all threads Initial Comment: ConnectRegistry might take quite some time when connecting to a remote machine (especially if it's not responding). It should be possible to run other threads while waiting for this call to return. I notice that some registry calls are enclosed by Py_*_ALLOW_THREADS pairs while some aren't, is there any reason for this? The patch adds Py_*_ALLOW_THREADS around the call to RegConnectRegistry in PC/_winreg.c ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-24 12:33 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r50795. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1448199&group_id=5470 From noreply at sourceforge.net Mon Jul 24 13:55:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 04:55:47 -0700 Subject: [Patches] [ python-Patches-1232023 ] MS Windows - module search path fix Message-ID: Patches item #1232023, was opened at 2005-07-04 07:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232023&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: K. Thananchayan (thanan) Assigned to: Nobody/Anonymous (nobody) Summary: MS Windows - module search path fix Initial Comment: Module search path initialization code for Windows (PC) contains empty component(s) if Python home is determined and registry key "Software/Python/PythonCore//PythonPath" of HKLM or HKCU exists but does not any subkeys as usually the case. This(ese) empyt componentes transformed into current directory later causing to load modules in the current directory in preference to modules in the installation. This patch removes this(ese) empty component(s) from initial module search path. ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-24 13:55 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r50796 (for 2.5) I won't backport this to 2.4.x, as this change in behaviour might break existing installations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1232023&group_id=5470 From noreply at sourceforge.net Mon Jul 24 14:54:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 05:54:08 -0700 Subject: [Patches] [ python-Patches-1527744 ] winsound - probably win9x port is not working Message-ID: Patches item #1527744, was opened at 2006-07-24 21:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527744&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: winsound - probably win9x port is not working Initial Comment: Hello. I found this bug while building trunk with VC6. In current PC/winsound.c, #include #include #ifdef HAVE_CONIO_H #include /* port functions on Win9x */ #endif #include but HAVE_CONIO_H is defined in pyconfig.h, so Python.h should be included before. Otherwise _outp() and _inp() are always unresolved. I hope attached patch will fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527744&group_id=5470 From noreply at sourceforge.net Mon Jul 24 15:02:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 06:02:37 -0700 Subject: [Patches] [ python-Patches-1457736 ] patch for building trunk with VC6 Message-ID: Patches item #1457736, was opened at 2006-03-24 22:40 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for building trunk with VC6 Initial Comment: Hello. I tried to build trunk with VC6, but failed. The reasons are - _W64 is not defined on VC6. (PC/pyconfig.h) - intptr_t and uintptr_t are not decleared on VC6. (should use Py_intptr_t and Py_uintptr_t respectively) I'll submit the patch for these two issues as "build_trunk_for_vc6.patch". And more two issues. - zlib was make built into pythoncore, but PC/VC6/pythoncore.dsp is not updated for it yet. I'll submit the file itself. - long long cannot be used on VC6, so 0xFFFFULL is failed to compile with "invalid suffix" error. I workarounded this replaced ULL with UI64 (_int64's suffix) but I don't know how to make the patch. maybe can this tequnique be used? #define Py_ULL(x) x##ULL /* non VC6 */ #define Py_ULL(x) x##UI64 /* VC6 */ Py_ULL(0xFFFFFFFFFFFFFFFF) instead of 0xFFF...FULL ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-24 22:02 Message: Logged In: YES user_id=1200846 This supports other packages other than _msi. (I skipped this package because I don't know how to test it) test case passed successfully. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 13:33 Message: Logged In: YES user_id=1200846 Thanks to Luke Dunstan, my patch becomes much smaller. - Replace *.dsp in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp - _sqlite3 and other new packages are not supported I read core member are not interested in VC6 anymore, so this is for VC6 guy. I don't want to install VC++2005Express because it installs .net framework which I don't need. I'm Java guy. :-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:40 Message: Logged In: YES user_id=1200846 Oops, I forgot to upload the file. - Apply x.patch. - Replace pythoncore.dsp and pcbuild.dsw in PC/VC6 with attached files. - Remove PC/VC6/zlib.dsp ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-07 14:37 Message: Logged In: YES user_id=1200846 Hello. I updated the patch. (Probably this is better) - defined ULL() macro locally in Modules/sha512module.c maybe it's better to declare Py_ULL or something globally, but I don't know how to do it. - more patch for zlib builtin (ie: PC/VC6/Readme.txt) I cannot try this patch on VC7 or later, but I confirmed lib/test/testall.py passed on VC6. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2006-05-07 03:16 Message: Logged In: YES user_id=30442 Is there anything preventing this patch from being applied? It would help me with building the trunk using both VC6 and Microsoft eMbedded Visual C++ 4.0 (for Windows CE). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 02:02 Message: Logged In: YES user_id=33168 Raymond, maybe this will help get VC6 building? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457736&group_id=5470 From noreply at sourceforge.net Mon Jul 24 15:29:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 06:29:07 -0700 Subject: [Patches] [ python-Patches-1523356 ] (partial?) fix for Misc/python-config.in Message-ID: Patches item #1523356, was opened at 2006-07-16 11:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1523356&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: M. Levinson (levinsm) Assigned to: Georg Brandl (gbrandl) Summary: (partial?) fix for Misc/python-config.in Initial Comment: I've found that the current output from python-config isn't quite right for compiling and linking an application with an embedded interpreter on platforms that need $(SYSLIBS). The attached patch removes extraneous directories from the include path and adds the missing libraries, which was enough to make it work for me in my limited testing. But even with these changes, I haven't quite managed to convince myself that python-config is currently general enough to work on all platforms. Couldn't $(LINKFORSHARED) also be required in some cases, for example? And perhaps there are other missing flags I haven't thought of. I feel it's worth double-checking because python-config strikes me as a potentially convenient tool, but only if its output is known to be correct: If a broken version ever became widely installed in the wild then even if it were to be fixed in some future release, the authors of other applications would forever after need to worry about distinguishing between good and bad versions of python-config before relying on its output, which would undermine its convenience. (Also: if/when it is included in a release, a man page and some mention of it in Doc/ext would be a plus. :-) I hope this is helpful. Thanks for all your great work! ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 13:29 Message: Logged In: YES user_id=849994 Thanks for the patch, applied as rev. 50800. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-24 07:02 Message: Logged In: YES user_id=21627 Georg, can you please take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1523356&group_id=5470 From noreply at sourceforge.net Mon Jul 24 15:39:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 06:39:53 -0700 Subject: [Patches] [ python-Patches-1527597 ] New module: miniconf Message-ID: Patches item #1527597, was opened at 2006-07-24 07:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 3 Submitted By: S.Fourmanoit (syfou) Assigned to: Nobody/Anonymous (nobody) Summary: New module: miniconf Initial Comment: Find enclosed a new data persistence module: miniconf, that basically allows the casual creation and reading of configuration files and similar simple data sets. I ended-up using part of this code in many projects I did in Python (such as adesklets), and many other fellow developers borrowed it from me, so I though it could be nice to have it as a part of the standard library. So I cleaned it up, re-factored it as a simple, standalone module, and here it is, complete with documentation and its test module. Find enclosed a patch against svn trunck (Python 2.5b2, revision 50794). It changes nothing to the tree, besides adding a one-liner to Doc/lib/lib.tex to reference the new documentation. The module also works untouched on Python 2.4.3; I will be glad to provide a patch against any other tree if you want me too; all comments are of course welcomed. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 13:39 Message: Logged In: YES user_id=849994 Have you published this on the Python Cheese Shop? This might be the more appropriate way to make this module known to other Python developers since there's no way to include it in 2.5 any more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 From noreply at sourceforge.net Mon Jul 24 15:46:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 06:46:58 -0700 Subject: [Patches] [ python-Patches-1527744 ] winsound - probably win9x port is not working Message-ID: Patches item #1527744, was opened at 2006-07-24 12:54 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527744&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: winsound - probably win9x port is not working Initial Comment: Hello. I found this bug while building trunk with VC6. In current PC/winsound.c, #include #include #ifdef HAVE_CONIO_H #include /* port functions on Win9x */ #endif #include but HAVE_CONIO_H is defined in pyconfig.h, so Python.h should be included before. Otherwise _outp() and _inp() are always unresolved. I hope attached patch will fix this problem. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 13:46 Message: Logged In: YES user_id=849994 Applied in rev. 50802. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527744&group_id=5470 From noreply at sourceforge.net Mon Jul 24 16:10:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 07:10:05 -0700 Subject: [Patches] [ python-Patches-1515343 ] 1515163 fix - traceback and str exc Message-ID: Patches item #1515343, was opened at 2006-06-30 21:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Jim Jewett (jimjjewett) Assigned to: Anthony Baxter (anthonybaxter) Summary: 1515163 fix - traceback and str exc Initial Comment: 1515163 is a regression from 2.4. It is fairly obscure, as it should only affect deprecated string exceptions which also have a value. raise "string", "string" On the other hand, I did run into it while trying to clean up unittest. The patch fixes this problem, and adds several test cases. -jJ ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 14:10 Message: Logged In: YES user_id=849994 Committed in rev. 50803. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-11 20:27 Message: Logged In: YES user_id=764593 traceback.py.diff3.txt is the minimal fix. traceback.py.diff2.txt is a better fix. test_traceback.py.diff.txt strengthens the test cases (not just this bug; a few others tests as well.) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-03 02:12 Message: Logged In: YES user_id=764593 I forgot to mention in this tracker that this is a regression against 2.4, so it should be fixed even post- beta, unless we decide to never fix it as part of deprecation. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-07-01 11:21 Message: Logged In: YES user_id=764593 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-07-01 11:19 Message: Logged In: NO ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 21:53 Message: Logged In: YES user_id=764593 For misc/news, I suggest something like "Fixed an obscure traceback regression when (deprecated) strings are raised." ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-30 21:52 Message: Logged In: YES user_id=764593 In order to fix it, I also broke out some repeated code into a subfunction, and switched some logic to a more modern idiom -- these parts *could* be separated if need be, but I won't be able to do it this week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1515343&group_id=5470 From noreply at sourceforge.net Mon Jul 24 18:44:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 09:44:01 -0700 Subject: [Patches] [ python-Patches-1527597 ] New module: miniconf Message-ID: Patches item #1527597, was opened at 2006-07-24 03:43 Message generated for change (Comment added) made by syfou You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 3 Submitted By: S.Fourmanoit (syfou) Assigned to: Nobody/Anonymous (nobody) Summary: New module: miniconf Initial Comment: Find enclosed a new data persistence module: miniconf, that basically allows the casual creation and reading of configuration files and similar simple data sets. I ended-up using part of this code in many projects I did in Python (such as adesklets), and many other fellow developers borrowed it from me, so I though it could be nice to have it as a part of the standard library. So I cleaned it up, re-factored it as a simple, standalone module, and here it is, complete with documentation and its test module. Find enclosed a patch against svn trunck (Python 2.5b2, revision 50794). It changes nothing to the tree, besides adding a one-liner to Doc/lib/lib.tex to reference the new documentation. The module also works untouched on Python 2.4.3; I will be glad to provide a patch against any other tree if you want me too; all comments are of course welcomed. ---------------------------------------------------------------------- >Comment By: S.Fourmanoit (syfou) Date: 2006-07-24 12:44 Message: Logged In: YES user_id=1175491 > Have you published this on the Python Cheese Shop? If did not; without being trivial, I felt this was both generic and useful enough to be worth the inclusion into the base library; I managed to miss the feature freeze on python 2.5 -- sorry about that... I don't mind submitting it to the Python Cheese Shop, if it is the right track to have it eventually committed to Python code base; miniconf having virtually no collateral impact on the rest of the code, it is indeed perfectly suitable for distribution as a standalone module for both the 2.4.x and incoming 2.5.x Python interpreters. I don't mind either waiting for the end of the feature freeze, keeping the module up to date as needed against any new code. I am foreign to the development cycle of Python -- do you know what will be the next window of opportunity? Into the incoming 2.5 tree when it will be out of the freeze? Into python 2.6? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 09:39 Message: Logged In: YES user_id=849994 Have you published this on the Python Cheese Shop? This might be the more appropriate way to make this module known to other Python developers since there's no way to include it in 2.5 any more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 From noreply at sourceforge.net Mon Jul 24 21:55:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 12:55:53 -0700 Subject: [Patches] [ python-Patches-1527597 ] New module: miniconf Message-ID: Patches item #1527597, was opened at 2006-07-24 07:43 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 3 Submitted By: S.Fourmanoit (syfou) Assigned to: Nobody/Anonymous (nobody) Summary: New module: miniconf Initial Comment: Find enclosed a new data persistence module: miniconf, that basically allows the casual creation and reading of configuration files and similar simple data sets. I ended-up using part of this code in many projects I did in Python (such as adesklets), and many other fellow developers borrowed it from me, so I though it could be nice to have it as a part of the standard library. So I cleaned it up, re-factored it as a simple, standalone module, and here it is, complete with documentation and its test module. Find enclosed a patch against svn trunck (Python 2.5b2, revision 50794). It changes nothing to the tree, besides adding a one-liner to Doc/lib/lib.tex to reference the new documentation. The module also works untouched on Python 2.4.3; I will be glad to provide a patch against any other tree if you want me too; all comments are of course welcomed. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 19:55 Message: Logged In: YES user_id=849994 You'll at least have to raise this on the python-dev list. It is most probable that you're then asked to let a user base grow by making the module available e.g. via Cheese Shop and report back at a time where 2.6 is nearing. ---------------------------------------------------------------------- Comment By: S.Fourmanoit (syfou) Date: 2006-07-24 16:44 Message: Logged In: YES user_id=1175491 > Have you published this on the Python Cheese Shop? If did not; without being trivial, I felt this was both generic and useful enough to be worth the inclusion into the base library; I managed to miss the feature freeze on python 2.5 -- sorry about that... I don't mind submitting it to the Python Cheese Shop, if it is the right track to have it eventually committed to Python code base; miniconf having virtually no collateral impact on the rest of the code, it is indeed perfectly suitable for distribution as a standalone module for both the 2.4.x and incoming 2.5.x Python interpreters. I don't mind either waiting for the end of the feature freeze, keeping the module up to date as needed against any new code. I am foreign to the development cycle of Python -- do you know what will be the next window of opportunity? Into the incoming 2.5 tree when it will be out of the freeze? Into python 2.6? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 13:39 Message: Logged In: YES user_id=849994 Have you published this on the Python Cheese Shop? This might be the more appropriate way to make this module known to other Python developers since there's no way to include it in 2.5 any more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1527597&group_id=5470 From noreply at sourceforge.net Tue Jul 25 01:28:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 16:28:34 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 13:25 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-07-24 23:28 Message: Logged In: YES user_id=1126061 I've spent quite a few hours today trying to write a patch for this, but alas, this was my first look at autoconf, and it won the battle. Perhaps someone with more autoconf experience could take a look at this? I've attached the output from compiling Python. If anyone needs me to run tests I'm more than happy to. Matt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 18:22 Message: Logged In: YES user_id=33168 Matt, the patch isn't maintainable. For example what happens when NetBSD does support bluetooth, how could both situations be dealt with? It would be much better to verify that the bluetooth header(s) were usable at configure time. If not, the HAVE_BLUETOOTH* macros should not be defined. This would probably take a AC_TRY_COMPILE command in configure.in. Do you think you could try to work on a patch that does that? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-21 16:06 Message: Logged In: YES user_id=1126061 Woa, my bad. That second changeset wasn't supposed to be there. That'll teach me for not scrutinizing my patches more. New version attached. Matt ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-07-21 15:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Tue Jul 25 05:28:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 20:28:34 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 06:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:28 Message: Logged In: YES user_id=33168 Don't worry, autoconf always wins the first battle. You just gotta be more persistant than it. :-) Seriously, autoconf can be a bitch. The real trick is to find out what about bluetooth is broken and build a little C program that should work but doesn't. That will be the key to autoconf. Here's a possible example that could get you going: AC_MSG_CHECKING(for resizeterm) AC_TRY_COMPILE([#include ], void *x=resizeterm, AC_DEFINE(HAVE_CURSES_RESIZETERM, 1, Define if you have the 'resizeterm' function.) AC_MSG_RESULT(yes), AC_MSG_RESULT(no) ) That's taken from the current configure.in. You would need to adjust the names and the code as appropriate. You will probably want to look at the resulting configure. That can help you find the names of vars. For example, if bluetooth is defined or not is something like ac_cv_has_bluetooth_h and ac_cv_has_sys_bluetooth_h. You can find the actual values in configure. Hope that's enough to get you going. If not, feel free to mail me about what you are trying and all the other details and we can try to get this working. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-24 16:28 Message: Logged In: YES user_id=1126061 I've spent quite a few hours today trying to write a patch for this, but alas, this was my first look at autoconf, and it won the battle. Perhaps someone with more autoconf experience could take a look at this? I've attached the output from compiling Python. If anyone needs me to run tests I'm more than happy to. Matt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:22 Message: Logged In: YES user_id=33168 Matt, the patch isn't maintainable. For example what happens when NetBSD does support bluetooth, how could both situations be dealt with? It would be much better to verify that the bluetooth header(s) were usable at configure time. If not, the HAVE_BLUETOOTH* macros should not be defined. This would probably take a AC_TRY_COMPILE command in configure.in. Do you think you could try to work on a patch that does that? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-21 09:06 Message: Logged In: YES user_id=1126061 Woa, my bad. That second changeset wasn't supposed to be there. That'll teach me for not scrutinizing my patches more. New version attached. Matt ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-07-21 08:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Tue Jul 25 05:58:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 20:58:47 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 16:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 18:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Tue Jul 25 07:15:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Jul 2006 22:15:59 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Jul 25 09:20:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 00:20:32 -0700 Subject: [Patches] [ python-Patches-1498370 ] Improve itertools.starmap Message-ID: Patches item #1498370, was opened at 2006-06-01 03:41 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Anthony Baxter (anthonybaxter) Summary: Improve itertools.starmap Initial Comment: As it currently stands, the iterator argument to itertools.starmap() must yield tuples, even those any iterable can be *-expanded in function calls. The attached patch changes starmap()'s behaviour (as well as docs and tests) to allow the provided iterator to return any iterable object. The patch is against r46582. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-25 17:20 Message: Logged In: YES user_id=29957 Hm. Making the code agree with the docs is a good plan. Please make sure to include a very clear NEWS item. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-07-18 13:42 Message: Logged In: YES user_id=591932 Raymond's intuition for bare metal is correct. My suggested simplifaction slowed down the tuple case by most of a percent (I benchmarked it but left it out of the comment). Preternatural, I tell you. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-17 11:00 Message: Logged In: YES user_id=80475 Since starmap() is documented to behave like "yield function(*iterable.next())", I think this fixup can be considered a bugfix. If Anthony is okay with this, it should into Py2.5. While Jack's suggested modification leads to a conceptually simpler patch, I prefer an alternate version that only calls PySequence_Tuple() if PyTuple_CheckExact() fails. That will make sure that we don't slow down the most common case. Also, I prefer slightly different updates to the docs and test suite. If Anthony approves for inclusion in Py2.5, I will upload my own version of a patch to starmap(). ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-27 19:22 Message: Logged In: YES user_id=1344176 I've updated the patch per jackdied's suggestion, plus improved the test suite a bit. The patch is now against r47103. ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-06-10 06:13 Message: Logged In: YES user_id=591932 The patch can be simplified by always calling PySequence_Tuple() and doing the decref instead of special casing tuples. If you pass PySequence_Tuple() a tuple it will incref it and hand it back to you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-06-01 11:36 Message: Logged In: YES user_id=671362 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1498370&group_id=5470 From noreply at sourceforge.net Tue Jul 25 10:23:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 01:23:14 -0700 Subject: [Patches] [ python-Patches-1397711 ] Fix dict and set docs, re: immutability Message-ID: Patches item #1397711, was opened at 2006-01-05 23:28 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Raymond Hettinger (rhettinger) Summary: Fix dict and set docs, re: immutability Initial Comment: This patch resolves bug #1368768. As mentioned in the bug description, the documentation for sets and dicts incorrectly reports that set members and dict keys must be immutable. This patch corrects this, changing references to immutability to hashability and inserting footnotes describing what is meant by "hashable". The patch is a diff against Doc/lib/libstdtypes.tex from SVN revision 41926. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-25 18:23 Message: Logged In: YES user_id=29957 Raymond, this is assigned to you - were you going to check it in? If not, I will do it. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-01-21 00:07 Message: Logged In: YES user_id=1344176 I've updated the patch to include Jim's version of the footnote. The new version of the patch is against SVN revision 42105. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-01-14 09:09 Message: Logged In: YES user_id=764593 Definately an improvement, but it still may not be quite right in the footnote. You don't have to define a __hash__ method; you just need to avoid redefining it (or __eq__) to something that doesn't work. Here is another stab Hashable objects must define or inherit proper \method{__hash__} and \method{__eq__} methods. Most objects do, but some mutable types -- including lists -- redefine equality in such a way that the hash code would not be stable. Instead, their hash functions return -1 to indicate that the object should not be used as a dict key or set member. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1397711&group_id=5470 From noreply at sourceforge.net Tue Jul 25 10:24:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 01:24:18 -0700 Subject: [Patches] [ python-Patches-1513299 ] Clean up usage of map() in the stdlib Message-ID: Patches item #1513299, was opened at 2006-06-27 22:15 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Clean up usage of map() in the stdlib Initial Comment: This patch cleans up the usage of map() in the standard library. Among other things, it removes several usages of things like map(None, x), as well as simplifying a number of map(lambda: ..., x) expressions. This patch is against r47124. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-07-25 18:24 Message: Logged In: YES user_id=29957 map(None, ...) should definitely be expunged. The others should be addressed on a case-by-case basis. I'll have a read-through of the patch. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-28 02:53 Message: Logged In: YES user_id=1344176 Updated the patch to r47131 and added a bunch of new cleanups. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-28 01:46 Message: Logged In: YES user_id=764593 There are none I would suggest reverting; it is just that some are clear wins and others are not so important. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-06-28 01:24 Message: Logged In: YES user_id=1344176 Which ones would you like to see reverted (ie, which ones are not an improvement)? I've found some more cases that can be improved, so a new version of the patch will be on the way shortly. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-28 01:15 Message: Logged In: YES user_id=764593 Some cases are definately an improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1513299&group_id=5470 From noreply at sourceforge.net Tue Jul 25 11:53:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 02:53:56 -0700 Subject: [Patches] [ python-Patches-1525817 ] calltip awkwardly shortened Message-ID: Patches item #1525817, was opened at 2006-07-20 13:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525817&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: Martin v. L??wis (loewis) Summary: calltip awkwardly shortened Initial Comment: Because of the fact, that calltips are truncated, if the overall length exceeds some value (75), the second line is shortened too much, if the parameterlist (i. e. first line) is relatively long. Example: for the function: def setup(self, width=0.5, height=0.75, startx=None, starty=None): """ Set the size and position of the main window. ... The second line only displays Set the size and positio... although even unshortended it would be shorter than the first line. This seems counterproductive. I submit a patch, which lets both lines be at most as long as they would be with the former code. (Of course one could think of different solutions.) ---------------------------------------------------------------------- >Comment By: Martin v. L??wis (loewis) Date: 2006-07-25 11:53 Message: Logged In: YES user_id=21627 Thanks for the report. I fixed it slightly differently in 50815; the original intent was to truncate long lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525817&group_id=5470 From noreply at sourceforge.net Tue Jul 25 12:23:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 03:23:01 -0700 Subject: [Patches] [ python-Patches-1525766 ] pkgutil.walk_packages ignores onerror arg Message-ID: Patches item #1525766, was opened at 2006-07-20 08:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525766&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: pkgutil.walk_packages ignores onerror arg Initial Comment: pkgutil.walk_packages doesn't properly pass the onerror argument to recursive calls. Also, the docstrings are quite lacking. Finally, it doesn't pass the name of the thing it was trying to import to the onerror handler, making using the handler for error reporting a bit difficult. This patch fixes all three of those. If the change to the onerror handler signature is controversial, I can make another patch without that at least the clearly bugfix part of this can go in py2.5. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-25 10:23 Message: Logged In: YES user_id=849994 Committed as rev. 50819. As the walk_packages function isn't documented yet, I think the argument change is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1525766&group_id=5470 From noreply at sourceforge.net Tue Jul 25 15:42:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 06:42:29 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 21:03 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 16:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 15:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 07:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Tue Jul 25 18:07:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 09:07:02 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 19:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Tue Jul 25 18:07:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 09:07:48 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 19:07 Message generated for change (Settings changed) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Tue Jul 25 18:17:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 09:17:42 -0700 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Open Resolution: Accepted Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for mbcs codecs Initial Comment: Hello. I have noticed mbcs codecs sometimes generates broken string. I'm using Windows(Japanese) so mbcs is mapped to cp932 (close to shift_jis) When I run the attached script "a.zip", the entry "Error 00007"'s message becomes broken like attached file "b.txt". I think this happens because the string passed to PyUnicode_DecodeMBCS() sometimes terminates with leading byte, and MultiByteToWideChar() counts it for size of result string.buffer size. I hope attached patch "mbcs.patch" may fix the problem. It would be nice if this bug will be fixed in 2.4.3... Thank you. ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-26 01:17 Message: Logged In: YES user_id=1200846 Sorry, I reopened this issue because I found problem. With attached "mbcs.py" and "mbcs.txt", result file "hoge.txt" gets corrupted. This happens because Codec.decode is called incrementally, while default value for final in mbcs_decode() is True. >I think the default value for final in mbcs_decode() should >be true, so that the stateless decoder detects incomplete >byte sequences too. Probably this is not true. I think "stateless" means codec doesn't have internal state for incremental usage, doesn't mean it is not called incrementally. # I hope attached "fix.patch" fixes the problem. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-06-14 14:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46945. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-27 06:40 Message: Logged In: YES user_id=1200846 I reverted PyUnicode_Resize() patch for now, and recreated the patch as "mbcs.patch". >You should probably find someone on python-dev with a >multibyte version of Windows to look at the patch. OK, I will. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-27 06:18 Message: Logged In: YES user_id=1200846 >The change to PyUnicode_Resize() should be reverted (or done >in a way that doesn't lead to bugs). Sorry, how about this? Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 46417) +++ Objects/unicodeobject.c (working copy) @@ -326,7 +326,7 @@ return -1; } v = (PyUnicodeObject *)*unicode; - if (v == NULL || !PyUnicode_Check(v) || v->ob_refcnt != 1 || length < 0) { + if (v == NULL || !PyUnicode_Check(v) || length < 0) { PyErr_BadInternalCall(); return -1; } @@ -335,7 +335,7 @@ possible since these are being shared. We simply return a fresh copy with the same Unicode content. */ if (v->length != length && - (v == unicode_empty || v->length == 1)) { + (v == unicode_empty || v->length == 1 || v->ob_refcnt != 1)) { PyUnicodeObject *w = _PyUnicode_New(length); if (w == NULL) return -1; ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2006-05-27 00:43 Message: Logged In: YES user_id=89016 The change to PyUnicode_Resize() should be reverted (or done in a way that doesn't lead to bugs). Unfortunately I don't have a Windows where I can test the patch, so I'm unassigning the bug. You should probably find someone on python-dev with a multibyte version of Windows to look at the patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 20:06 Message: Logged In: YES user_id=1200846 >PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, >but probably I'll fix it too. Done. Attached as "mbcs_win64_support.patch". Now, total summary... - MBCS decoder and encoder now supports 64bit Py_ssize_t environment. (I don't have such machine, but I checked routine by defining NEED_RETRY and redefining INT_MAX as 2, 3, 4) - Fixed a bug of MBCS incremental decoder which was originaly reported by me. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 05:18 Message: Logged In: YES user_id=1200846 I updated the patch. - PyUnicode_DecodeMBCS now supports size >= INT_MAX. (I don't have machine to test such big string, but I have tested this routine replaced INT_MAX with 2 and 3) PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, but probably I'll fix it too. This patch includes Patch#1494487. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-02 20:40 Message: Logged In: YES user_id=1200846 I updated the patch. (I copy and pasted "int final = 0" from above code (ex: utf_16_ex_decode), maybe they also should be changed for consistency?) And one more thing, I noticed "errors" is ignored now. We can detect invalid character if we set MB_ERR_INVALID_CHARS flag when calling MultiByteToWideChar, but we cannot tell where is the position of invalid character, and MSDN saids this flag is available Win2000SP4 or later (I don't know why) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp So I didn't make the patch for it. ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2006-04-26 02:22 Message: Logged In: YES user_id=89016 I think the default value for final in mbcs_decode() should be true, so that the stateless decoder detects incomplete byte sequences too. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-04-07 18:10 Message: Logged In: YES user_id=1200846 I have sent contributor form via postal mail. Probably you can get it after 10 days. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 17:16 Message: Logged In: YES user_id=1200846 You are right. I've updated the patch. (mbcs5.patch) >>> import codecs [20198 refs] >>> d = codecs.getincrementaldecoder("mbcs")() [20198 refs] >>> d.decode('\x82\xa0\x82') u'\u3042' [20198 refs] >>> d.decode('') u'' [20198 refs] >>> d.decode('', final=True) u'\x00' [20198 refs] ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2006-03-28 01:06 Message: Logged In: YES user_id=89016 _buffer_decode() in the IncrementalDecoder ignores the final argument. IncrementalDecoder._buffer_decode() should pass on its final argument to _codecsmodules.c::mbcs_decode(), which should be extended to accept the final argument. Also PyUnicode_DecodeMBCSStateful() must handle consumed == NULL correctly (with your patch it drops trailing lead bytes even if consumed == NULL) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 16:41 Message: Logged In: YES user_id=1200846 I replaced tests. Probably this is better instead of comparing the two string generated by same decoder. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 14:44 Message: Logged In: YES user_id=1200846 My real name is Hirokazu Yamamoto. But sorry, I don't have FAX. (It's needed to send contributor form, isn't it?) I'll attach the patch updated for trunk. And I'll attach the tests. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-03-27 06:05 Message: Logged In: YES user_id=21627 I have reservations against this patch because of the quasi-anonymous nature of the submission. ocean-city, can you please state your real name? Would you also be willing to fill out a contributor form, as shown on http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-24 23:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D??rwald (doerwalter) Date: 2006-03-24 06:44 Message: Logged In: YES user_id=89016 This isn't a bugfix in the strictest sense, so IMHO this patch shouldn't go into 2.4. If the patch goes into 2.5, it would need the appropriate changes to encodings/mbcs.py (i.e. the IncrementalDecoder would have to be changed (inheriting from BufferedIncrementalDecoder). I realize that this patch might be hard to test, as results are dependent on locale. Nevertheless at least some tests would be good (even if they are only run or do something useful on a certain locale and are skipped otherwise). ocean-city, can you update the patch for the trunk and add tests? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-23 11:51 Message: Logged In: YES user_id=1200846 Hello. This is my final patch. (mbcs4.patch) - mbcs3a.patch: _mbsbtype depends on locale not system ANSI code page. so probably it's not good to use it with MultiByteToWideChar. - mbcs3b.patch: CharNext may cause buffer overflow. and this patch always calls CharPrev but it's not needed if string is not terminated with "potensial" lead byte. I hope this is stable enough to commit on repositry. Thank you. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 23:36 Message: Logged In: YES user_id=1200846 Sorry, I was stupid. MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp) saids, > IsDBCSLeadByte can only indicate a potential lead byte value. IsDBCSLeadByte was returning 1 for some trail byte (ex: "???"[1]) The patch "mbcs3a.patch" worked for me, but _mbsbtype is probably compiler specific. Is that OK? The patch "mbcs3b.patch" also worked for me and it only uses Win32API, but I don't have enough faith on this implementation... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 19:31 Message: Logged In: YES user_id=1200846 Sorry, I found problem when tried more long text file... Please wait. I'll investigate more intensibly. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 19:13 Message: Logged In: YES user_id=1200846 Thank you for reply. How about this? (I'm a newbie, I hope this is right tex format but... can you confirm this? I created this patch by copy & paste from PyUnicode_DecodeUTF16Stateful and some modification) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 18:12 Message: Logged In: YES user_id=38388 One more nit: the doc patch is missing. Please add a patch for the API docs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 18:11 Message: Logged In: YES user_id=38388 As I understand your comment, the mbcs codec will have a problem if the input string terminates with a lead byte. Could you add a comment regarding this to the patch ?! I can't test the patch, since I don't have a Japanese Windows to check on, but from looking at the patch, it seems OK. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 16:42 Message: Logged In: YES user_id=1200846 I forgot to mention this. "mbcs.patch" is for release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Jul 26 19:31:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 10:31:28 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 21:03 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-26 20:31 Message: Logged In: YES user_id=1330769 I agree that IDLE must have a no-subprocess mode, since it has its uses. Still, I feel these uses are relatively isoteric, so while the option should exist as a command line option, it shouldn't usually be used by non-developers. On systems without networking trying to use sockets will fail, and IDLE should detect this and fall-back to no-subprocess mode automatically. (Another item on the TODO list...) Well, we could "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as you say, erratic. Also, if a collision happens the listening socket won't recieve a connection, and accept() will timeout. After this we can continue trying other ports. I submitted my implementation as a separate patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-25 22:40 Message: Logged In: YES user_id=149084 There are a couple of reasons: some systems don't have networking installed, and running w/o the subprocess causes the debugger to work slightly differently: it is possible to debug IDLE itself. It is surprising that it was possible to run IDLE in either mode w/o mucking up the code too badly. But there is one major problem: on Windows, it's possible to start more than one listener on a port. I haven't been able to track this down, it's somewhat erratic. Given the problems on Windows with stuck subprocesses, I'm loath to go to multiple instances of IDLE w/o fixing the multiple listener problem with its collisions. I certainly agree with you that it would be very desireable not to use the -n switch in the "edit with IDLE" binding. And I also agree about the efficacy of the subprocess, that's why we went to all the effort on IDLEfork. https://sourceforge.net/tracker/ index.php?func=detail&aid=661363&group_id=9579&atid=309579 Maybe we can get this fixed in 2.6. It's way too risky to attempt it in 2.5 and it's a new feature. Could you add your patch so I can look at it? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 16:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 15:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 07:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Tue Jul 25 20:08:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 11:08:06 -0700 Subject: [Patches] [ python-Patches-1517042 ] Fix for Lib/test/crashers/gc_inspection.py Message-ID: Patches item #1517042, was opened at 2006-07-04 16:39 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 2 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for Lib/test/crashers/gc_inspection.py Initial Comment: The attached patch fixes the bug pointed out in crashers/gc_inspection.py, namely that gc.get_referrers() can be used to see objects (in this case tuples) before their built, leading to segfaults. The patch works by modifying Objects/abstract.c:PySequence_AsTuple, wrapping the call to PyIter_Next() with _PyObject_GC_TRACK/UNTRACK calls. This has the effect of hiding the being-created tuple from gc.get_referrers() while fetching the next item from the iterator. Also attached is a patch to crashers/gc_inspection.py itself, which allows the test to actually pass (the previous version would raise IndexErrors in the event the test passed). ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-07-25 18:08 Message: Logged In: YES user_id=4771 This patch is pointless. I recommend rejecting it. The crashers/gc_inspection.py was just one example among many of crashing Python with gc.get_referrers(). I don't see why we should care to fix just this specific way. What would be needed is a complete review, possibly with an API change to decouple object creation and GC registration, and appropriate documentation for extension module writers. I don't think it's likely to happen though. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-06 06:28 Message: Logged In: YES user_id=33168 Note that the declaration of item needs to be moved to the top of the scope so it can compile with C89. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-07-05 22:31 Message: Logged In: YES user_id=80475 Crashers based on gc.get_referrers() should not be considered real bugs. It is certainly not worth complexifying the code or slowing it down just to preclude these little perverse safe-cracking exercises. Also, it is not worth the risk of introducing a real bug when the code was working fine. That being said, if the code is genuinely defective and has potential to cause real-world problems, then it should be fixed. I would think that if there were a long- standing problem with tuples, it would have manifested itself long ago. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2006-07-05 17:36 Message: Logged In: YES user_id=1344176 The improve_gc_inspection.patch file has been superseded by a patch attached to bug #1517663. The bug details another interpreter crash in the same vein as the one fix in tuple() by this patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1517042&group_id=5470 From noreply at sourceforge.net Thu Jul 27 05:05:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 20:05:00 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 14:03 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:05 Message: Logged In: YES user_id=149084 On Windows 2000, at least, when a collision occurs there is a significant (30%?) chance that the late arrival will get a listening connection. Then both sets of processes merrily communicate on the same socket, apparently w/o mutual corruption. At least that's the way it seemed to me last time I looked. I can't put much faith in a situation like that. However, your patch 1529142, though a hack, may be practical, at least for now. 2.6. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-26 13:31 Message: Logged In: YES user_id=1330769 I agree that IDLE must have a no-subprocess mode, since it has its uses. Still, I feel these uses are relatively isoteric, so while the option should exist as a command line option, it shouldn't usually be used by non-developers. On systems without networking trying to use sockets will fail, and IDLE should detect this and fall-back to no-subprocess mode automatically. (Another item on the TODO list...) Well, we could "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as you say, erratic. Also, if a collision happens the listening socket won't recieve a connection, and accept() will timeout. After this we can continue trying other ports. I submitted my implementation as a separate patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-25 15:40 Message: Logged In: YES user_id=149084 There are a couple of reasons: some systems don't have networking installed, and running w/o the subprocess causes the debugger to work slightly differently: it is possible to debug IDLE itself. It is surprising that it was possible to run IDLE in either mode w/o mucking up the code too badly. But there is one major problem: on Windows, it's possible to start more than one listener on a port. I haven't been able to track this down, it's somewhat erratic. Given the problems on Windows with stuck subprocesses, I'm loath to go to multiple instances of IDLE w/o fixing the multiple listener problem with its collisions. I certainly agree with you that it would be very desireable not to use the -n switch in the "edit with IDLE" binding. And I also agree about the efficacy of the subprocess, that's why we went to all the effort on IDLEfork. https://sourceforge.net/tracker/ index.php?func=detail&aid=661363&group_id=9579&atid=309579 Maybe we can get this fixed in 2.6. It's way too risky to attempt it in 2.5 and it's a new feature. Could you add your patch so I can look at it? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 09:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 08:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 00:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Wed Jul 26 21:50:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 12:50:28 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Tue Jul 25 20:46:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Jul 2006 11:46:48 -0700 Subject: [Patches] [ python-Patches-1455898 ] patch for mbcs codecs Message-ID: Patches item #1455898, was opened at 2006-03-22 16:31 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: Accepted Priority: 7 Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: patch for mbcs codecs Initial Comment: Hello. I have noticed mbcs codecs sometimes generates broken string. I'm using Windows(Japanese) so mbcs is mapped to cp932 (close to shift_jis) When I run the attached script "a.zip", the entry "Error 00007"'s message becomes broken like attached file "b.txt". I think this happens because the string passed to PyUnicode_DecodeMBCS() sometimes terminates with leading byte, and MultiByteToWideChar() counts it for size of result string.buffer size. I hope attached patch "mbcs.patch" may fix the problem. It would be nice if this bug will be fixed in 2.4.3... Thank you. ---------------------------------------------------------------------- >Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-26 03:46 Message: Logged In: YES user_id=1200846 >>I think the default value for final in mbcs_decode() should >>be true, so that the stateless decoder detects incomplete >>byte sequences too. > >Probably this is not true. Sorry, I lied. Stateless decoder was exactly the thing you said. >>> import codecs >>> d = codecs.getdecoder("cp932") >>> d('\x82') Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'cp932' codec can't decode byte 0x82 in position 0: incomplete multibyte sequence Problem was on StreamReader. StreamReader should treat "final" as false, but I didn't change this code, class StreamReader(Codec,codecs.StreamReader): pass so StreamReader wrongly treated "final" as True. I cloned routine from Lib/encoding/utf-8.py. I hope finally this meets requirement of codec system... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-07-26 01:17 Message: Logged In: YES user_id=1200846 Sorry, I reopened this issue because I found problem. With attached "mbcs.py" and "mbcs.txt", result file "hoge.txt" gets corrupted. This happens because Codec.decode is called incrementally, while default value for final in mbcs_decode() is True. >I think the default value for final in mbcs_decode() should >be true, so that the stateless decoder detects incomplete >byte sequences too. Probably this is not true. I think "stateless" means codec doesn't have internal state for incremental usage, doesn't mean it is not called incrementally. # I hope attached "fix.patch" fixes the problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-14 14:21 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as r46945. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-27 06:40 Message: Logged In: YES user_id=1200846 I reverted PyUnicode_Resize() patch for now, and recreated the patch as "mbcs.patch". >You should probably find someone on python-dev with a >multibyte version of Windows to look at the patch. OK, I will. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-27 06:18 Message: Logged In: YES user_id=1200846 >The change to PyUnicode_Resize() should be reverted (or done >in a way that doesn't lead to bugs). Sorry, how about this? Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 46417) +++ Objects/unicodeobject.c (working copy) @@ -326,7 +326,7 @@ return -1; } v = (PyUnicodeObject *)*unicode; - if (v == NULL || !PyUnicode_Check(v) || v->ob_refcnt != 1 || length < 0) { + if (v == NULL || !PyUnicode_Check(v) || length < 0) { PyErr_BadInternalCall(); return -1; } @@ -335,7 +335,7 @@ possible since these are being shared. We simply return a fresh copy with the same Unicode content. */ if (v->length != length && - (v == unicode_empty || v->length == 1)) { + (v == unicode_empty || v->length == 1 || v->ob_refcnt != 1)) { PyUnicodeObject *w = _PyUnicode_New(length); if (w == NULL) return -1; ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-05-27 00:43 Message: Logged In: YES user_id=89016 The change to PyUnicode_Resize() should be reverted (or done in a way that doesn't lead to bugs). Unfortunately I don't have a Windows where I can test the patch, so I'm unassigning the bug. You should probably find someone on python-dev with a multibyte version of Windows to look at the patch. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 20:06 Message: Logged In: YES user_id=1200846 >PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, >but probably I'll fix it too. Done. Attached as "mbcs_win64_support.patch". Now, total summary... - MBCS decoder and encoder now supports 64bit Py_ssize_t environment. (I don't have such machine, but I checked routine by defining NEED_RETRY and redefining INT_MAX as 2, 3, 4) - Fixed a bug of MBCS incremental decoder which was originaly reported by me. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-25 05:18 Message: Logged In: YES user_id=1200846 I updated the patch. - PyUnicode_DecodeMBCS now supports size >= INT_MAX. (I don't have machine to test such big string, but I have tested this routine replaced INT_MAX with 2 and 3) PyUnicode_DecodeMBCS does not support size >= INT_MAX yet, but probably I'll fix it too. This patch includes Patch#1494487. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-05-02 20:40 Message: Logged In: YES user_id=1200846 I updated the patch. (I copy and pasted "int final = 0" from above code (ex: utf_16_ex_decode), maybe they also should be changed for consistency?) And one more thing, I noticed "errors" is ignored now. We can detect invalid character if we set MB_ERR_INVALID_CHARS flag when calling MultiByteToWideChar, but we cannot tell where is the position of invalid character, and MSDN saids this flag is available Win2000SP4 or later (I don't know why) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_17si.asp So I didn't make the patch for it. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-04-26 02:22 Message: Logged In: YES user_id=89016 I think the default value for final in mbcs_decode() should be true, so that the stateless decoder detects incomplete byte sequences too. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-04-07 18:10 Message: Logged In: YES user_id=1200846 I have sent contributor form via postal mail. Probably you can get it after 10 days. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-28 17:16 Message: Logged In: YES user_id=1200846 You are right. I've updated the patch. (mbcs5.patch) >>> import codecs [20198 refs] >>> d = codecs.getincrementaldecoder("mbcs")() [20198 refs] >>> d.decode('\x82\xa0\x82') u'\u3042' [20198 refs] >>> d.decode('') u'' [20198 refs] >>> d.decode('', final=True) u'\x00' [20198 refs] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-28 01:06 Message: Logged In: YES user_id=89016 _buffer_decode() in the IncrementalDecoder ignores the final argument. IncrementalDecoder._buffer_decode() should pass on its final argument to _codecsmodules.c::mbcs_decode(), which should be extended to accept the final argument. Also PyUnicode_DecodeMBCSStateful() must handle consumed == NULL correctly (with your patch it drops trailing lead bytes even if consumed == NULL) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 16:41 Message: Logged In: YES user_id=1200846 I replaced tests. Probably this is better instead of comparing the two string generated by same decoder. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-27 14:44 Message: Logged In: YES user_id=1200846 My real name is Hirokazu Yamamoto. But sorry, I don't have FAX. (It's needed to send contributor form, isn't it?) I'll attach the patch updated for trunk. And I'll attach the tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-27 06:05 Message: Logged In: YES user_id=21627 I have reservations against this patch because of the quasi-anonymous nature of the submission. ocean-city, can you please state your real name? Would you also be willing to fill out a contributor form, as shown on http://www.python.org/psf/contrib-form.html ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-24 23:02 Message: Logged In: YES user_id=1200846 OK, I'll try. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-24 06:44 Message: Logged In: YES user_id=89016 This isn't a bugfix in the strictest sense, so IMHO this patch shouldn't go into 2.4. If the patch goes into 2.5, it would need the appropriate changes to encodings/mbcs.py (i.e. the IncrementalDecoder would have to be changed (inheriting from BufferedIncrementalDecoder). I realize that this patch might be hard to test, as results are dependent on locale. Nevertheless at least some tests would be good (even if they are only run or do something useful on a certain locale and are skipped otherwise). ocean-city, can you update the patch for the trunk and add tests? ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-23 11:51 Message: Logged In: YES user_id=1200846 Hello. This is my final patch. (mbcs4.patch) - mbcs3a.patch: _mbsbtype depends on locale not system ANSI code page. so probably it's not good to use it with MultiByteToWideChar. - mbcs3b.patch: CharNext may cause buffer overflow. and this patch always calls CharPrev but it's not needed if string is not terminated with "potensial" lead byte. I hope this is stable enough to commit on repositry. Thank you. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 23:36 Message: Logged In: YES user_id=1200846 Sorry, I was stupid. MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_0o2t.asp) saids, > IsDBCSLeadByte can only indicate a potential lead byte value. IsDBCSLeadByte was returning 1 for some trail byte (ex: "?"[1]) The patch "mbcs3a.patch" worked for me, but _mbsbtype is probably compiler specific. Is that OK? The patch "mbcs3b.patch" also worked for me and it only uses Win32API, but I don't have enough faith on this implementation... ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 19:31 Message: Logged In: YES user_id=1200846 Sorry, I found problem when tried more long text file... Please wait. I'll investigate more intensibly. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 19:13 Message: Logged In: YES user_id=1200846 Thank you for reply. How about this? (I'm a newbie, I hope this is right tex format but... can you confirm this? I created this patch by copy & paste from PyUnicode_DecodeUTF16Stateful and some modification) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 18:12 Message: Logged In: YES user_id=38388 One more nit: the doc patch is missing. Please add a patch for the API docs. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-03-22 18:11 Message: Logged In: YES user_id=38388 As I understand your comment, the mbcs codec will have a problem if the input string terminates with a lead byte. Could you add a comment regarding this to the patch ?! I can't test the patch, since I don't have a Japanese Windows to check on, but from looking at the patch, it seems OK. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-03-22 16:42 Message: Logged In: YES user_id=1200846 I forgot to mention this. "mbcs.patch" is for release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1455898&group_id=5470 From noreply at sourceforge.net Wed Jul 26 19:45:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 10:45:08 -0700 Subject: [Patches] [ python-Patches-1529142 ] Allowing multiple instances of IDLE with sub-processes Message-ID: Patches item #1529142, was opened at 2006-07-26 20:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Allowing multiple instances of IDLE with sub-processes Initial Comment: (See patch 1201569 "allow running multiple instances of IDLE" for previous discussion on this topic) To summarize discussion up to this point: There is a problem doing this on Windows since more than one listening socket can be openned on a single port. I suggest we "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch 661363) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as Kurt mentioned, erratic. This patch chooses a port from range(49152, 65536), which are the 'dynamic' ports as described by the DCCP (see http://www.iana.org/assignments/port-numbers), and avoids known 'dangerous' ports (used by trojans, worms, etc.) which I gathered by Googling for half an hour. I replaced socket.timeout with select(), since I find its timeout mechanism is more reliable. (Currently, Python's socket's timeout mechanism raises unexpected, unexplained errors on Windows.) I also changed the flow a bit, so if a timeout occurs after a sub-process is spawned, the subprocess is killed. IMO This requires thorough testing. I tested it for half an hour on my WinXP Python2.4.3, and after fixing typos and such, everything seems to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529142&group_id=5470 From noreply at sourceforge.net Thu Jul 27 09:36:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 00:36:42 -0700 Subject: [Patches] [ python-Patches-1529514 ] More openbsd targets for ctypes Message-ID: Patches item #1529514, was opened at 2006-07-27 09:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: More openbsd targets for ctypes Initial Comment: This patch was sent in by Damien Miller in private email. It allows to build ctypes on more OpenBSD platforms. The attached diff contains a patch for Modules/_ctypes/libffi/configure.ac, of course Modules/_ctypes/libffi/configure would be regenerated as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529514&group_id=5470 From noreply at sourceforge.net Thu Jul 27 02:13:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 17:13:56 -0700 Subject: [Patches] [ python-Patches-1529353 ] Squeezer - squeeze large output in the interpreter Message-ID: Patches item #1529353, was opened at 2006-07-27 03:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Squeezer - squeeze large output in the interpreter Initial Comment: Here is my improved version of Squeezer - the IDLE extension to end all of your oh-no-I-just-printed-War-and-Peace-in-the-interpreter troubles! Changes: * Fixed line counting logic * Line counting is done according to current window width and current tab width * Fixed configHandler to enable reading of raw data from config files (100% backwards compatible) - needed by Squeezer to enable configuration of text viewers in config-extensions I've been working this vesion without a hitch for several weeks, but that's hardly enough testing is it? Attached: * the original Squeezer.py by Noam Raphael * a diff against Noam's original Squeezer.py * a diff of configHandler.py against the current SVN version (revision 46863) * fixed 'middle click to copy' - now works on Windows One minor note - the 'middle click to copy' didn't work on Windows because it simply called selection_own() which doesn't affect the clipboard. I added clipboard_clear() and clipboard_append() and it now works on Windows. This should be tested on Linux, Unix, OSX etc. to check compatibility. For more info on the clipboard issue, see: http://groups.google.com/group/comp.lang.python/browse_thread/thread/647feeef55625733/bc08421d8aea9928?lnk=st&q=&rnum=2#bc08421d8aea9928 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 From noreply at sourceforge.net Thu Jul 27 05:17:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 20:17:58 -0700 Subject: [Patches] [ python-Patches-1519796 ] Fix for #1513611 and #1511497; xml.sax imports Message-ID: Patches item #1519796, was opened at 2006-07-10 03:32 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for #1513611 and #1511497; xml.sax imports Initial Comment: Package xmlcore.sax currently uses a mix of realtive and absolute imports. This caused the following bugs: http://python.org/sf/1513611 http://python.org/sf/1511497 This patch fixes it, by using relative imports. I tried using absolute imports, but then some of the tests in the attached test_xml_importing module fail. The tests are separate because I don't know how to include setUp() and tearDown() methods into non unittest based tests. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-26 23:17 Message: Logged In: YES user_id=3066 These tests do not trigger any failures for me with the current trunk, so I'm not sure what the patch is fixing. I'm attaching a patch that includes tests cases for both of the issues reportedly fixed by this patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-10 17:03 Message: Logged In: YES user_id=21627 Assigning to Fred Drake, who introduced xmlcore. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-10 03:59 Message: Logged In: YES user_id=1326842 Attaching a new patch and updated tests, since I missed that make_parser() uses __import__(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 From noreply at sourceforge.net Thu Jul 27 15:31:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 06:31:28 -0700 Subject: [Patches] [ python-Patches-1529686 ] test_defaultdict not integrated into test sute Message-ID: Patches item #1529686, was opened at 2006-07-27 15:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: test_defaultdict not integrated into test sute Initial Comment: test_defaultdict is missing a test_main() function, which means that regrtest ignores its testcases. You can see this if you run: python regrtest.py -v test_defaultdict ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 From noreply at sourceforge.net Wed Jul 26 16:13:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 07:13:47 -0700 Subject: [Patches] [ python-Patches-1529018 ] Move firewall warning to "about" menu Message-ID: Patches item #1529018, was opened at 2006-07-26 17:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529018&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Move firewall warning to "about" menu Initial Comment: This patch addresses the point brought up in the following post on IDLE-dev by Gregor Lingl. I support this change and nobody raised an objection. " The firewall warning message in the Pythonshell window was introduced in Python 2.3 (IDLE 1.0 or something similar?) I remember well the problems, which have been occurred then, and to which it was the answer. (If I remember correctly I was involved in the discussion thread which led to the introduction of that message.) Since more than three years I've used IDLE on many different systems and I didn't encounter a single Firewall warning since then. (It seems that firewalls nowadays are not offended by the use of 127.0.0.1) Therefore, and because the message is long and ugly, I'd like to suggest to delete it from the Python Shell window and - if considered necessary - for instance to put it into the IDLE Help - "About IDLE" submenu or in a special IDLE-Firewall warning submenu of IDLE-Help. Please observe that it pops up thousands of times and it's read at most once. Additional remark (about my personal interest): I have to do a lot of IDLE-screenshots for a textbook on programming and I really don't like it to occur on all those screenshots. " ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529018&group_id=5470 From noreply at sourceforge.net Thu Jul 27 17:06:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 08:06:06 -0700 Subject: [Patches] [ python-Patches-1529686 ] test_defaultdict not integrated into test sute Message-ID: Patches item #1529686, was opened at 2006-07-27 13:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: test_defaultdict not integrated into test sute Initial Comment: test_defaultdict is missing a test_main() function, which means that regrtest ignores its testcases. You can see this if you run: python regrtest.py -v test_defaultdict ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-27 15:06 Message: Logged In: YES user_id=849994 Fixed this one (and two others) in rev. 50861. Thanks for spotting! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 From noreply at sourceforge.net Thu Jul 27 18:22:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 09:22:09 -0700 Subject: [Patches] [ python-Patches-1529811 ] misleading info about tarfile.py's "r|*" mode Message-ID: Patches item #1529811, was opened at 2006-07-27 18:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: Nobody/Anonymous (nobody) Summary: misleading info about tarfile.py's "r|*" mode Initial Comment: In the "New, Improved and Removed Modules" section of "What's new in Python 2.5", it is said to be new that a tarfile's compression can be autodetected using mode "r|*". This is not quite right. New about the "r|*" mode is that it can autodetect compression of a tarfile opened in *stream mode* which was not possible before. Attached is a patch against whatsnew25.tex in current SVN HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529811&group_id=5470 From noreply at sourceforge.net Wed Jul 26 22:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 13:30:48 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 12:07 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open >Resolution: Later Priority: 3 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 16:30 Message: Logged In: YES user_id=149084 Well, once you get it throughly tested, please attach the patch so I can look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Thu Jul 27 04:49:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 19:49:46 -0700 Subject: [Patches] [ python-Patches-1529353 ] Squeezer - squeeze large output in the interpreter Message-ID: Patches item #1529353, was opened at 2006-07-26 20:13 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Squeezer - squeeze large output in the interpreter Initial Comment: Here is my improved version of Squeezer - the IDLE extension to end all of your oh-no-I-just-printed-War-and-Peace-in-the-interpreter troubles! Changes: * Fixed line counting logic * Line counting is done according to current window width and current tab width * Fixed configHandler to enable reading of raw data from config files (100% backwards compatible) - needed by Squeezer to enable configuration of text viewers in config-extensions I've been working this vesion without a hitch for several weeks, but that's hardly enough testing is it? Attached: * the original Squeezer.py by Noam Raphael * a diff against Noam's original Squeezer.py * a diff of configHandler.py against the current SVN version (revision 46863) * fixed 'middle click to copy' - now works on Windows One minor note - the 'middle click to copy' didn't work on Windows because it simply called selection_own() which doesn't affect the clipboard. I added clipboard_clear() and clipboard_append() and it now works on Windows. This should be tested on Linux, Unix, OSX etc. to check compatibility. For more info on the clipboard issue, see: http://groups.google.com/group/comp.lang.python/browse_thread/thread/647feeef55625733/bc08421d8aea9928?lnk=st&q=&rnum=2#bc08421d8aea9928 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 22:49 Message: Logged In: YES user_id=149084 OK, thanks. Please take a look at the two diffs you uploaded, they seem corrupted. Squeezer.py looks ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 From noreply at sourceforge.net Thu Jul 27 02:15:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 17:15:14 -0700 Subject: [Patches] [ python-Patches-1529353 ] Squeezer - squeeze large output in the interpreter Message-ID: Patches item #1529353, was opened at 2006-07-27 03:13 Message generated for change (Settings changed) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Squeezer - squeeze large output in the interpreter Initial Comment: Here is my improved version of Squeezer - the IDLE extension to end all of your oh-no-I-just-printed-War-and-Peace-in-the-interpreter troubles! Changes: * Fixed line counting logic * Line counting is done according to current window width and current tab width * Fixed configHandler to enable reading of raw data from config files (100% backwards compatible) - needed by Squeezer to enable configuration of text viewers in config-extensions I've been working this vesion without a hitch for several weeks, but that's hardly enough testing is it? Attached: * the original Squeezer.py by Noam Raphael * a diff against Noam's original Squeezer.py * a diff of configHandler.py against the current SVN version (revision 46863) * fixed 'middle click to copy' - now works on Windows One minor note - the 'middle click to copy' didn't work on Windows because it simply called selection_own() which doesn't affect the clipboard. I added clipboard_clear() and clipboard_append() and it now works on Windows. This should be tested on Linux, Unix, OSX etc. to check compatibility. For more info on the clipboard issue, see: http://groups.google.com/group/comp.lang.python/browse_thread/thread/647feeef55625733/bc08421d8aea9928?lnk=st&q=&rnum=2#bc08421d8aea9928 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 From noreply at sourceforge.net Thu Jul 27 22:48:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 13:48:34 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 19:07 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2006-07-27 23:48 Message: Logged In: YES user_id=1330769 Bah, sorry for forgetting to post the file... It really was getting late that night :P ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:30 Message: Logged In: YES user_id=149084 Well, once you get it throughly tested, please attach the patch so I can look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Fri Jul 28 01:51:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 16:51:25 -0700 Subject: [Patches] [ python-Patches-1520294 ] Support for PyGetSetDefs in pydoc, inspect, and types Message-ID: Patches item #1520294, was opened at 2006-07-10 21:45 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Support for PyGetSetDefs in pydoc, inspect, and types Initial Comment: Attributes defined in extension modules via PyGetSetDef aren't instances of property and aren't really handled correctly in the above three modules. This patch adds a types.GetSetterType an inspect.isgetsetter() function, and support for getsetters in pydoc, along with test cases and doc changes. This patch should go into Python 2.5 and part of it should get backported to Python 2.4. Specifically the support for PyGetSetDef in pydoc should be backported, but it should be done in such a way as to not add isgetsetter() or GetSetterType (fairly easy to do as module globals in pydoc.py). Mostly I'm looking for another set of eyes to proof my changes. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-27 19:51 Message: Logged In: YES user_id=12800 r50881 for *nix r50885 for Windows ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-20 15:28 Message: Logged In: YES user_id=12800 I've posted this to python-dev: http://mail.python.org/pipermail/python-dev/2006-July/067590.html Hope it helps. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-19 23:18 Message: Logged In: YES user_id=33168 I know that Anthony has been busy. I'm -0 on the patch moreso because of the added _types.c. It's not the code that I have a problem with, but the direction we are going. At various points, we've talked about doing away with types.py. This makes that a bit messier. it's a little like the idea of adding __module_name__ at the last minute. Once this is in, it's next to impossible to remove if incorrect. Also, I'm a little concerned about how this affects other impls (PyPy, IronPython, Jython). Would you mind posting more of the impl details on py-dev and see if anyone still has an opinion? I don't recall any support pro or con. I suspect most don't really care and few people have read the patch. If you mention the impl details, I don't know if that would change anything. What is the impact of waiting? These features have been in since 2.2, right? Also, unlike Tim's threading changes, these can be exposed with a third party extension module can't they? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-19 08:21 Message: Logged In: YES user_id=12800 Thanks for the comments. - I've changed it to GetSetDescriptorType - 'data descriptor' is just what Python itself prints for the type(getset_descriptor) so that's what I chose, but the test should still be with isgetsetdescriptor(). Although it's inconsistent with type(), I changed inspect.py's text to read 'getset descriptor' since I think that's more accurate. - I've changed false to \code{False} in the docs, but libinspect.text uses "true" all over the place. I am not changing that. :) - updated the test and tried to make it pass in other implementations. Since no one else has really commented either for or against, and the RM hasn't pronounced, I'm going to take silence as approval and commit these changes later today. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-17 09:17 Message: Logged In: YES user_id=849994 Looks fine, I noticed a few things: - perhaps GetSet should be named GetSetDescriptor for consistency with DataDescriptor and MemberDescriptor - in pydoc, shouldn't "data descriptor" be tested with "inspectisdatadescriptor"? - in the docs, false should be False - test_twelve should now be called test_thirteen ;) and the comment in it should be adapted - is the test suite expected to pass in implementations without the newly tested descriptor types? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-13 12:05 Message: Logged In: YES user_id=12800 Here's an updated patch with several improvements. First, the name is now GetSetType and isgetset(). Also, I've added support for member descriptors with MemberDescriptorType and ismemberdescriptor(). I've also added pydoc help for member descriptors. The appropriate things are done for implementations other than CPython that don't have such extension types. This patch includes the usual docs and tests updates. The other improvement is that rather than relying on accidents of implementation in the C Python interpreter, I've added a built-in _types module which implements specifically the types that are needed. This seems like the best way to ensure that we have accurate types without tying down future development of obscure other modules. This may make it more difficult to backport to Python 2.4, but that's a different concern. Better to DTRT for Python 2.5 first. Assigning back to Georg for another quick review, but feel free to assign it back to me for final checkin (assuming Anthony okays it). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-11 03:04 Message: Logged In: YES user_id=849994 Why not GetSet? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-07-10 23:07 Message: Logged In: YES user_id=12800 Yeah, I went back and forth on that a few times. GetSetter was a poor compromise between GetSet and GetterSetter :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 22:57 Message: Logged In: YES user_id=33168 I haven't looked at the patch, but the name seems a little funny to me due to the lack of parallel names. GetterSetter makes more sense or the current GetSet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520294&group_id=5470 From noreply at sourceforge.net Fri Jul 28 02:50:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 17:50:31 -0700 Subject: [Patches] [ python-Patches-1529686 ] test_defaultdict not integrated into test sute Message-ID: Patches item #1529686, was opened at 2006-07-27 15:31 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: test_defaultdict not integrated into test sute Initial Comment: test_defaultdict is missing a test_main() function, which means that regrtest ignores its testcases. You can see this if you run: python regrtest.py -v test_defaultdict ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-07-28 02:50 Message: Logged In: YES user_id=1326842 Could you please port the test_iterlen part of your patch to the 2.4 branch? I just noticed that this test is not new. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-27 17:06 Message: Logged In: YES user_id=849994 Fixed this one (and two others) in rev. 50861. Thanks for spotting! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 From noreply at sourceforge.net Fri Jul 28 03:16:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 18:16:30 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 06:25 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 18:16 Message: Logged In: YES user_id=33168 Yup, this looks good now. Don't forget to add a note to Misc/NEWS in the Extension Modules section. If you aren't already in Misc/ACKS, add yourself. :-) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-26 03:39 Message: Logged In: YES user_id=1126061 Attaching patch. Turns out NetBSD does support all the bluetooth stuff in Python. All bluetooth 'addresses' use a single struct 'sockaddr_bt'. Matt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:28 Message: Logged In: YES user_id=33168 Don't worry, autoconf always wins the first battle. You just gotta be more persistant than it. :-) Seriously, autoconf can be a bitch. The real trick is to find out what about bluetooth is broken and build a little C program that should work but doesn't. That will be the key to autoconf. Here's a possible example that could get you going: AC_MSG_CHECKING(for resizeterm) AC_TRY_COMPILE([#include ], void *x=resizeterm, AC_DEFINE(HAVE_CURSES_RESIZETERM, 1, Define if you have the 'resizeterm' function.) AC_MSG_RESULT(yes), AC_MSG_RESULT(no) ) That's taken from the current configure.in. You would need to adjust the names and the code as appropriate. You will probably want to look at the resulting configure. That can help you find the names of vars. For example, if bluetooth is defined or not is something like ac_cv_has_bluetooth_h and ac_cv_has_sys_bluetooth_h. You can find the actual values in configure. Hope that's enough to get you going. If not, feel free to mail me about what you are trying and all the other details and we can try to get this working. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-24 16:28 Message: Logged In: YES user_id=1126061 I've spent quite a few hours today trying to write a patch for this, but alas, this was my first look at autoconf, and it won the battle. Perhaps someone with more autoconf experience could take a look at this? I've attached the output from compiling Python. If anyone needs me to run tests I'm more than happy to. Matt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:22 Message: Logged In: YES user_id=33168 Matt, the patch isn't maintainable. For example what happens when NetBSD does support bluetooth, how could both situations be dealt with? It would be much better to verify that the bluetooth header(s) were usable at configure time. If not, the HAVE_BLUETOOTH* macros should not be defined. This would probably take a AC_TRY_COMPILE command in configure.in. Do you think you could try to work on a patch that does that? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-21 09:06 Message: Logged In: YES user_id=1126061 Woa, my bad. That second changeset wasn't supposed to be there. That'll teach me for not scrutinizing my patches more. New version attached. Matt ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-07-21 08:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Thu Jul 27 06:46:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Jul 2006 21:46:47 -0700 Subject: [Patches] [ python-Patches-1475523 ] patch fixing #1448060 (gettext.py bug) Message-ID: Patches item #1475523, was opened at 2006-04-24 06:09 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Thenault Sylvain (syt) Assigned to: Martin v. L?wis (loewis) Summary: patch fixing #1448060 (gettext.py bug) Initial Comment: Here is a patch for the bug described in https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448060&group_id=5470 It follows the latest Martin followup as I understand it. I'm not sure if multi-lines field handling should be totally discarded while reading metadata headers (as implemented), or if it should only be discarded for the content-type and plural-forms header. If one think this patch isn't correct, please comment so I can fix it. Notice that if the second solution was intended, lines such as "#-#-#-#-# fr.po #-#-#-#-#\n" inserted by msgcat/msgmerge will have to be treated differently (i.e. multi-lines support but skip lines begining with a #). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-17 00:45 Message: Logged In: YES user_id=21627 The patch is wrong; it breaks the existing test case WeirdMetadataTest. I think the "just a single line" rule should be restricted to Plural-Forms; not sure whether it should apply to content-type also (but why not). I'll attach another patch that adds a test case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1475523&group_id=5470 From noreply at sourceforge.net Fri Jul 28 06:33:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 21:33:50 -0700 Subject: [Patches] [ python-Patches-1529811 ] misleading info about tarfile.py's "r|*" mode Message-ID: Patches item #1529811, was opened at 2006-07-27 09:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Lars Gust?bel (gustaebel) >Assigned to: A.M. Kuchling (akuchling) Summary: misleading info about tarfile.py's "r|*" mode Initial Comment: In the "New, Improved and Removed Modules" section of "What's new in Python 2.5", it is said to be new that a tarfile's compression can be autodetected using mode "r|*". This is not quite right. New about the "r|*" mode is that it can autodetect compression of a tarfile opened in *stream mode* which was not possible before. Attached is a patch against whatsnew25.tex in current SVN HEAD. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 21:33 Message: Logged In: YES user_id=33168 Andrew, I suppose you'll want to take a look at this and update the whatsnew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529811&group_id=5470 From noreply at sourceforge.net Fri Jul 28 06:51:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 21:51:02 -0700 Subject: [Patches] [ python-Patches-1529514 ] More openbsd targets for ctypes Message-ID: Patches item #1529514, was opened at 2006-07-27 00:36 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: More openbsd targets for ctypes Initial Comment: This patch was sent in by Damien Miller in private email. It allows to build ctypes on more OpenBSD platforms. The attached diff contains a patch for Modules/_ctypes/libffi/configure.ac, of course Modules/_ctypes/libffi/configure would be regenerated as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529514&group_id=5470 From noreply at sourceforge.net Thu Jul 27 14:48:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Jul 2006 05:48:38 -0700 Subject: [Patches] [ python-Patches-1519796 ] Fix for #1513611 and #1511497; xml.sax imports Message-ID: Patches item #1519796, was opened at 2006-07-10 09:32 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Fix for #1513611 and #1511497; xml.sax imports Initial Comment: Package xmlcore.sax currently uses a mix of realtive and absolute imports. This caused the following bugs: http://python.org/sf/1513611 http://python.org/sf/1511497 This patch fixes it, by using relative imports. I tried using absolute imports, but then some of the tests in the attached test_xml_importing module fail. The tests are separate because I don't know how to include setUp() and tearDown() methods into non unittest based tests. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-07-27 14:48 Message: Logged In: YES user_id=1326842 The patch is extremely fragile and works only if you don't mix objects from xml and xmlcore. As your test shows, it breaks if you import 'make_parser' and 'SAXParseException' from different packages. As for the tests, the first four fail for me if I run them as a script. They are not integrated into the test suite since they are missing a test_main() function. It seems that renaming xmlcore back to xml is the simplest solution, so I'll just close this patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-27 05:17 Message: Logged In: YES user_id=3066 These tests do not trigger any failures for me with the current trunk, so I'm not sure what the patch is fixing. I'm attaching a patch that includes tests cases for both of the issues reportedly fixed by this patch. ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2006-07-10 23:03 Message: Logged In: YES user_id=21627 Assigning to Fred Drake, who introduced xmlcore. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-10 09:59 Message: Logged In: YES user_id=1326842 Attaching a new patch and updated tests, since I missed that make_parser() uses __import__(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519796&group_id=5470 From noreply at sourceforge.net Fri Jul 28 13:44:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 04:44:15 -0700 Subject: [Patches] [ python-Patches-1526460 ] Fix socketmodule compile on NetBSD Message-ID: Patches item #1526460, was opened at 2006-07-21 13:25 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Fix socketmodule compile on NetBSD Initial Comment: socketmodule tries to include bluetooth support is bluetooth.h or bluetooth/bluetooth.h is found. However NetBSD's bluetooth API (which is only available in the -current development branch) is incompatible with, afaik, any other. This patch is taken from pkgsrc. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-07-28 11:44 Message: Logged In: YES user_id=1126061 Committed revision 50899. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 01:16 Message: Logged In: YES user_id=33168 Yup, this looks good now. Don't forget to add a note to Misc/NEWS in the Extension Modules section. If you aren't already in Misc/ACKS, add yourself. :-) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-26 10:39 Message: Logged In: YES user_id=1126061 Attaching patch. Turns out NetBSD does support all the bluetooth stuff in Python. All bluetooth 'addresses' use a single struct 'sockaddr_bt'. Matt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 03:28 Message: Logged In: YES user_id=33168 Don't worry, autoconf always wins the first battle. You just gotta be more persistant than it. :-) Seriously, autoconf can be a bitch. The real trick is to find out what about bluetooth is broken and build a little C program that should work but doesn't. That will be the key to autoconf. Here's a possible example that could get you going: AC_MSG_CHECKING(for resizeterm) AC_TRY_COMPILE([#include ], void *x=resizeterm, AC_DEFINE(HAVE_CURSES_RESIZETERM, 1, Define if you have the 'resizeterm' function.) AC_MSG_RESULT(yes), AC_MSG_RESULT(no) ) That's taken from the current configure.in. You would need to adjust the names and the code as appropriate. You will probably want to look at the resulting configure. That can help you find the names of vars. For example, if bluetooth is defined or not is something like ac_cv_has_bluetooth_h and ac_cv_has_sys_bluetooth_h. You can find the actual values in configure. Hope that's enough to get you going. If not, feel free to mail me about what you are trying and all the other details and we can try to get this working. ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-24 23:28 Message: Logged In: YES user_id=1126061 I've spent quite a few hours today trying to write a patch for this, but alas, this was my first look at autoconf, and it won the battle. Perhaps someone with more autoconf experience could take a look at this? I've attached the output from compiling Python. If anyone needs me to run tests I'm more than happy to. Matt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 18:22 Message: Logged In: YES user_id=33168 Matt, the patch isn't maintainable. For example what happens when NetBSD does support bluetooth, how could both situations be dealt with? It would be much better to verify that the bluetooth header(s) were usable at configure time. If not, the HAVE_BLUETOOTH* macros should not be defined. This would probably take a AC_TRY_COMPILE command in configure.in. Do you think you could try to work on a patch that does that? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-07-21 16:06 Message: Logged In: YES user_id=1126061 Woa, my bad. That second changeset wasn't supposed to be there. That'll teach me for not scrutinizing my patches more. New version attached. Matt ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2006-07-21 15:43 Message: Logged In: YES user_id=55188 The patch breaks the build on FreeBSD. What does the second changeset in the patch do? I think that it isn't necessary if you want to just disable it in NetBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1526460&group_id=5470 From noreply at sourceforge.net Fri Jul 28 14:07:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 05:07:26 -0700 Subject: [Patches] [ python-Patches-1529811 ] misleading info about tarfile.py's "r|*" mode Message-ID: Patches item #1529811, was opened at 2006-07-27 12:22 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Lars Gust?bel (gustaebel) Assigned to: A.M. Kuchling (akuchling) Summary: misleading info about tarfile.py's "r|*" mode Initial Comment: In the "New, Improved and Removed Modules" section of "What's new in Python 2.5", it is said to be new that a tarfile's compression can be autodetected using mode "r|*". This is not quite right. New about the "r|*" mode is that it can autodetect compression of a tarfile opened in *stream mode* which was not possible before. Attached is a patch against whatsnew25.tex in current SVN HEAD. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-28 08:07 Message: Logged In: YES user_id=11375 Applied; thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 00:33 Message: Logged In: YES user_id=33168 Andrew, I suppose you'll want to take a look at this and update the whatsnew. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529811&group_id=5470 From noreply at sourceforge.net Fri Jul 28 17:52:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 08:52:12 -0700 Subject: [Patches] [ python-Patches-1530482 ] pydoc render_doc Message-ID: Patches item #1530482, was opened at 2006-07-28 18:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc render_doc Initial Comment: a patch for improving pydoc's inner working. instead of doc() doing both the text rendering and sending it to the pager, introduce a new function, render_doc(), that renders the text. doc() now calls render_doc() and sends the text to the pager. this allows external programs to generate a "text only" version of the documentation, without having to read it from stdout. reference: http://mail.python.org/pipermail/python-dev/2006-July/067776.html the patch is against revision 50881: http://svn.python.org/view/python/trunk/Lib/pydoc.py?rev=50881&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_id=5470 From noreply at sourceforge.net Fri Jul 28 17:54:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 08:54:31 -0700 Subject: [Patches] [ python-Patches-1530482 ] pydoc render_doc Message-ID: Patches item #1530482, was opened at 2006-07-28 18:52 Message generated for change (Settings changed) made by gangesmaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: pydoc render_doc Initial Comment: a patch for improving pydoc's inner working. instead of doc() doing both the text rendering and sending it to the pager, introduce a new function, render_doc(), that renders the text. doc() now calls render_doc() and sends the text to the pager. this allows external programs to generate a "text only" version of the documentation, without having to read it from stdout. reference: http://mail.python.org/pipermail/python-dev/2006-July/067776.html the patch is against revision 50881: http://svn.python.org/view/python/trunk/Lib/pydoc.py?rev=50881&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_id=5470 From noreply at sourceforge.net Fri Jul 28 18:35:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 09:35:53 -0700 Subject: [Patches] [ python-Patches-1529686 ] test_email_codecs not integrated into test sute Message-ID: Patches item #1529686, was opened at 2006-07-27 15:31 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) >Summary: test_email_codecs not integrated into test sute Initial Comment: test_defaultdict is missing a test_main() function, which means that regrtest ignores its testcases. You can see this if you run: python regrtest.py -v test_defaultdict ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-07-28 18:35 Message: Logged In: YES user_id=1326842 'test_email_encodings' is another test that is not integrated into the test suite. The patch for the 2.4 branch includes 'test_email_codecs' as well as 'test_iterlen' fixes. The patch for the trunk includes 'test_email_codecs' fixes and also adds tests from the 'test_email_codecs_renamed' to the standard test suite. P.S. Yay! The 'File Upload' checkbox is gone! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-28 02:50 Message: Logged In: YES user_id=1326842 Could you please port the test_iterlen part of your patch to the 2.4 branch? I just noticed that this test is not new. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-27 17:06 Message: Logged In: YES user_id=849994 Fixed this one (and two others) in rev. 50861. Thanks for spotting! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 From noreply at sourceforge.net Fri Jul 28 20:31:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 11:31:40 -0700 Subject: [Patches] [ python-Patches-1529686 ] test_email_codecs not integrated into test sute Message-ID: Patches item #1529686, was opened at 2006-07-27 13:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: test_email_codecs not integrated into test sute Initial Comment: test_defaultdict is missing a test_main() function, which means that regrtest ignores its testcases. You can see this if you run: python regrtest.py -v test_defaultdict ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 18:31 Message: Logged In: YES user_id=849994 Thanks for the patches! I had grepped through the tests, but somehow missed email_codecs. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-28 16:35 Message: Logged In: YES user_id=1326842 'test_email_encodings' is another test that is not integrated into the test suite. The patch for the 2.4 branch includes 'test_email_codecs' as well as 'test_iterlen' fixes. The patch for the trunk includes 'test_email_codecs' fixes and also adds tests from the 'test_email_codecs_renamed' to the standard test suite. P.S. Yay! The 'File Upload' checkbox is gone! ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-28 00:50 Message: Logged In: YES user_id=1326842 Could you please port the test_iterlen part of your patch to the 2.4 branch? I just noticed that this test is not new. Thanks. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-27 15:06 Message: Logged In: YES user_id=849994 Fixed this one (and two others) in rev. 50861. Thanks for spotting! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529686&group_id=5470 From noreply at sourceforge.net Fri Jul 28 21:44:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 12:44:32 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 14:03 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-28 15:44 Message: Logged In: YES user_id=149084 I don't mean to be derogatory by calling it a hack! Hacks can be very practical and useful, but they are often not 100% reliable. I'm only referring to the port selection part of the patch. Regarding REUSEADDR, if it is not set True there is a timeout before the listening connection can be set up again on the same socket. As I recollect, it's ten sec, and so very annoying when restarting IDLE especially during development. Guido clued me in on REUSEADDR, which solved the problem. According to the below links, it's only operative when the socket is in the TIME_WAIT state, and that should not be the case in the W2K overlapping socket situation. http://www.unixguide.net/network/socketfaq/4.5.shtml http://www.unixguide.net/network/socketfaq/2.7.shtml IDLE discussion should be on IDLE-dev unless it's something which affects the Python implementation or changes the installation, i.e. how .py is bound on Windows. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-27 02:54 Message: Logged In: YES user_id=1330769 My patch is not so much a hack, it's actually a more optimal implementation, with or without the Windows issue. It just also happens to make port collision very rare ;) Aren't coincidences wonderful? Anyways, I remember seeing something about "reuse address" when binding sockets... ah, here it is. Check out SocketServer.py: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) And this comment in BaseHTTPServer.py: allow_reuse_address = 1 # Seems to make sense in testing environment Could socket.SO_REUSEADDR be the cause? What does it default to? Maybe its implementation on Windows is broken? (Probably not, but still worth checking.) Maybe we should get the discussion up and running again in Python-Dev or c.l.p... ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:05 Message: Logged In: YES user_id=149084 On Windows 2000, at least, when a collision occurs there is a significant (30%?) chance that the late arrival will get a listening connection. Then both sets of processes merrily communicate on the same socket, apparently w/o mutual corruption. At least that's the way it seemed to me last time I looked. I can't put much faith in a situation like that. However, your patch 1529142, though a hack, may be practical, at least for now. 2.6. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-26 13:31 Message: Logged In: YES user_id=1330769 I agree that IDLE must have a no-subprocess mode, since it has its uses. Still, I feel these uses are relatively isoteric, so while the option should exist as a command line option, it shouldn't usually be used by non-developers. On systems without networking trying to use sockets will fail, and IDLE should detect this and fall-back to no-subprocess mode automatically. (Another item on the TODO list...) Well, we could "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as you say, erratic. Also, if a collision happens the listening socket won't recieve a connection, and accept() will timeout. After this we can continue trying other ports. I submitted my implementation as a separate patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-25 15:40 Message: Logged In: YES user_id=149084 There are a couple of reasons: some systems don't have networking installed, and running w/o the subprocess causes the debugger to work slightly differently: it is possible to debug IDLE itself. It is surprising that it was possible to run IDLE in either mode w/o mucking up the code too badly. But there is one major problem: on Windows, it's possible to start more than one listener on a port. I haven't been able to track this down, it's somewhat erratic. Given the problems on Windows with stuck subprocesses, I'm loath to go to multiple instances of IDLE w/o fixing the multiple listener problem with its collisions. I certainly agree with you that it would be very desireable not to use the -n switch in the "edit with IDLE" binding. And I also agree about the efficacy of the subprocess, that's why we went to all the effort on IDLEfork. https://sourceforge.net/tracker/ index.php?func=detail&aid=661363&group_id=9579&atid=309579 Maybe we can get this fixed in 2.6. It's way too risky to attempt it in 2.5 and it's a new feature. Could you add your patch so I can look at it? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 09:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 08:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 00:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Fri Jul 28 21:48:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 12:48:15 -0700 Subject: [Patches] [ python-Patches-1201569 ] allow running multiple instances of IDLE Message-ID: Patches item #1201569, was opened at 2005-05-13 14:03 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Jeff Shute (jshute) Assigned to: Kurt B. Kaiser (kbk) Summary: allow running multiple instances of IDLE Initial Comment: This patch will allow running multiple instances of IDLE in the default (mutli-process) mode by choosing the first available port from 8833-8893 instead of failing when another IDLE has already bound port 8833. (Not tested on windows.) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-28 15:48 Message: Logged In: YES user_id=149084 Timeout might have been a whole minute. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-28 15:44 Message: Logged In: YES user_id=149084 I don't mean to be derogatory by calling it a hack! Hacks can be very practical and useful, but they are often not 100% reliable. I'm only referring to the port selection part of the patch. Regarding REUSEADDR, if it is not set True there is a timeout before the listening connection can be set up again on the same socket. As I recollect, it's ten sec, and so very annoying when restarting IDLE especially during development. Guido clued me in on REUSEADDR, which solved the problem. According to the below links, it's only operative when the socket is in the TIME_WAIT state, and that should not be the case in the W2K overlapping socket situation. http://www.unixguide.net/network/socketfaq/4.5.shtml http://www.unixguide.net/network/socketfaq/2.7.shtml IDLE discussion should be on IDLE-dev unless it's something which affects the Python implementation or changes the installation, i.e. how .py is bound on Windows. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-27 02:54 Message: Logged In: YES user_id=1330769 My patch is not so much a hack, it's actually a more optimal implementation, with or without the Windows issue. It just also happens to make port collision very rare ;) Aren't coincidences wonderful? Anyways, I remember seeing something about "reuse address" when binding sockets... ah, here it is. Check out SocketServer.py: if self.allow_reuse_address: self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.socket.bind(self.server_address) And this comment in BaseHTTPServer.py: allow_reuse_address = 1 # Seems to make sense in testing environment Could socket.SO_REUSEADDR be the cause? What does it default to? Maybe its implementation on Windows is broken? (Probably not, but still worth checking.) Maybe we should get the discussion up and running again in Python-Dev or c.l.p... ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:05 Message: Logged In: YES user_id=149084 On Windows 2000, at least, when a collision occurs there is a significant (30%?) chance that the late arrival will get a listening connection. Then both sets of processes merrily communicate on the same socket, apparently w/o mutual corruption. At least that's the way it seemed to me last time I looked. I can't put much faith in a situation like that. However, your patch 1529142, though a hack, may be practical, at least for now. 2.6. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-26 13:31 Message: Logged In: YES user_id=1330769 I agree that IDLE must have a no-subprocess mode, since it has its uses. Still, I feel these uses are relatively isoteric, so while the option should exist as a command line option, it shouldn't usually be used by non-developers. On systems without networking trying to use sockets will fail, and IDLE should detect this and fall-back to no-subprocess mode automatically. (Another item on the TODO list...) Well, we could "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as you say, erratic. Also, if a collision happens the listening socket won't recieve a connection, and accept() will timeout. After this we can continue trying other ports. I submitted my implementation as a separate patch. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-25 15:40 Message: Logged In: YES user_id=149084 There are a couple of reasons: some systems don't have networking installed, and running w/o the subprocess causes the debugger to work slightly differently: it is possible to debug IDLE itself. It is surprising that it was possible to run IDLE in either mode w/o mucking up the code too badly. But there is one major problem: on Windows, it's possible to start more than one listener on a port. I haven't been able to track this down, it's somewhat erratic. Given the problems on Windows with stuck subprocesses, I'm loath to go to multiple instances of IDLE w/o fixing the multiple listener problem with its collisions. I certainly agree with you that it would be very desireable not to use the -n switch in the "edit with IDLE" binding. And I also agree about the efficacy of the subprocess, that's why we went to all the effort on IDLEfork. https://sourceforge.net/tracker/ index.php?func=detail&aid=661363&group_id=9579&atid=309579 Maybe we can get this fixed in 2.6. It's way too risky to attempt it in 2.5 and it's a new feature. Could you add your patch so I can look at it? ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-25 09:42 Message: Logged In: YES user_id=1330769 First of all, there is (theoretically) no reason to un IDLE -without- a subprocess. The subprocess is an awesome feature and I feel that it should be the (good, usable, reliable) default. IDLE's "Run Module" option is very handy but its behavior depends on whether or not there is a subprocess. If there is a subprocess it restarts the interpreter every time, which is good! If there is no subprocess it runs the module the first time, and later does nothing (because of Python's import-once mechanism). On windows the Python installer adds "Edit with IDLE" to Explorer's right-click context menu, which is VERY convenient. But this shortcut start IDLE with the -n precisely because of this subprocess issue. So if I want to be able to use Run Module and have the interpreter restart, I have to manually open the file for editting. Yes, it's something I can live with, but it's a serious turn-off for new users. I often teach Python using IDLE. Having IDLE sometimes run with a subprocess and sometimes without confuses new users, so I end up having to explain the subprocess issue very early, and they still get bitten by it a few times. And they also have to manually open files instead of using the "Edit with IDLE" shortcut. Allowing multiple instances, each with a subprocess listening on a different port, seems like the cleanest solution. Whatever socket issues there are, let's get them cleared up! P.S. I've been using this patch for some time, it works pretty well but not 100%. ---------------------------------------------------------------------- Comment By: Jeff Shute (jshute) Date: 2005-05-18 08:52 Message: Logged In: YES user_id=39615 My use case is just that I find it annoying that in the default mode, you can't run multiple instances, and I kept seeing the annoying dialog box and having to restart. I normally use -n mode partly because of this, but sometimes I forget. It seemed like a trivial fix. Regarding the note, I didn't understand the comment because it doesn't say why. I thought maybe it was done that way so that it could be made to fail so the error messages could be tested. It seemed like you avoid the sleep() and several race conditions by starting the listener first. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-05-18 00:37 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork 661363 Will not be considered until remaining problems with socket binding on Windows have been resolved. Note: You can start as many copies of IDLE as you want with the -n switch. What is your use case? Also note: # spawning first avoids passing a listening socket to the subprocess ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1201569&group_id=5470 From noreply at sourceforge.net Fri Jul 28 21:48:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 12:48:52 -0700 Subject: [Patches] [ python-Patches-1529142 ] Allowing multiple instances of IDLE with sub-processes Message-ID: Patches item #1529142, was opened at 2006-07-26 13:45 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529142&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tal Einat (taleinat) >Assigned to: Kurt B. Kaiser (kbk) Summary: Allowing multiple instances of IDLE with sub-processes Initial Comment: (See patch 1201569 "allow running multiple instances of IDLE" for previous discussion on this topic) To summarize discussion up to this point: There is a problem doing this on Windows since more than one listening socket can be openned on a single port. I suggest we "dodge" the Windows problem for now by having IDLE try a random port every time (like in the IDLEfork patch 661363) - thus collisions will be kept to a minimum. If we choose among over 10,000 ports, most users will never encounter a port collision. And even when a collision does happen, it will probably be detected and properly dealt with - collision non-detection errors are, as Kurt mentioned, erratic. This patch chooses a port from range(49152, 65536), which are the 'dynamic' ports as described by the DCCP (see http://www.iana.org/assignments/port-numbers), and avoids known 'dangerous' ports (used by trojans, worms, etc.) which I gathered by Googling for half an hour. I replaced socket.timeout with select(), since I find its timeout mechanism is more reliable. (Currently, Python's socket's timeout mechanism raises unexpected, unexplained errors on Windows.) I also changed the flow a bit, so if a timeout occurs after a sub-process is spawned, the subprocess is killed. IMO This requires thorough testing. I tested it for half an hour on my WinXP Python2.4.3, and after fixing typos and such, everything seems to work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529142&group_id=5470 From noreply at sourceforge.net Fri Jul 28 23:45:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 14:45:05 -0700 Subject: [Patches] [ python-Patches-1529514 ] More openbsd targets for ctypes Message-ID: Patches item #1529514, was opened at 2006-07-27 09:36 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529514&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: More openbsd targets for ctypes Initial Comment: This patch was sent in by Damien Miller in private email. It allows to build ctypes on more OpenBSD platforms. The attached diff contains a patch for Modules/_ctypes/libffi/configure.ac, of course Modules/_ctypes/libffi/configure would be regenerated as well. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-07-28 23:45 Message: Logged In: YES user_id=11105 Committed as r50918. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529514&group_id=5470 From noreply at sourceforge.net Sat Jul 29 05:46:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 20:46:00 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 19:02 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 8 Submitted By: Tony Nelson (tony_nelson) Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 23:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 23:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 21:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 14:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Sat Jul 29 05:47:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 20:47:49 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Tim Peters (tim_one) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sat Jul 29 06:05:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Jul 2006 21:05:07 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-28 23:47 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) >Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-07-29 00:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sat Jul 29 15:19:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 06:19:25 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sat Jul 29 16:36:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 07:36:04 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 19:02 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 8 Submitted By: Tony Nelson (tony_nelson) Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 10:36 Message: Logged In: YES user_id=1356214 Darn. My test will only work on *nix, and not on other platforms such as MSWindows. I don't see a way to send a signal that would work on all platforms, so I don't know a way to test the patch. I'll have to ask for help. The test may need to be changed to only test on *nix. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 23:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 23:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 21:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 14:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Sat Jul 29 18:43:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 09:43:58 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-29 13:47 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-30 02:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 23:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-29 14:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sat Jul 29 20:20:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 11:20:37 -0700 Subject: [Patches] [ python-Patches-1530738 ] Fix __index__() clipping really big numbers Message-ID: Patches item #1530738, was opened at 2006-07-28 20:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core (C code) Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Fix __index__() clipping really big numbers Initial Comment: Patch attached (index_overflow.diff) that causes __index__() to raise OverflowError for really big numbers instead of silently clipping them. The approach in the patch is a "minimal fix" that is as ugly as hell (3 different error return codes!), so I'm going to try for a cleaner version that changes nb_index to return a PyObject* (then the client code can decide whether to convert to Py_ssize_t or not, and whether to clip or raise OverflowError when doing so). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 11:20 Message: Logged In: YES user_id=33168 The description is no longer valid, this is not a minimal patch. I haven't thought about the actual design of the patch, but I have a bunch of issues. In no particular, order: * tests should not use the assert statement, but self.assert* * There are a bunch of formatting changes (one place with a couple of extra blank lines, other places where tabs became spaces or vica versa) * I think there might be behaviour changes wrt checking for sq_ass_item and sq_get_item and raising type_error()s. I didn't think about this hard, but just from a quick review there was a red flag. * PyNumber_Index(o, is_index) is a bogus naming. Either the API should change or is_index should change. It doesn't make sense to me that you would call an API to get the index that is not an index. * int_index became int_int, same with long, but not in other places. I don't understand the name change. I need to think more about the structure of this patch. There's something I don't like, but I'm not sure what it is without further review. More eyes would definitely help. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 09:43 Message: Logged In: YES user_id=1038590 Revised the patch to further reduce code duplication in the implementation, and to reduce the divergence from PEP 357. The functions in the C API now have the names PyNumber_Index (raises IndexError), PyNumber_AsSsize_t (raises OverflowError) and PyNumber_AsClippedSsize_t (clamps to PY_SSIZE_T_MIN/MAX), and are no longer exposed through the operator module. Python code should either use __index__() directly (if not constrained to concrete containers) or else use operator.index(). ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-07-29 06:19 Message: Logged In: YES user_id=1038590 Attaching the patch that approaches the problem from the ground up by redesigning the PEP 357 C API to meet the needs of the actual use cases in the standard library. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-28 21:05 Message: Logged In: YES user_id=31435 Since I don't think this is a sane approach, I'm not going to spend time reviewing it :-) Suggest working out what's /wanted/ on python-dev first, including beefing up PEP 357 so it spells out the revised intents. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530738&group_id=5470 From noreply at sourceforge.net Sat Jul 29 20:23:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 11:23:41 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 16:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 8 Submitted By: Tony Nelson (tony_nelson) Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 11:23 Message: Logged In: YES user_id=33168 Does the bug affect Windows? A test that only runs on Unix is better than nothing. If the test can't be fixed to run on Windows, please add a comment with an XXX to discuss this and try to get someone to impl a Windows version. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 07:36 Message: Logged In: YES user_id=1356214 Darn. My test will only work on *nix, and not on other platforms such as MSWindows. I don't see a way to send a signal that would work on all platforms, so I don't know a way to test the patch. I'll have to ask for help. The test may need to be changed to only test on *nix. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 20:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 18:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 11:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Sat Jul 29 21:27:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 12:27:23 -0700 Subject: [Patches] [ python-Patches-1490989 ] Describe Py_DEBUG and friends... Message-ID: Patches item #1490989, was opened at 2006-05-18 10:33 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490989&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: A.M. Kuchling (akuchling) Summary: Describe Py_DEBUG and friends... Initial Comment: Here's a minimal first cut at describing Py_DEBUG and friends. Hopefully the description is detailed enough to be useful but not so detailed as to always be out-of-date. If nothing else, perhaps it will spur someone with better knowledge of these details to correct my mistakes and flesh out detail. As is usual for me, I have not run this through LaTeX. (I lack it at work.) It will need to be checked for correctness. Skip ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 15:27 Message: Logged In: YES user_id=11375 I've applied a slightly modified version of your patch in rev. 50948. Good work! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-05-18 11:48 Message: Logged In: YES user_id=44345 If I did I forgot. I was grepping around trying to figure out what Py_DEBUG did exactly and saw the XXX comment in Doc/api/api.tex. I naively assumed at that point that Py_DEBUG and friends weren't documented. In any case, I think it makes sense to have some mention of the available options in api.tex, simply because it's the "official" documentation. It should reference Misc/SpecialBuilds.txt as well. Skip ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-05-18 11:13 Message: Logged In: YES user_id=6656 You know about Misc/SpecialBuilds.txt? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1490989&group_id=5470 From noreply at sourceforge.net Sat Jul 29 21:28:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 12:28:58 -0700 Subject: [Patches] [ python-Patches-1494140 ] Documentation for new Struct object Message-ID: Patches item #1494140, was opened at 2006-05-24 05:26 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for new Struct object Initial Comment: The performance enhancements to the struct module (patch #1493701) are implemented by having a Struct object, which is a compiled structure. This text file documents these new struct objects. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 15:28 Message: Logged In: YES user_id=11375 Does this patch still need to be updated for pack_to(), or can it just be applied? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-07-10 13:26 Message: Logged In: YES user_id=671362 Patch for the TeX style doc. Bob, can you work on updating the main section right after 2.5 b2? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-26 09:05 Message: Logged In: YES user_id=139309 We're going to need to revise this patch some more to document the new pack_to function (for Martin Blais' hotbuf work) Additionally we'll probably also want to revise the main struct documentation to talk about bounds checking and avoiding the creation of long objects. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 10:32 Message: Logged In: YES user_id=139309 That's clearly a typo. I've attached a new version of the patch that removes those two letters. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-24 17:03 Message: Logged In: YES user_id=764593 Shouldn't self.size be the number of bytes required to *pack * the structure? The number required to *unpack* seems like it ought to include tuple overhead and such... ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 11:35 Message: Logged In: YES user_id=139309 New patch attached, fixed unpack documentation, added unpack_from method. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 10:54 Message: Logged In: YES user_id=139309 Hold up on this patch, I need to revise it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 From noreply at sourceforge.net Sat Jul 29 21:57:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 12:57:20 -0700 Subject: [Patches] [ python-Patches-1068277 ] os.path.exists returns False if no permission Message-ID: Patches item #1068277, was opened at 2004-11-17 16:20 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Robert Brewer (aminusfu) >Assigned to: A.M. Kuchling (akuchling) Summary: os.path.exists returns False if no permission Initial Comment: A single new sentence for os.path.exists description, which makes it clear that it may return False even if the path actually exists. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 15:57 Message: Logged In: YES user_id=11375 Fred approved this patch, so I've tweaked it a little and committed it. (rev. 50950 on the trunk, 50951 on the release24-maint branch.) If we want to change the underlying implementation (and hence semantics) of os.path.exists(), I think that should be a PEP, or at least a separate bug. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-12-20 09:53 Message: Logged In: YES user_id=4771 Actually, what about the following ? def exists(path): return os.access(path, os.F_OK) It returns True on all existing directory entries apart from broken links and links pointing within unreadable directories. I don't see any similar nice solution for the more recent os.path.lexists()... There are cases where the above exists() returns True but the current lexists() returns False, which is strange because lexists() is supposed to be a more permissive version of exists(). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-12-20 08:00 Message: Logged In: YES user_id=4771 I don't see an obvious way to do it, but shouldn't os.path.exists() try harder to return the expected answer? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-12-05 01:56 Message: Logged In: YES user_id=3066 This should be committed on the trunk and release24-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1068277&group_id=5470 From noreply at sourceforge.net Sat Jul 29 23:56:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 14:56:17 -0700 Subject: [Patches] [ python-Patches-1519025 ] New ver. of 1102879: Fix for 926423: socket timeouts Message-ID: Patches item #1519025, was opened at 2006-07-07 19:02 Message generated for change (Comment added) made by tony_nelson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Modules Group: None Status: Open Resolution: None Priority: 8 Submitted By: Tony Nelson (tony_nelson) Assigned to: Anthony Baxter (anthonybaxter) Summary: New ver. of 1102879: Fix for 926423: socket timeouts Initial Comment: This is a new version of the patch for 1102879, "Fix for 926423: socket timeouts + Ctrl-C don't play nice". It passes "make EXTRATESTOPTS=-unetwork test". I've also made a version for Python 2.4.3 (for FC5), at , which also passes tests, and works with yum on FC5. This is my first patch to Python. I didn't see a way to attach a file to the old patch. My patch is slightly different from the original patch. My patch brings the error path back to the main line: where the original patch would call PyErr_SetFromErrno() for internal_select() errors, mine initializes the status vars so that the normal error handler will be called, and detects timeout when internal_select() returns 1. Thus the normal (replaceable) error handler is called for errors whether or not a timeout is set. The patch handles connect() calls, and sock_connect_ex() now checks for signals as would PyErr_SetFromErrno(). I didn't change the name "timeout" as it didn't bother me. I didn't add any confusing macros. This patch took so long because of confusion (and vacation). Before the patch, Ctl-C would produce an EWOULDBLOCK error, after the patch an EINTR error, but still no KeyboardInterrupt exception. It too me way too long to notice that the rpm library used by yum sets its own signal handlers, and that one line of code (setting SIGINT back to the python default) would fix it. Now that I have KeyboardInterrupts I have confidence in this patch. ---------------------------------------------------------------------- >Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 17:56 Message: Logged In: YES user_id=1356214 I'm pretty sure that the bug would affect MSWindows. I don't know how to make the test work without sending a signal, such as signal.alarm() or os.kill(), which don't seem to be available on other platforms. I've marked the test with XXX and a comment as requested. I've posed the question on python-dev. Should I ask there for specific help writing the test? The test in this version of the patch has fewer race conditions (and reports the bug differently) than the previous test. The functional part of the patch is unchanged. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 14:23 Message: Logged In: YES user_id=33168 Does the bug affect Windows? A test that only runs on Unix is better than nothing. If the test can't be fixed to run on Windows, please add a comment with an XXX to discuss this and try to get someone to impl a Windows version. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-29 10:36 Message: Logged In: YES user_id=1356214 Darn. My test will only work on *nix, and not on other platforms such as MSWindows. I don't see a way to send a signal that would work on all platforms, so I don't know a way to test the patch. I'll have to ask for help. The test may need to be changed to only test on *nix. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-28 23:46 Message: Logged In: YES user_id=1356214 Here is a new patch that adds a test, in test_socket.py TCPTimeoutTest.testInterruptedTimeout(); the functional part of the patch is unchanged. The test doesn't use an actual Ctl-C, or even a SIGINT, as sending one of them seemed hard; it sends a SIGALRM instead. The test passes with the patch; without the patch it prints a confused error message, but unfortunately that's about right. As for what I mean by "test", well, I was confused about what was being threaded. I have it straight now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 23:58 Message: Logged In: YES user_id=33168 The test_unary_minus problem is due to gcc4.1 optimizations. We need to fix that. Yes, please write a test. As long as you can reproduce the problem with the old code and the new code doesn't crash, that's an improvement. Thanks! Not sure what you mean by "test". It should at least be in a separate method. Perhaps you could use a new class in test_socket. I doubt that a new file should be necessary. Even a new class seems like it probably shouldn't be necessary, but I can't say without actually having written the test. We'll figure out where to put it as long as we have a test case. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2006-07-23 21:58 Message: Logged In: YES user_id=1356214 Thank you for your advice. I have updated the patch for HEAD (r50793). It passes "make EXTRATESTOPTS=-unetwork test" except for test_compile, which fails test_unary_minus. Should I try to write the test? I think that it could try to accept() and another thread could send a signal. I think it would have to be separate from all the other tests, which are threaded, so that it won't interfere with them. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-23 14:36 Message: Logged In: YES user_id=33168 I'm +0.5 or more this going in to 2.5 final. However, I'd really like to see a test for this. Also, the patch should be updated to HEAD. It doesn't look like it will apply cleanly as there were many changes to socketmodule.c. As for a test, I think if you try to connect to a non-existant host and send a signal from another thread, I think that can trigger the bug. Anthony, let me know your thoughts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1519025&group_id=5470 From noreply at sourceforge.net Sun Jul 30 01:56:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 16:56:20 -0700 Subject: [Patches] [ python-Patches-1489771 ] Updates to syntax rules in reference manual Message-ID: Patches item #1489771, was opened at 2006-05-16 21:09 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Updates to syntax rules in reference manual Initial Comment: I tried to update the reference manual to the current Python syntax. Some things are still missing, most notably the yield expression. Detailed description of changes below. I can also attach the generated webpages, if someone is interested. Expressions =========== List Displays ------------- Reordered the rules so that the style is consistent with the rest of the manual. Separated listmaker into expression_list and list_comprehension, for better readability. Replaced "expression_list" between "for" and "in" with "target_list". See this thread for details: http://mail.python.org/pipermail/python-dev/2006-April/064264.html The only thing missing is old_lambdadef. Generator Expressions --------------------- Simmilar as above. Calls ----- Fixed the latex syntax (somebody forgot to remove a line when generators were introduced). Replaced test with expression. Fixed allowed positions for commas (func(*args,) is not allowed). Boolean operations ------------------ Restructured the new conditional expression so that it is more readable. Simple Statements ================= Augmented assignment statements ------------------------------- Removed comments from "productionlist" macro, since they broke the generated grammar.txt file. Removed empty groups that are not needed anymore, since automatic conversion to guillemets was disabled. Unfortunately the escaped operator characters would still need manual fixing in the grammar.txt file. The print statement ------------------- Removed all uses of the "optional" macro and replaced them with sqare brackets, since it broke the generated grammar.txt file. The import statement -------------------- Replaced all invalid uses of name with identifier. Added relative import notation to the grammar section. Description of relative imports is still needed. The exec statement ------------------ Corrected a minor mistake, since exec "a = 1" or "a = 2" is not valid Python syntax. Added a (commented out) section about a strange feature (you can already treat exec as a function) that should IMHO be included in documentation and its use encouraged over the current notation. Compound statements =================== The with statement ------------------ Added missing macro. Function definition ------------------- Cleaned up "parameter_list" so that it is correct and expresses all the restrictions, but is still easier to understand (I hope). Still needed ------------ Yield became an expression in version 2.5, but this is not documented. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 01:56 Message: Logged In: YES user_id=1326842 Attaching a patch updated to the current trunk with two minor fixes: - I reverted the changes to the __future__ statement because they broke the output; - fixed a mistake in the function definition section; I didn't know that ``def f(a, (b, c)=(1, 2)): pass`` is valid syntax. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-18 05:46 Message: Logged In: YES user_id=1326842 I created another patch and updated the previous two with the following fixes: - Disabled an example of the EBNF notation in introduction to prevent name clashes and inclusion into the generated grammar file. - yield can be a bare statement in 2.5. - Reintroduced "name" in import statements, so that explanation can stay the same. - Reformated __future__ import statement, but left the latex syntax broken so that it still won't be included into grammar.txt. - Fixed a paragraph about valid __future__ features. The new patch is more of an example how hard it would be to synchronise the names. It is more or less consistent with the Grammar file, but as a consequence is completely out of sync with the surrounding text. While I would like to see less differences betwen Grammar and Reference manual, I don't think it is that easy, since someone would also have to check the rest of the text and fix all incorrect references. I would guess that the same holds for changing the Grammar file; you would simply have to change too much code. I think that the simplest solution is to add the table from my previous comment to the PEP 306. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:55 Message: Logged In: YES user_id=764593 I agree that it would be better if they were consistent. But does the manual have better names? If so, alpha is a good time to fix the grammar file. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-17 18:54 Message: Logged In: YES user_id=1326842 Token names in reference manual already differ from those in Grammar file. I only added new tokens where it helps readability: - I've split listmaker into expression_list (already present in reference manual and often used) and list_comprehension. - I added conditional_expression, because I thought it helps readability. - Differences in function definiton and call syntax can't be avoided since Grammar file doesn't express all the limitations. - Same goes for target_list; Grammar uses testlist, but that was one of the problems raised in the thread mentioned above. The biggest problem is that what is known as "test" in Grammar/Grammar, is "expression" in the reference manual, and I think I fixed all parts that didn't take this in cosideration. I'm attaching two new patches. reference_manual_updated.diff contains another fix (removed unneeded markup and comments), but is otherwise the same as the previous patch. reference_manual_conservative.diff also contains this fix, but removes tokens list_comprehension and conditional_expression. This means that there are still large differences between Grammar file and reference manual, most notably: Grammar manual --------------------------------------------- NAME identifier expr or_expr test expression old_test test testlist expression_list | target_list testlist_safe testlist All of these differences were already present before my changes. Let me know if you want them fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 17:01 Message: Logged In: YES user_id=849994 I think the token names in the reference should not be different from those in python/Grammar/Grammar. Aside from this, the patch is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 From noreply at sourceforge.net Sun Jul 30 02:42:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 17:42:55 -0700 Subject: [Patches] [ python-Patches-793553 ] urllib SSL authentication docs are wrong Message-ID: Patches item #793553, was opened at 2003-08-22 17:15 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: John J Lee (jjlee) >Assigned to: A.M. Kuchling (akuchling) Summary: urllib SSL authentication docs are wrong Initial Comment: urllib docs for URLOpener say: Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. They're not needed, and the certificate is never checked, because _ssl.c doesn't check it (which is documented in the socket.ssl docs). A doc patch is attached. ---------------------------------------------------------------------- >Comment By: Nobody/Anonymous (nobody) Date: 2006-07-29 17:42 Message: Logged In: NO Patch applied to docs in rev. 50962. The feature of providing a client cert does seem to work. I verified this by running "openssl s_server -accept 8000 -www -cert server.cert -key server.key -verify 1" to provide a server on port 8000, and then running the attached client script. (You'll need to generate client and server keys and certs first.) On running the script, the server prints messages showing that it's received a certificate. Therefore, I'm closing this patch. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-06-10 13:20 Message: Logged In: YES user_id=3066 This should be handled by someone who knows something about the SSL API. I'm not at all sure why I assigned it to myself to begin with. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 11:27 Message: Logged In: YES user_id=21627 Sure, I agree the current documentation is wrong. It would be good to test the feature before correcting the documentation, though. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-31 11:09 Message: Logged In: YES user_id=261020 <Googles for x509> Ah. That appears to be true. In that case, do you agree that the following is still wrong (taken from urllib.URLOpener docs)? Additional keyword parameters, collected in x509, are used for authentication with the https: scheme. The keywords key_file and cert_file are supported; both are needed to actually retrieve a resource at an https: URL. You don't need either dict entry for opening most https: URLs. Also, it gives no clue that x509 is for client authentication, and that server authentication is not done. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 09:16 Message: Logged In: YES user_id=21627 Isn't the purpose of these arguments client-side authentication? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=793553&group_id=5470 From noreply at sourceforge.net Sun Jul 30 05:56:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 20:56:16 -0700 Subject: [Patches] [ python-Patches-1531113 ] "a += yield foo" compiles as "a += yield (yield foo)" Message-ID: Patches item #1531113, was opened at 2006-07-29 23:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christopher Tur Lesniewski-Laas (ctl) Assigned to: Nobody/Anonymous (nobody) Summary: "a += yield foo" compiles as "a += yield (yield foo)" Initial Comment: [Note: my apologies for not attaching the patches using the file upload; the file upload button is not showing up in my Mozilla-based browsers. I'd be happy to email the patches in MIME attachments if you provide an email address.] While working on a new async framework package based on Python 2.5's new coroutine generators, I discovered a "this could never have worked" bug in the AST compiler or augmented assigns using the new yield operator. The bug is that "a += yield foo" is compiled as "a += yield (yield foo)". A simple program that demonstrates this bug is: def coroutine(): a = 0 while a < 200: a += yield print a c = coroutine() c.next() c.send(10) c.send(20) c.send(30) c.send(40) c.send(50) This prints out: 20 60 instead of the expected: 10 30 60 100 150 The disassembler shows that two Yield instructions are getting inserted where there should be just one: 2 0 LOAD_CONST 1 (0) 3 STORE_FAST 0 (a) 3 6 SETUP_LOOP 35 (to 44) >> 9 LOAD_FAST 0 (a) 12 LOAD_CONST 2 (200) 15 COMPARE_OP 0 (<) 18 JUMP_IF_FALSE 21 (to 42) 21 POP_TOP 4 22 LOAD_FAST 0 (a) 25 LOAD_CONST 0 (None) 28 YIELD_VALUE 29 YIELD_VALUE 30 INPLACE_ADD 31 STORE_FAST 0 (a) 5 34 LOAD_FAST 0 (a) 37 PRINT_ITEM 38 PRINT_NEWLINE 39 JUMP_ABSOLUTE 9 >> 42 POP_TOP 43 POP_BLOCK >> 44 LOAD_CONST 0 (None) 47 RETURN_VALUE The offending code is in Python/ast.c, function ast_for_expr_stmt(): expr2 = Yield(ast_for_expr(c, ch), LINENO(ch), ch->n_col_offset, c->c_arena); since ast_for_expr(c, ch) processes the Yield node again. The following patch resolves the problem for me: Index: Python/ast.c =================================================================== --- Python/ast.c (revision 50930) +++ Python/ast.c (working copy) @@ -1964,7 +1964,7 @@ if (TYPE(ch) == testlist) expr2 = ast_for_testlist(c, ch); else - expr2 = Yield(ast_for_expr(c, ch), LINENO(ch), ch->n_col_offset, c->c_arena); + expr2 = ast_for_expr(c, ch); if (!expr2) return NULL; -------------------------------------------------------------------- A separate, minor issue I discovered while looking at this code: the ast_for_expr_stmt function seems to contain code to handle the case: (yield foo) += bar even though it correctly fails on the case: (yield foo) = bar This is just confusing; the two cases should match. The following patch is one way of solving this problem: Index: Python/ast.c =================================================================== --- Python/ast.c (revision 50930) +++ Python/ast.c (working copy) @@ -1928,11 +1928,11 @@ operator_ty newoperator; node *ch = CHILD(n, 0); - if (TYPE(ch) == testlist) - expr1 = ast_for_testlist(c, ch); - else - expr1 = Yield(ast_for_expr(c, CHILD(ch, 0)), LINENO(ch), n->n_col_offset, - c->c_arena); + if (TYPE(ch) == yield_expr) { + ast_error(ch, "assignment to yield expression not possible"); + return NULL; + } + expr1 = ast_for_testlist(c, ch); if (!expr1) return NULL; Cheers, Chris Lesniewski ctl mit edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531113&group_id=5470 From noreply at sourceforge.net Sun Jul 30 06:16:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Jul 2006 21:16:54 -0700 Subject: [Patches] [ python-Patches-1531113 ] "a += yield foo" compiles as "a += yield (yield foo)" Message-ID: Patches item #1531113, was opened at 2006-07-29 20:56 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None >Priority: 9 Submitted By: Christopher Tur Lesniewski-Laas (ctl) Assigned to: Nobody/Anonymous (nobody) Summary: "a += yield foo" compiles as "a += yield (yield foo)" Initial Comment: [Note: my apologies for not attaching the patches using the file upload; the file upload button is not showing up in my Mozilla-based browsers. I'd be happy to email the patches in MIME attachments if you provide an email address.] While working on a new async framework package based on Python 2.5's new coroutine generators, I discovered a "this could never have worked" bug in the AST compiler or augmented assigns using the new yield operator. The bug is that "a += yield foo" is compiled as "a += yield (yield foo)". A simple program that demonstrates this bug is: def coroutine(): a = 0 while a < 200: a += yield print a c = coroutine() c.next() c.send(10) c.send(20) c.send(30) c.send(40) c.send(50) This prints out: 20 60 instead of the expected: 10 30 60 100 150 The disassembler shows that two Yield instructions are getting inserted where there should be just one: 2 0 LOAD_CONST 1 (0) 3 STORE_FAST 0 (a) 3 6 SETUP_LOOP 35 (to 44) >> 9 LOAD_FAST 0 (a) 12 LOAD_CONST 2 (200) 15 COMPARE_OP 0 (<) 18 JUMP_IF_FALSE 21 (to 42) 21 POP_TOP 4 22 LOAD_FAST 0 (a) 25 LOAD_CONST 0 (None) 28 YIELD_VALUE 29 YIELD_VALUE 30 INPLACE_ADD 31 STORE_FAST 0 (a) 5 34 LOAD_FAST 0 (a) 37 PRINT_ITEM 38 PRINT_NEWLINE 39 JUMP_ABSOLUTE 9 >> 42 POP_TOP 43 POP_BLOCK >> 44 LOAD_CONST 0 (None) 47 RETURN_VALUE The offending code is in Python/ast.c, function ast_for_expr_stmt(): expr2 = Yield(ast_for_expr(c, ch), LINENO(ch), ch->n_col_offset, c->c_arena); since ast_for_expr(c, ch) processes the Yield node again. The following patch resolves the problem for me: Index: Python/ast.c =================================================================== --- Python/ast.c (revision 50930) +++ Python/ast.c (working copy) @@ -1964,7 +1964,7 @@ if (TYPE(ch) == testlist) expr2 = ast_for_testlist(c, ch); else - expr2 = Yield(ast_for_expr(c, ch), LINENO(ch), ch->n_col_offset, c->c_arena); + expr2 = ast_for_expr(c, ch); if (!expr2) return NULL; -------------------------------------------------------------------- A separate, minor issue I discovered while looking at this code: the ast_for_expr_stmt function seems to contain code to handle the case: (yield foo) += bar even though it correctly fails on the case: (yield foo) = bar This is just confusing; the two cases should match. The following patch is one way of solving this problem: Index: Python/ast.c =================================================================== --- Python/ast.c (revision 50930) +++ Python/ast.c (working copy) @@ -1928,11 +1928,11 @@ operator_ty newoperator; node *ch = CHILD(n, 0); - if (TYPE(ch) == testlist) - expr1 = ast_for_testlist(c, ch); - else - expr1 = Yield(ast_for_expr(c, CHILD(ch, 0)), LINENO(ch), n->n_col_offset, - c->c_arena); + if (TYPE(ch) == yield_expr) { + ast_error(ch, "assignment to yield expression not possible"); + return NULL; + } + expr1 = ast_for_testlist(c, ch); if (!expr1) return NULL; Cheers, Chris Lesniewski ctl mit edu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531113&group_id=5470 From noreply at sourceforge.net Sun Jul 30 09:01:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 00:01:27 -0700 Subject: [Patches] [ python-Patches-1531113 ] "a += yield foo" compiles as "a += yield (yield foo)" Message-ID: Patches item #1531113, was opened at 2006-07-29 20:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531113&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Christopher Tur Lesniewski-Laas (ctl) >Assigned to: Neal Norwitz (nnorwitz) Summary: "a += yield foo" compiles as "a += yield (yield foo)" Initial Comment: [Note: my apologies for not attaching the patches using the file upload; the file upload button is not showing up in my Mozilla-based browsers. I'd be happy to email the patches in MIME attachments if you provide an email address.] While working on a new async framework package based on Python 2.5's new coroutine generators, I discovered a "this could never have worked" bug in the AST compiler or augmented assigns using the new yield operator. The bug is that "a += yield foo" is compiled as "a += yield (yield foo)". A simple program that demonstrates this bug is: def coroutine(): a = 0 while a < 200: a += yield print a c = coroutine() c.next() c.send(10) c.send(20) c.send(30) c.send(40) c.send(50) This prints out: 20 60 instead of the expected: 10 30 60 100 150 The disassembler shows that two Yield instructions are getting inserted where there should be just one: 2 0 LOAD_CONST 1 (0) 3 STORE_FAST 0 (a) 3 6 SETUP_LOOP 35 (to 44) >> 9 LOAD_FAST 0 (a) 12 LOAD_CONST 2 (200) 15 COMPARE_OP 0 (<) 18 JUMP_IF_FALSE 21 (to 42) 21 POP_TOP 4 22 LOAD_FAST 0 (a) 25 LOAD_CONST 0 (None) 28 YIELD_VALUE 29 YIELD_VALUE 30 INPLACE_ADD 31 STORE_FAST 0 (a) 5 34 LOAD_FAST 0 (a) 37 PRINT_ITEM 38 PRINT_NEWLINE 39 JUMP_ABSOLUTE 9 >> 42 POP_TOP 43 POP_BLOCK >> 44 LOAD_CONST 0 (None) 47 RETURN_VALUE The offending code is in Python/ast.c, function ast_for_expr_stmt(): expr2 = Yield(ast_for_expr(c, ch), LINENO(ch), ch->n_col_offset, c->c_arena); since ast_for_expr(c, ch) processes the Yield node again. The following patch resolves the problem for me: Index: Python/ast.c =================================================================== --- Python/ast.c (revision 50930) +++ Python/ast.c (working copy) @@ -1964,7 +1964,7 @@ if (TYPE(ch) == testlist) expr2 = ast_for_testlist(c, ch); else - expr2 = Yield(ast_for_expr(c, ch), LINENO(ch), ch->n_col_offset, c->c_arena); + expr2 = ast_for_expr(c, ch); if (!expr2) return NULL; -------------------------------------------------------------------- A separate, minor issue I discovered while looking at this code: the ast_for_expr_stmt function seems to contain code to handle the case: (yield foo) += bar even though it correctly fails on the case: (yield foo) = bar This is just confusing; the two cases should match. The following patch is one way of solving this problem: Index: Python/ast.c =================================================================== --- Python/ast.c (revision 50930) +++ Python/ast.c (working copy) @@ -1928,11 +1928,11 @@ operator_ty newoperator; node *ch = CHILD(n, 0); - if (TYPE(ch) == testlist) - expr1 = ast_for_testlist(c, ch); - else - expr1 = Yield(ast_for_expr(c, CHILD(ch, 0)), LINENO(ch), n->n_col_offset, - c->c_arena); + if (TYPE(ch) == yield_expr) { + ast_error(ch, "assignment to yield expression not possible"); + return NULL; + } + expr1 = ast_for_testlist(c, ch); if (!expr1) return NULL; Cheers, Chris Lesniewski ctl mit edu ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 00:01 Message: Logged In: YES user_id=33168 Thanks! The second part about fixing assignment to yield expressions wasn't correct. Also there was a SystemError for (yield bar) = foo. That definitely needed fixing. Let me know if you find any more issues. Committed revision 50968. BTW, I believe SF fixed the upload button issue by removing the button. I guess we need to update the comment. :-) It should just work now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531113&group_id=5470 From noreply at sourceforge.net Sun Jul 30 13:01:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 04:01:57 -0700 Subject: [Patches] [ python-Patches-1489771 ] Updates to syntax rules in reference manual Message-ID: Patches item #1489771, was opened at 2006-05-16 19:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Updates to syntax rules in reference manual Initial Comment: I tried to update the reference manual to the current Python syntax. Some things are still missing, most notably the yield expression. Detailed description of changes below. I can also attach the generated webpages, if someone is interested. Expressions =========== List Displays ------------- Reordered the rules so that the style is consistent with the rest of the manual. Separated listmaker into expression_list and list_comprehension, for better readability. Replaced "expression_list" between "for" and "in" with "target_list". See this thread for details: http://mail.python.org/pipermail/python-dev/2006-April/064264.html The only thing missing is old_lambdadef. Generator Expressions --------------------- Simmilar as above. Calls ----- Fixed the latex syntax (somebody forgot to remove a line when generators were introduced). Replaced test with expression. Fixed allowed positions for commas (func(*args,) is not allowed). Boolean operations ------------------ Restructured the new conditional expression so that it is more readable. Simple Statements ================= Augmented assignment statements ------------------------------- Removed comments from "productionlist" macro, since they broke the generated grammar.txt file. Removed empty groups that are not needed anymore, since automatic conversion to guillemets was disabled. Unfortunately the escaped operator characters would still need manual fixing in the grammar.txt file. The print statement ------------------- Removed all uses of the "optional" macro and replaced them with sqare brackets, since it broke the generated grammar.txt file. The import statement -------------------- Replaced all invalid uses of name with identifier. Added relative import notation to the grammar section. Description of relative imports is still needed. The exec statement ------------------ Corrected a minor mistake, since exec "a = 1" or "a = 2" is not valid Python syntax. Added a (commented out) section about a strange feature (you can already treat exec as a function) that should IMHO be included in documentation and its use encouraged over the current notation. Compound statements =================== The with statement ------------------ Added missing macro. Function definition ------------------- Cleaned up "parameter_list" so that it is correct and expresses all the restrictions, but is still easier to understand (I hope). Still needed ------------ Yield became an expression in version 2.5, but this is not documented. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 11:01 Message: Logged In: YES user_id=849994 The testlist in list comprehensions ("testlist_safe" in Grammar/Grammar) is different from the normal testlist. Does your patch address this? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-29 23:56 Message: Logged In: YES user_id=1326842 Attaching a patch updated to the current trunk with two minor fixes: - I reverted the changes to the __future__ statement because they broke the output; - fixed a mistake in the function definition section; I didn't know that ``def f(a, (b, c)=(1, 2)): pass`` is valid syntax. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-18 03:46 Message: Logged In: YES user_id=1326842 I created another patch and updated the previous two with the following fixes: - Disabled an example of the EBNF notation in introduction to prevent name clashes and inclusion into the generated grammar file. - yield can be a bare statement in 2.5. - Reintroduced "name" in import statements, so that explanation can stay the same. - Reformated __future__ import statement, but left the latex syntax broken so that it still won't be included into grammar.txt. - Fixed a paragraph about valid __future__ features. The new patch is more of an example how hard it would be to synchronise the names. It is more or less consistent with the Grammar file, but as a consequence is completely out of sync with the surrounding text. While I would like to see less differences betwen Grammar and Reference manual, I don't think it is that easy, since someone would also have to check the rest of the text and fix all incorrect references. I would guess that the same holds for changing the Grammar file; you would simply have to change too much code. I think that the simplest solution is to add the table from my previous comment to the PEP 306. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-17 22:55 Message: Logged In: YES user_id=764593 I agree that it would be better if they were consistent. But does the manual have better names? If so, alpha is a good time to fix the grammar file. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-17 16:54 Message: Logged In: YES user_id=1326842 Token names in reference manual already differ from those in Grammar file. I only added new tokens where it helps readability: - I've split listmaker into expression_list (already present in reference manual and often used) and list_comprehension. - I added conditional_expression, because I thought it helps readability. - Differences in function definiton and call syntax can't be avoided since Grammar file doesn't express all the limitations. - Same goes for target_list; Grammar uses testlist, but that was one of the problems raised in the thread mentioned above. The biggest problem is that what is known as "test" in Grammar/Grammar, is "expression" in the reference manual, and I think I fixed all parts that didn't take this in cosideration. I'm attaching two new patches. reference_manual_updated.diff contains another fix (removed unneeded markup and comments), but is otherwise the same as the previous patch. reference_manual_conservative.diff also contains this fix, but removes tokens list_comprehension and conditional_expression. This means that there are still large differences between Grammar file and reference manual, most notably: Grammar manual --------------------------------------------- NAME identifier expr or_expr test expression old_test test testlist expression_list | target_list testlist_safe testlist All of these differences were already present before my changes. Let me know if you want them fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 15:01 Message: Logged In: YES user_id=849994 I think the token names in the reference should not be different from those in python/Grammar/Grammar. Aside from this, the patch is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 From noreply at sourceforge.net Sun Jul 30 13:09:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 04:09:55 -0700 Subject: [Patches] [ python-Patches-1529353 ] Squeezer - squeeze large output in the interpreter Message-ID: Patches item #1529353, was opened at 2006-07-27 03:13 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 4 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Squeezer - squeeze large output in the interpreter Initial Comment: Here is my improved version of Squeezer - the IDLE extension to end all of your oh-no-I-just-printed-War-and-Peace-in-the-interpreter troubles! Changes: * Fixed line counting logic * Line counting is done according to current window width and current tab width * Fixed configHandler to enable reading of raw data from config files (100% backwards compatible) - needed by Squeezer to enable configuration of text viewers in config-extensions I've been working this vesion without a hitch for several weeks, but that's hardly enough testing is it? Attached: * the original Squeezer.py by Noam Raphael * a diff against Noam's original Squeezer.py * a diff of configHandler.py against the current SVN version (revision 46863) * fixed 'middle click to copy' - now works on Windows One minor note - the 'middle click to copy' didn't work on Windows because it simply called selection_own() which doesn't affect the clipboard. I added clipboard_clear() and clipboard_append() and it now works on Windows. This should be tested on Linux, Unix, OSX etc. to check compatibility. For more info on the clipboard issue, see: http://groups.google.com/group/comp.lang.python/browse_thread/thread/647feeef55625733/bc08421d8aea9928?lnk=st&q=&rnum=2#bc08421d8aea9928 ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2006-07-30 14:09 Message: Logged In: YES user_id=1330769 Uploaded unified diffs instead of standard diffs. Probably the first diffs had bad newlines because I'm working on Win. Also 2 changes: * minor fix - end case when clicking at beginning of text block * Allow squeezing of stderr (tracebacks...) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-27 05:49 Message: Logged In: YES user_id=149084 OK, thanks. Please take a look at the two diffs you uploaded, they seem corrupted. Squeezer.py looks ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 From noreply at sourceforge.net Sun Jul 30 14:06:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 05:06:14 -0700 Subject: [Patches] [ python-Patches-1528468 ] PyShell.recall - fix indentation logic Message-ID: Patches item #1528468, was opened at 2006-07-25 19:07 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: Later Priority: 3 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: PyShell.recall - fix indentation logic Initial Comment: PyShell.recall uses wrong indentation logic when recalling a block of code (more than one line). It first inserts the first line and calls newline_and_indent, which inserts a newline and indents the next line according to heuristics - more indent after ':', less after a return, etc. So far so good. Afterwards, for each following line, it just inserts line.strip(), and again calls newline_and_indent. This often ruins the block's indentation, for instance at the end of loops and 'if' blocks. This can easily be improved upon since we have the original indentation. This patch retains the block's original indentation, only adjusting it to fit the current base indentation level. This patch also doesn't add an extra newline at the end of a recalled block, unless there was on there originally. I haven't tested it thoroughly but I have played around with it a lot and tweaked it. So far it seems to work 100%. ---------------------------------------------------------------------- >Comment By: Tal Einat (taleinat) Date: 2006-07-30 15:06 Message: Logged In: YES user_id=1330769 I uploaded an update (another patch, apply after applying the first one), this fixes the behavior a bit. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-27 23:48 Message: Logged In: YES user_id=1330769 Bah, sorry for forgetting to post the file... It really was getting late that night :P ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:30 Message: Logged In: YES user_id=149084 Well, once you get it throughly tested, please attach the patch so I can look at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528468&group_id=5470 From noreply at sourceforge.net Sun Jul 30 15:33:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 06:33:45 -0700 Subject: [Patches] [ python-Patches-1489771 ] Updates to syntax rules in reference manual Message-ID: Patches item #1489771, was opened at 2006-05-16 21:09 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ?iga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Updates to syntax rules in reference manual Initial Comment: I tried to update the reference manual to the current Python syntax. Some things are still missing, most notably the yield expression. Detailed description of changes below. I can also attach the generated webpages, if someone is interested. Expressions =========== List Displays ------------- Reordered the rules so that the style is consistent with the rest of the manual. Separated listmaker into expression_list and list_comprehension, for better readability. Replaced "expression_list" between "for" and "in" with "target_list". See this thread for details: http://mail.python.org/pipermail/python-dev/2006-April/064264.html The only thing missing is old_lambdadef. Generator Expressions --------------------- Simmilar as above. Calls ----- Fixed the latex syntax (somebody forgot to remove a line when generators were introduced). Replaced test with expression. Fixed allowed positions for commas (func(*args,) is not allowed). Boolean operations ------------------ Restructured the new conditional expression so that it is more readable. Simple Statements ================= Augmented assignment statements ------------------------------- Removed comments from "productionlist" macro, since they broke the generated grammar.txt file. Removed empty groups that are not needed anymore, since automatic conversion to guillemets was disabled. Unfortunately the escaped operator characters would still need manual fixing in the grammar.txt file. The print statement ------------------- Removed all uses of the "optional" macro and replaced them with sqare brackets, since it broke the generated grammar.txt file. The import statement -------------------- Replaced all invalid uses of name with identifier. Added relative import notation to the grammar section. Description of relative imports is still needed. The exec statement ------------------ Corrected a minor mistake, since exec "a = 1" or "a = 2" is not valid Python syntax. Added a (commented out) section about a strange feature (you can already treat exec as a function) that should IMHO be included in documentation and its use encouraged over the current notation. Compound statements =================== The with statement ------------------ Added missing macro. Function definition ------------------- Cleaned up "parameter_list" so that it is correct and expresses all the restrictions, but is still easier to understand (I hope). Still needed ------------ Yield became an expression in version 2.5, but this is not documented. ---------------------------------------------------------------------- >Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 15:33 Message: Logged In: YES user_id=1326842 Yes, the only thing missing was old lambda. The new patch ('reference_manual_old_lambda') includes it. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 13:01 Message: Logged In: YES user_id=849994 The testlist in list comprehensions ("testlist_safe" in Grammar/Grammar) is different from the normal testlist. Does your patch address this? ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-07-30 01:56 Message: Logged In: YES user_id=1326842 Attaching a patch updated to the current trunk with two minor fixes: - I reverted the changes to the __future__ statement because they broke the output; - fixed a mistake in the function definition section; I didn't know that ``def f(a, (b, c)=(1, 2)): pass`` is valid syntax. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-18 05:46 Message: Logged In: YES user_id=1326842 I created another patch and updated the previous two with the following fixes: - Disabled an example of the EBNF notation in introduction to prevent name clashes and inclusion into the generated grammar file. - yield can be a bare statement in 2.5. - Reintroduced "name" in import statements, so that explanation can stay the same. - Reformated __future__ import statement, but left the latex syntax broken so that it still won't be included into grammar.txt. - Fixed a paragraph about valid __future__ features. The new patch is more of an example how hard it would be to synchronise the names. It is more or less consistent with the Grammar file, but as a consequence is completely out of sync with the surrounding text. While I would like to see less differences betwen Grammar and Reference manual, I don't think it is that easy, since someone would also have to check the rest of the text and fix all incorrect references. I would guess that the same holds for changing the Grammar file; you would simply have to change too much code. I think that the simplest solution is to add the table from my previous comment to the PEP 306. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-18 00:55 Message: Logged In: YES user_id=764593 I agree that it would be better if they were consistent. But does the manual have better names? If so, alpha is a good time to fix the grammar file. ---------------------------------------------------------------------- Comment By: ?iga Seilnacht (zseil) Date: 2006-05-17 18:54 Message: Logged In: YES user_id=1326842 Token names in reference manual already differ from those in Grammar file. I only added new tokens where it helps readability: - I've split listmaker into expression_list (already present in reference manual and often used) and list_comprehension. - I added conditional_expression, because I thought it helps readability. - Differences in function definiton and call syntax can't be avoided since Grammar file doesn't express all the limitations. - Same goes for target_list; Grammar uses testlist, but that was one of the problems raised in the thread mentioned above. The biggest problem is that what is known as "test" in Grammar/Grammar, is "expression" in the reference manual, and I think I fixed all parts that didn't take this in cosideration. I'm attaching two new patches. reference_manual_updated.diff contains another fix (removed unneeded markup and comments), but is otherwise the same as the previous patch. reference_manual_conservative.diff also contains this fix, but removes tokens list_comprehension and conditional_expression. This means that there are still large differences between Grammar file and reference manual, most notably: Grammar manual --------------------------------------------- NAME identifier expr or_expr test expression old_test test testlist expression_list | target_list testlist_safe testlist All of these differences were already present before my changes. Let me know if you want them fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 17:01 Message: Logged In: YES user_id=849994 I think the token names in the reference should not be different from those in python/Grammar/Grammar. Aside from this, the patch is fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1489771&group_id=5470 From noreply at sourceforge.net Sun Jul 30 15:39:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 06:39:43 -0700 Subject: [Patches] [ python-Patches-780595 ] Fix zip file header format in zipfile.py Message-ID: Patches item #780595, was opened at 2003-07-30 23:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780595&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: John M. Baughman (scuzball1) Assigned to: Greg Ward (gward) Summary: Fix zip file header format in zipfile.py Initial Comment: The zip file header unpack format uses signed longs for those values. For the readfile function to work with very large files (2GB+ in my case) it needs to use unsigned longs. In the case of these files, the readfile code would break with a memory error when trying to buffer backwards in memory since the value is converted to a signed long producing a negative value. This patch converts the header unpack format to use unsigned longs. -John M. Baughman ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 13:39 Message: Logged In: YES user_id=849994 Something similar has been done in rev. 36413. ---------------------------------------------------------------------- Comment By: John M. Baughman (scuzball1) Date: 2003-07-31 15:44 Message: Logged In: YES user_id=834241 My bad, this patch is for zipfile.py. Got in a slight hurry last night and didn't complete the description well enough. -John M. Baughman ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=780595&group_id=5470 From noreply at sourceforge.net Sun Jul 30 16:20:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 07:20:04 -0700 Subject: [Patches] [ python-Patches-1529353 ] Squeezer - squeeze large output in the interpreter Message-ID: Patches item #1529353, was opened at 2006-07-26 20:13 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: None Status: Open Resolution: None Priority: 4 Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Squeezer - squeeze large output in the interpreter Initial Comment: Here is my improved version of Squeezer - the IDLE extension to end all of your oh-no-I-just-printed-War-and-Peace-in-the-interpreter troubles! Changes: * Fixed line counting logic * Line counting is done according to current window width and current tab width * Fixed configHandler to enable reading of raw data from config files (100% backwards compatible) - needed by Squeezer to enable configuration of text viewers in config-extensions I've been working this vesion without a hitch for several weeks, but that's hardly enough testing is it? Attached: * the original Squeezer.py by Noam Raphael * a diff against Noam's original Squeezer.py * a diff of configHandler.py against the current SVN version (revision 46863) * fixed 'middle click to copy' - now works on Windows One minor note - the 'middle click to copy' didn't work on Windows because it simply called selection_own() which doesn't affect the clipboard. I added clipboard_clear() and clipboard_append() and it now works on Windows. This should be tested on Linux, Unix, OSX etc. to check compatibility. For more info on the clipboard issue, see: http://groups.google.com/group/comp.lang.python/browse_thread/thread/647feeef55625733/bc08421d8aea9928?lnk=st&q=&rnum=2#bc08421d8aea9928 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-30 10:20 Message: Logged In: YES user_id=149084 Ah, that's better. Thanks. ---------------------------------------------------------------------- Comment By: Tal Einat (taleinat) Date: 2006-07-30 07:09 Message: Logged In: YES user_id=1330769 Uploaded unified diffs instead of standard diffs. Probably the first diffs had bad newlines because I'm working on Win. Also 2 changes: * minor fix - end case when clicking at beginning of text block * Allow squeezing of stderr (tracebacks...) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 22:49 Message: Logged In: YES user_id=149084 OK, thanks. Please take a look at the two diffs you uploaded, they seem corrupted. Squeezer.py looks ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1529353&group_id=5470 From noreply at sourceforge.net Sun Jul 30 19:02:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 10:02:57 -0700 Subject: [Patches] [ python-Patches-1346238 ] A constant folding optimization pass for the AST Message-ID: Patches item #1346238, was opened at 2005-11-02 10:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance >Group: Python 2.6 Status: Open Resolution: None >Priority: 6 Submitted By: Rune Holm (titanstar) Assigned to: Neal Norwitz (nnorwitz) Summary: A constant folding optimization pass for the AST Initial Comment: This patch adds the following: A visitor interface generalized from the existing ast pass code in order to make it easy to write ast passes that only care about specific node types. A constant folding pass that looks for operations involving number or string literals, and calculates these at compile time. Example code snippets that this pass will optimize: 3 + 4 + x => 7 + x 2 ** 2 ** 2 => 16 4 and 5 and x and 6 => x and 6 4 or 5 or x => 4 4 and 5 and ~6 => -7 When combined with patch 1346214, the compiler will also optimize statements like if 2**2**2 - 16: expensive_computation() => nothing The patch adds two new files: Include/optimize.h and Python.optimize.c. This was done because I anticipate adding more AST optimizations later using the same visitor interface, and Python/compile.c is already very crowded with byte code generation and bytecode optimization. If new files aren't desired, I could easily change the pass to add the extra code to compile.c This patch combined with patch 1346214 passes the unit tests on all the platforms I've tested it on, namely: macos 10.3/ppc linux/x86 linux/amd64 linux/ppc linux/ia64 valgrind on linux/x86 does not reveal any additional leaks or uninitialized accesses that aren't already in the svn head. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 10:02 Message: Logged In: YES user_id=33168 Shoot. I missed this. Bumping priority so hopefully I will remember to take a look at this after 2.5 is out. We still need to split up compile.c along the lines of Jeremy's 2006 PyCon presentation (1-2 extra files). I think one extra file was for assembly. I don't remember the details now. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-17 08:54 Message: Logged In: YES user_id=849994 Candidate for Iceland? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-19 09:12 Message: Logged In: YES user_id=80475 I'm +1 on the idea, but won't have an opportunity to review the patch in detail (to check for possible semantic changes). Neal, what do you think? ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2006-02-19 05:35 Message: Logged In: YES user_id=858364 It avoids generating constant objects with sizes above 20 (in a similar fashion as the bytecode peepholer), and checks whether the operand of unary minus is non-zero in order to avoid changing -0.0. As for the bytecode peephole optimizer, this AST constant folder performs quite similar optimizations, but optimizes partially constant and/or and comparative expressions in addition. This patch should however not be seen as a replacement for the bytecode constant folder, but rather as a complement. An optimizing compiler typically contains many forms of constant folding in the different phases of compilation, since many later optimizations benefit from constant folding (warranting early constant folding), and some optimizations might emit code that benefit from constant folding again (warranting late constant folding). For an example of the former, consider the statement if 1-1: some_code() both passes are able to transform this into if 0: some_code() but since the AST constant folder is run before the dead code eliminator at , these two together are able to optimize the if statement away altogether. Note that this patch probably won't apply cleanly anymore, since it was written three months ago and the AST code has undergone quite a few changes since then. But if there is interest in applying this patch, I'll gladly update it for the current trunk. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-02-19 02:09 Message: Logged In: YES user_id=80475 This should be compared to the constant folding already added to Py2.5 via the peepholer: dis.dis(compile('x=2+3', '', 'exec')) Also, make sure it doesn't go over the top consuming memory for the likes of: '-' * 100 (None,)*2000 Both of those should not be optimized away at compile-time. Also, be sure not optimize away -0.0. Thet is not the same as +0.0. The distinction is important for branch cuts in cmath. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 01:41 Message: Logged In: YES user_id=1188172 Neal, what do you think of this? ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-06 12:42 Message: Logged In: YES user_id=858364 Sorry, I'm new to the sourceforge patch tracker. The patch should be attached now. ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-11-06 11:10 Message: Logged In: YES user_id=750513 the actual patch is missing... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1346238&group_id=5470 From noreply at sourceforge.net Sun Jul 30 19:04:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 10:04:02 -0700 Subject: [Patches] [ python-Patches-1031213 ] Patch for bug #780725 Message-ID: Patches item #1031213, was opened at 2004-09-20 06:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None >Priority: 6 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Neal Norwitz (nnorwitz) Summary: Patch for bug #780725 Initial Comment: When SyntaxError occurs and the module contains source encodings definition, current implementation prints error line in UTF8. This patch reverts the line into original encoding for printing. This patch calls some memory-allocation APIs such as PyUnicode_DecodeUTF8. I'm not sure I can (or should) call PyErr_Clear() here if error happened. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-30 10:04 Message: Logged In: YES user_id=33168 Note to self (or anyone interested): remember to look into this. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2006-03-17 23:06 Message: Logged In: YES user_id=463672 Sorry for my laziness. I revised a patch for current trunk. - Use "replace" for recoding source - Reports error with PyErr_Print() - Test case ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2005-10-12 23:38 Message: Logged In: YES user_id=463672 Thanks for your comments. I'll post a revised patch and test case later. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-02 11:08 Message: Logged In: YES user_id=38388 Please use the "replace" error handler when recoding the source line to Unicode - this will reduce the probability of the conversion failing. If you do get an error, it's likely going to be an unknown encoding or less likely a memory problem. Please add some logic to deal with these errors as well - currently you don't call PyError_Clear() or take some other action which may lead to confusing error reports (e.g. error popping up randomly during program execution due to the set error). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 22:45 Message: Logged In: YES user_id=33168 I'm hoping that someone more familiar with unicode could take a look at this. The patch looks ok to me, but I don't know how to test that it works. I'm inclined to accept it, unless I hear otherwise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1031213&group_id=5470 From noreply at sourceforge.net Sun Jul 30 19:33:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Jul 2006 10:33:38 -0700 Subject: [Patches] [ python-Patches-1494140 ] Documentation for new Struct object Message-ID: Patches item #1494140, was opened at 2006-05-24 18:26 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation for new Struct object Initial Comment: The performance enhancements to the struct module (patch #1493701) are implemented by having a Struct object, which is a compiled structure. This text file documents these new struct objects. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-07-31 02:33 Message: Logged In: YES user_id=671362 > Does this patch still need to be updated for pack_to() I suppose so and hence updated my patch. (1) document pack_into(pack_to is renamed to pack_into). (2) document pack_into/pack_from as module functions too(just like re module) As for the function name change, I've already updated "what's new in 2.5" in r50985. I guess the patch is ready to be applied. Reviews are appreciated. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-30 04:28 Message: Logged In: YES user_id=11375 Does this patch still need to be updated for pack_to(), or can it just be applied? ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2006-07-11 02:26 Message: Logged In: YES user_id=671362 Patch for the TeX style doc. Bob, can you work on updating the main section right after 2.5 b2? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-26 22:05 Message: Logged In: YES user_id=139309 We're going to need to revise this patch some more to document the new pack_to function (for Martin Blais' hotbuf work) Additionally we'll probably also want to revise the main struct documentation to talk about bounds checking and avoiding the creation of long objects. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 23:32 Message: Logged In: YES user_id=139309 That's clearly a typo. I've attached a new version of the patch that removes those two letters. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-05-25 06:03 Message: Logged In: YES user_id=764593 Shouldn't self.size be the number of bytes required to *pack * the structure? The number required to *unpack* seems like it ought to include tuple overhead and such... ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-25 00:35 Message: Logged In: YES user_id=139309 New patch attached, fixed unpack documentation, added unpack_from method. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-05-24 23:54 Message: Logged In: YES user_id=139309 Hold up on this patch, I need to revise it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1494140&group_id=5470 From noreply at sourceforge.net Mon Jul 31 18:48:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 09:48:01 -0700 Subject: [Patches] [ python-Patches-1531859 ] Tracing and profiling functions can cause hangs in threads Message-ID: Patches item #1531859, was opened at 2006-07-31 16:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: Tracing and profiling functions can cause hangs in threads Initial Comment: Attached is a patch (with test case) that fixes a problem when a tracing function or a profiling function for a thread references a thread ID, causing it to hang. Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1531859&group_id=5470 From noreply at sourceforge.net Mon Jul 31 20:13:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 11:13:34 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Mon Jul 31 20:35:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 11:35:16 -0700 Subject: [Patches] [ python-Patches-1528167 ] Expose case-insensitivity of string.Template Message-ID: Patches item #1528167, was opened at 2006-07-25 01:15 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Chad Whitacre (whit537) Assigned to: Nobody/Anonymous (nobody) Summary: Expose case-insensitivity of string.Template Initial Comment: Python's $-style templating is wired for optional case-insensitivity under the hood, but doesn't expose this via the API. The attached patch (against trunk/ r50813) adds a new optional argument to turn this behavior on, and includes doc and tests. ---------------------------------------------------------------------- >Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:35 Message: Logged In: YES user_id=340931 (BTW, new patch is against trunk/ r51008) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 14:13 Message: Logged In: YES user_id=340931 I've replaced the patch with one that polishes off a few bugs and ambiguities, with accompanying tests and doc. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=340931 Warning: I've discovered that I introduced a bug. New patch forthcoming. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1528167&group_id=5470 From noreply at sourceforge.net Mon Jul 31 22:23:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 13:23:09 -0700 Subject: [Patches] [ python-Patches-1520905 ] Don't produce core file in test_subprocess.py Message-ID: Patches item #1520905, was opened at 2006-07-11 21:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) >Assigned to: A.M. Kuchling (akuchling) Summary: Don't produce core file in test_subprocess.py Initial Comment: The test_run_abort() testcase in test_subprocess.py produces a core file on Unix systems, even though the test is successful. This can be confusing or alarming to someone who runs 'make test' and then finds that the Python interpreter apparently crashed. Tested on Red Hat Linux 9 on x86. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-07-31 16:23 Message: Logged In: YES user_id=11375 >From reading the patch, the fix looks good. Do you have commit privileges, or do I need to check in the change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 From noreply at sourceforge.net Mon Jul 31 22:23:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 13:23:59 -0700 Subject: [Patches] [ python-Patches-1514543 ] mailbox (Maildir): avoid losing messages on name clash Message-ID: Patches item #1514543, was opened at 2006-06-29 14:26 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None >Priority: 6 Submitted By: David Watson (baikie) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (Maildir): avoid losing messages on name clash Initial Comment: The Maildir specification says that messages should be moved into the "new" directory using link()/unlink(), not rename(). This isn't for compatibility with ancient Unixes, but to avoid overwriting an existing message if the "unique" name turns out not to be unique after all. (In the current implementation this can happen if the system clock only has whole-second resolution and deliveries are being done in subprocesses, or the clock has been adjusted backwards, or two machines have the same hostname.) Similarly, the file in "tmp" should be created O_EXCL. This patch implements these requirements, falling back to rename() if link() is unavailable (where on Windows at least, it's supposed to fail if the destination exists), and raising ExternalClashError when the link/rename fails due to the name already being taken in "new". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514543&group_id=5470 From noreply at sourceforge.net Mon Jul 31 22:26:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 13:26:44 -0700 Subject: [Patches] [ python-Patches-1514544 ] mailbox: use fsync() to ensure data is really on disk Message-ID: Patches item #1514544, was opened at 2006-06-29 14:27 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: use fsync() to ensure data is really on disk Initial Comment: The mailbox module currently does nothing to ensure messages/indexes are physically on disk when the flush() method returns or message files are closed. This patch adds functions _sync_flush and _sync_close to flush and fsync() a file object, and in the latter case close it afterwards. _sync_close is then used where needed throughout the code. (For various reasons the current implementation only ever requires a sync immediately before closing a file, but _sync_flush is provided for future use.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1514544&group_id=5470 From noreply at sourceforge.net Mon Jul 31 22:35:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 13:35:59 -0700 Subject: [Patches] [ python-Patches-1520905 ] Don't produce core file in test_subprocess.py Message-ID: Patches item #1520905, was opened at 2006-07-12 01:18 Message generated for change (Comment added) made by dgreiman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tests Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: A.M. Kuchling (akuchling) Summary: Don't produce core file in test_subprocess.py Initial Comment: The test_run_abort() testcase in test_subprocess.py produces a core file on Unix systems, even though the test is successful. This can be confusing or alarming to someone who runs 'make test' and then finds that the Python interpreter apparently crashed. Tested on Red Hat Linux 9 on x86. ---------------------------------------------------------------------- >Comment By: Douglas Greiman (dgreiman) Date: 2006-07-31 20:35 Message: Logged In: YES user_id=1553997 No, I don't have commit privileges. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-31 20:23 Message: Logged In: YES user_id=11375 >From reading the patch, the fix looks good. Do you have commit privileges, or do I need to check in the change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520905&group_id=5470 From noreply at sourceforge.net Mon Jul 31 22:53:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 13:53:29 -0700 Subject: [Patches] [ python-Patches-1524825 ] ConfigParser: accept leading whitespace on options+comments Message-ID: Patches item #1524825, was opened at 2006-07-18 17:17 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524825&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ken Lalonde (kenlalonde) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser: accept leading whitespace on options+comments Initial Comment: ConfigParser considers leading white space before options and comments to be syntax errors, which is a bit harsh, and limits the utility of the module when parsing files originally written for other programs, such as Samba's smb.conf. The attached patch ignores leading white space on options, and skips comments with leading w.s. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 16:53 Message: Logged In: YES user_id=340931 Thanks for the patch Ken! This change sounds reasonable and low-risk. However, some patch suggestions: 1. Diff against HEAD of trunk/ from svn, not your platform's python installation 2. Add some tests in Lib/test/test_cfgparser.py (this will be in a source distribution from svn, but not in your platform's binary distribution) 3. Update the doc in Doc/lib/libcfgparser.tex (again, this will be in a source dist) FWIW, these are mentioned in the (admittedly somewhat obtuse) patch guidelines: http://www.python.org/dev/patches/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1524825&group_id=5470 From noreply at sourceforge.net Mon Jul 31 23:13:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 14:13:21 -0700 Subject: [Patches] [ python-Patches-1520879 ] make install change: Allow $DESTDIR to be relative Message-ID: Patches item #1520879, was opened at 2006-07-11 19:56 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520879&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Greiman (dgreiman) Assigned to: Nobody/Anonymous (nobody) Summary: make install change: Allow $DESTDIR to be relative Initial Comment: This patch allows the $DESTDIR variable used in 'make install' to be a relative path. It also avoids constructing filenames starting with double slashes ('//') when DESTDIR is an absolute path. Tested on RedHat 9.0 Linux on x86. ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-07-31 17:13 Message: Logged In: YES user_id=340931 I'd also like to see the argument to 'configure --prefix=' also be relative. Could this patch be expanded in that direction? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520879&group_id=5470