From noreply at sourceforge.net Tue Nov 1 04:46:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 19:46:21 -0800 Subject: [ python-Bugs-1344508 ] UNIX mmap leaks file descriptors Message-ID: Bugs item #1344508, was opened at 2005-11-01 03:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1344508&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Erwin S. Andreasen (drylock) Assigned to: Nobody/Anonymous (nobody) Summary: UNIX mmap leaks file descriptors Initial Comment: The commit from 2.49 to 2.50 in Modules/mmapmodule.c has made mmap under UNIX leak a file descriptor: - m_obj->fd = fd; + m_obj->fd = dup(fd); The FD given is dup'ed in order to allow ftruncation later, but no close of it is done in dealloc/close. A test case attached, using lsof after some mmaps/unmaps to show leak. Version: Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1344508&group_id=5470 From noreply at sourceforge.net Tue Nov 1 14:16:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 05:16:16 -0800 Subject: [ python-Bugs-1289136 ] distutils extension library path bug on cygwin Message-ID: Bugs item #1289136, was opened at 2005-09-12 14:04 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Whitley (jwhitley) Assigned to: Nobody/Anonymous (nobody) Summary: distutils extension library path bug on cygwin Initial Comment: A while back I reported a problem on the Cygwin mailing list where all python extension packages would fail "python setup.py install" at the link step due to a mangled lib dir (-L) option. distutils was producing a link line with "-L.", instead of the desired "-L/usr/lib/python2.4/config". I've finally rooted out the cause of this problem. The relevant code is the if-block starting at line 188 of: /usr/lib/python2.4/distutils/command/build_ext.py I've reproduced that block here for clarity of discussion (indentation truncated for redability) if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') The test "string.find(...) != -1" attempts to test whether "/usr" appears in the full executable name. This incorrectly fails in the case that /bin is in the user's path before /usr/bin. (i.e. string.find("/bin/python","/usr") == -1) Note that a vagary of Cygwin is that /usr/bin is a Cygwin mount to /bin. The user-side workaround is to ensure that /usr/bin appears in your path before /bin. It looks like a new and improved Cygwin special case test is needed to fix this problem; I'm not sure offhand what the best case would be. Perhaps an outright test as follows would work: sys.executable.startswith(sys.exec_prefix) or sys.executable.startswith(os.sep+"bin") ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-11-01 04:16 Message: Logged In: YES user_id=86216 I agree with John -- distutils needs to know whether it is building Python itself or just a extension module. I can think of the following ways to this accomplish this: 1. Check sys.path 2. Use some of the checks in Modules/getpath.c Any thoughts about which approach would be better? Any other ideas? ---------------------------------------------------------------------- Comment By: John Whitley (jwhitley) Date: 2005-10-28 09:29 Message: Logged In: YES user_id=649097 Jason is correct that readlink won't help. On Cygwin installations, /bin and /usr/bin are not symlinks, they're aliases in Cygwin's default mount system. (C:\cygwin on / (root) and C:\cygwin\bin on /usr/bin) The Python 2.4.1 docs says: "readlink(path) Return a string representing the path to which the symbolic link points." For good measure, I confirmed that readlink doesn't give the desired results. The bigger problem that I see is that this code is using hard-coded automagic path detection to figure out something that it should be told explicitly. That is, "are we in the special case of building python's own libraries/extensions." (versus trying to install an extension to an existing python installation.) To illustrate the problem, both my proposal and the original code are broken for trying to build python in /usr/local. (e.g. build under /usr/local/src -- thinks it's an install not a build due to "/usr" prefix...) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-10-28 04:21 Message: Logged In: YES user_id=86216 Unfortunately, I don't think readlink will help. I was thinking of comparing inodes, but AFAICT inodes under Cygwin are not guaranteed to be unique for all platforms and filesystems. So, maybe John's check is the only reliable option? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 18:47 Message: Logged In: YES user_id=33168 What does os.readlink(sys.executable) return? Maybe that will help you find the true canonical name? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-09-16 04:04 Message: Logged In: YES user_id=86216 John, Thanks for the excellent analysis! All, Unfortunately, I'm not sure what is the best way to solve this problem. Does anyone have any suggestions? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 From noreply at sourceforge.net Tue Nov 1 21:50:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 12:50:38 -0800 Subject: [ python-Bugs-1345263 ] colorsys tests, bug in frange Message-ID: Bugs item #1345263, was opened at 2005-11-01 21:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: colorsys tests, bug in frange Initial Comment: The frange() function in Lib/test/test_colorsys.py generates incorrect ranges, making the tests less comprehensive than expected. The following patch fixes the problem: $ svn diff Lib/test/test_colorsys.py Index: Lib/test/test_colorsys.py ================================================= ================== --- Lib/test/test_colorsys.py (revision 41365) +++ Lib/test/test_colorsys.py (working copy) @@ -4,7 +4,7 @@ def frange(start, stop, step): while start <= stop: yield start - start += stop + start += step class ColorsysTest(unittest.TestCase): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 From noreply at sourceforge.net Tue Nov 1 22:37:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 13:37:22 -0800 Subject: [ python-Bugs-1345313 ] Python 2.4 and 2.3.5 won't build on OpenBSD 3.7 Message-ID: Bugs item #1345313, was opened at 2005-11-01 13:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan (catdude) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 and 2.3.5 won't build on OpenBSD 3.7 Initial Comment: Both Python 2.3.5 and 2.4 fail to build, and both report the same errors. The output of configure and of make are attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470 From noreply at sourceforge.net Tue Nov 1 23:42:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 14:42:32 -0800 Subject: [ python-Bugs-1170311 ] zipfile UnicodeDecodeError Message-ID: Bugs item #1170311, was opened at 2005-03-24 21:51 Message generated for change (Comment added) made by smigyull You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: adam davis (adamx97) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile UnicodeDecodeError Initial Comment: I think this is the same as # 705295, which may have been prematurely closed. I think the error is dependent on the data or time. File "C:\Python24\lib\zipfile.py", line 166, in FileHeader return header + self.filename + self.extra UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 10: ordinal not in range(128) The header is packed like this: header = struct.pack(structFileHeader, stringFileHeader, self.extract_version, self.reserved, self.flag_bits, self.compress_type, dostime, dosdate, CRC, compress_size, file_size, len(self.filename), len(self.extra)) the header is: [Dbg]>>> header 'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00' and here are the parts that made it up: [Dbg]>>> structFileHeader, stringFileHeader, self.extract_version, self.reserved, self.flag_bits,self.compress_type, dostime, dosdate, CRC, compress_size, file_size, len(self.filename), len(self.extra) ('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472, 12920, 0, 0, 0, 45, 0) here's the pieces of the ---------------------------------------------------------------------- Comment By: Jean-Roch Roy (smigyull) Date: 2005-11-01 17:42 Message: Logged In: YES user_id=1371642 Python 2.4/WinXPSP2 I'm able to reproduce this bug. Create an arbitrary file named "Test.bin" having a time stamp of 2005-11-01 16:15:32. Then run this code: import zipfile zipFile = zipfile.ZipFile("Test.zip", "w", zipfile.ZIP_DEFLATED) zipFile.write(u"Test.bin") You should see the aforementionned traceback. The problem occurs when 1. pack() returns a string with some characters > 128 (depends on time stamp); and 2. write() is called with a unicode parameter (instead of a str parameter). ---------------------------------------------------------------------- Comment By: adam davis (adamx97) Date: 2005-03-30 22:51 Message: Logged In: YES user_id=175166 The "here's the pieces of the" was an accident, you can ignore it. My filename was pure ascii, something like "myemail at test.com.crt" It seems to me the problem is that the header isn't decodable. 0xd0 is 208, which is > 128. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-03-30 14:27 Message: Logged In: YES user_id=38388 The problem is not the data in the file, but the fact that your filename is probably a Unicode object which fails to concatenate with the header (which clearly isn't ASCII :-). I have no idea whether ZIP files support anything other than ASCII filenames. If you have a reference, please let us know. If your filename only contains ASCII characters, you should be able to open the file correctly by first encoding the filename to ASCII: filename.encode('ascii'). Perhaps zipfile.py should do that for you ?! ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-03-30 13:39 Message: Logged In: YES user_id=593130 Your report ends with 'here's the pieces of the'. Was something cut off? If you meant to attach a file, try again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470 From noreply at sourceforge.net Wed Nov 2 06:46:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 21:46:40 -0800 Subject: [ python-Bugs-1344508 ] UNIX mmap leaks file descriptors Message-ID: Bugs item #1344508, was opened at 2005-10-31 19:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1344508&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erwin S. Andreasen (drylock) >Assigned to: Neal Norwitz (nnorwitz) Summary: UNIX mmap leaks file descriptors Initial Comment: The commit from 2.49 to 2.50 in Modules/mmapmodule.c has made mmap under UNIX leak a file descriptor: - m_obj->fd = fd; + m_obj->fd = dup(fd); The FD given is dup'ed in order to allow ftruncation later, but no close of it is done in dealloc/close. A test case attached, using lsof after some mmaps/unmaps to show leak. Version: Python 2.4.2 (#2, Sep 29 2005, 00:23:59) [GCC 4.0.2 (Debian 4.0.1-9)] on linux2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-01 21:46 Message: Logged In: YES user_id=33168 Thanks! Committed revision 41366. Committed revision 41367. (cleanup) Committed revision 41368. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1344508&group_id=5470 From noreply at sourceforge.net Wed Nov 2 05:25:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 20:25:52 -0800 Subject: [ python-Bugs-1345263 ] colorsys tests, bug in frange Message-ID: Bugs item #1345263, was opened at 2005-11-01 21:50 Message generated for change (Settings changed) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: colorsys tests, bug in frange Initial Comment: The frange() function in Lib/test/test_colorsys.py generates incorrect ranges, making the tests less comprehensive than expected. The following patch fixes the problem: $ svn diff Lib/test/test_colorsys.py Index: Lib/test/test_colorsys.py ================================================= ================== --- Lib/test/test_colorsys.py (revision 41365) +++ Lib/test/test_colorsys.py (working copy) @@ -4,7 +4,7 @@ def frange(start, stop, step): while start <= stop: yield start - start += stop + start += step class ColorsysTest(unittest.TestCase): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 From noreply at sourceforge.net Wed Nov 2 05:19:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 20:19:17 -0800 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Wed Nov 2 09:42:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 00:42:51 -0800 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by papadopo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 09:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Wed Nov 2 07:02:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 22:02:41 -0800 Subject: [ python-Bugs-1345263 ] colorsys tests, bug in frange Message-ID: Bugs item #1345263, was opened at 2005-11-01 12:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Rune Holm (titanstar) >Assigned to: Neal Norwitz (nnorwitz) Summary: colorsys tests, bug in frange Initial Comment: The frange() function in Lib/test/test_colorsys.py generates incorrect ranges, making the tests less comprehensive than expected. The following patch fixes the problem: $ svn diff Lib/test/test_colorsys.py Index: Lib/test/test_colorsys.py ================================================= ================== --- Lib/test/test_colorsys.py (revision 41365) +++ Lib/test/test_colorsys.py (working copy) @@ -4,7 +4,7 @@ def frange(start, stop, step): while start <= stop: yield start - start += stop + start += step class ColorsysTest(unittest.TestCase): ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-01 22:02 Message: Logged In: YES user_id=33168 Thanks! I have no idea how you spotted that. Committed revision 41369. Committed revision 41370. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 From noreply at sourceforge.net Wed Nov 2 05:10:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 20:10:12 -0800 Subject: [ python-Bugs-1345313 ] Python 2.4 and 2.3.5 won't build on OpenBSD 3.7 Message-ID: Bugs item #1345313, was opened at 2005-11-01 22:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dan (catdude) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.4 and 2.3.5 won't build on OpenBSD 3.7 Initial Comment: Both Python 2.3.5 and 2.4 fail to build, and both report the same errors. The output of configure and of make are attached. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:10 Message: Logged In: YES user_id=21627 Please report this as a bug to the OpenBSD developers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345313&group_id=5470 From noreply at sourceforge.net Wed Nov 2 15:32:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 06:32:38 -0800 Subject: [ python-Bugs-1346026 ] doc typo Message-ID: Bugs item #1346026, was opened at 2005-11-02 14:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346026&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: doc typo Initial Comment: http://docs.python.org/lib/set-objects.html: "because it the one" -> "because it is the one" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346026&group_id=5470 From noreply at sourceforge.net Wed Nov 2 16:24:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 07:24:08 -0800 Subject: [ python-Bugs-1345263 ] colorsys tests, bug in frange Message-ID: Bugs item #1345263, was opened at 2005-11-01 21:50 Message generated for change (Comment added) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Neal Norwitz (nnorwitz) Summary: colorsys tests, bug in frange Initial Comment: The frange() function in Lib/test/test_colorsys.py generates incorrect ranges, making the tests less comprehensive than expected. The following patch fixes the problem: $ svn diff Lib/test/test_colorsys.py Index: Lib/test/test_colorsys.py ================================================= ================== --- Lib/test/test_colorsys.py (revision 41365) +++ Lib/test/test_colorsys.py (working copy) @@ -4,7 +4,7 @@ def frange(start, stop, step): while start <= stop: yield start - start += stop + start += step class ColorsysTest(unittest.TestCase): ---------------------------------------------------------------------- >Comment By: Rune Holm (titanstar) Date: 2005-11-02 16:24 Message: Logged In: YES user_id=858364 Well, I was hacking away on the parser, and accidentally broke the code that emits bytecode for while statements, which incidentally turned the while loop in question into an infinite loop. That tends to make you read the turned-buggy code extra carefully :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-02 07:02 Message: Logged In: YES user_id=33168 Thanks! I have no idea how you spotted that. Committed revision 41369. Committed revision 41370. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1345263&group_id=5470 From noreply at sourceforge.net Wed Nov 2 18:07:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 09:07:40 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 18:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Wed Nov 2 18:38:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 09:38:37 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 18:07 Message generated for change (Comment added) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- >Comment By: Rune Holm (titanstar) Date: 2005-11-02 18:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Wed Nov 2 19:34:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 10:34:18 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 09:07 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Rune Holm (titanstar) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-02 09:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Wed Nov 2 23:24:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 14:24:29 -0800 Subject: [ python-Bugs-1346395 ] Missing import in documentation Message-ID: Bugs item #1346395, was opened at 2005-11-03 00:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346395&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Aggelos Orfanakos (agorf) Assigned to: Nobody/Anonymous (nobody) Summary: Missing import in documentation Initial Comment: At the bottom of the URL http://docs.python.org/dist/meta-data.html one can find code that is used to make setup.py scripts, using "classifiers" and "download_url", compatible with Python versions prior to 2.2.3. It is using "sys.version", thus, missing the necessary "import sys" statement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346395&group_id=5470 From noreply at sourceforge.net Wed Nov 2 23:30:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 14:30:18 -0800 Subject: [ python-Bugs-1346395 ] Missing import in documentation Message-ID: Bugs item #1346395, was opened at 2005-11-03 00:24 Message generated for change (Settings changed) made by agorf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346395&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None >Priority: 1 Submitted By: Aggelos Orfanakos (agorf) Assigned to: Nobody/Anonymous (nobody) Summary: Missing import in documentation Initial Comment: At the bottom of the URL http://docs.python.org/dist/meta-data.html one can find code that is used to make setup.py scripts, using "classifiers" and "download_url", compatible with Python versions prior to 2.2.3. It is using "sys.version", thus, missing the necessary "import sys" statement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346395&group_id=5470 From noreply at sourceforge.net Thu Nov 3 00:01:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 15:01:28 -0800 Subject: [ python-Bugs-1346395 ] Missing import in documentation Message-ID: Bugs item #1346395, was opened at 2005-11-02 14:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346395&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Aggelos Orfanakos (agorf) Assigned to: Nobody/Anonymous (nobody) Summary: Missing import in documentation Initial Comment: At the bottom of the URL http://docs.python.org/dist/meta-data.html one can find code that is used to make setup.py scripts, using "classifiers" and "download_url", compatible with Python versions prior to 2.2.3. It is using "sys.version", thus, missing the necessary "import sys" statement. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-02 15:01 Message: Logged In: YES user_id=357491 rev. 41374 for the trunk and rev. #41375 for 2.4 have a fix. Thanks, Aggelos. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346395&group_id=5470 From noreply at sourceforge.net Thu Nov 3 00:05:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 15:05:14 -0800 Subject: [ python-Bugs-1340337 ] time.strptime() with bad % code throws bad exception Message-ID: Bugs item #1340337, was opened at 2005-10-27 23:48 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1340337&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve R. Hastings (steveha) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() with bad % code throws bad exception Initial Comment: I am using Python 2.4.2, the latest version currently available for the system I am using, which is Ubuntu 5.10 for x86. I was calling the time.strptime() function, and I had accidentally typed an extra % symbol in the time format string. If you do this you get a baffling message in the traceback. The deepest frame of the traceback looks like this: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '-' This means that I accidentally put "%-" in my format string. What happens if I accidentally put "% " in my format string? This: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '\' It turns out that spaces in the format string are replaced by r'\s*' by the time the exception happens. It really freaked me out to see Python complaining about a backslash, when I hadn't put a backslash into my format string. I propose that this library call should be re-written to catch the exception, and then throw a more sensible exception, including a statement like: "unknown % code in format string". In a perfect world this would be done in such a way that the last frame appearing in the traceback would be for the call to time.strptime(), and not show any lines from the guts of time.strptime() about regular expression compiling. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-02 15:05 Message: Logged In: YES user_id=357491 Rev. 41376 has the fix in the trunk. I am not going to backport since it is a semantic change. Thanks, Steve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1340337&group_id=5470 From noreply at sourceforge.net Thu Nov 3 02:54:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 17:54:06 -0800 Subject: [ python-Bugs-1346533 ] selectmodule.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346533, was opened at 2005-11-03 12:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Luke (luked) Assigned to: Nobody/Anonymous (nobody) Summary: selectmodule.c calls PyInt_AsLong without error checking Initial Comment: selectmodule.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.2 (#1, Nov 3 2005, 12:41:57) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import select >>> p = select.poll() >>> p.register(0) # stdin >>> p.poll(0x100000000) [(0, 4)] >>> 2 + 3 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346533&group_id=5470 From noreply at sourceforge.net Thu Nov 3 03:34:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 18:34:15 -0800 Subject: [ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346547, was opened at 2005-11-03 13:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Luke (luked) Assigned to: Nobody/Anonymous (nobody) Summary: _subprocess.c calls PyInt_AsLong without error checking Initial Comment: _subprocess.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> si = subprocess.STARTUPINFO() >>> si.wShowWindow = 2**65 >>> obj = subprocess.Popen('notepad.exe', startupinfo=si) >>> 1+1 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 From noreply at sourceforge.net Thu Nov 3 05:39:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 20:39:51 -0800 Subject: [ python-Bugs-1346026 ] doc typo Message-ID: Bugs item #1346026, was opened at 2005-11-02 06:32 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346026&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Keith Briggs (kbriggs) >Assigned to: Neal Norwitz (nnorwitz) Summary: doc typo Initial Comment: http://docs.python.org/lib/set-objects.html: "because it the one" -> "because it is the one" ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-02 20:39 Message: Logged In: YES user_id=33168 Thanks. Committed revision 41385. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346026&group_id=5470 From noreply at sourceforge.net Thu Nov 3 05:56:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 20:56:15 -0800 Subject: [ python-Bugs-417833 ] pydoc HTTP reload failure Message-ID: Bugs item #417833, was opened at 2001-04-21 07:10 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-02 20:56 Message: Logged In: YES user_id=45338 I've been looking into this problem, and unfortunately, the solution isn't as straightforward as rturpin's patch. The (sorry, undocumented) original reason that safeimport uses "del sys.modules[path]" instead of simply calling reload() is that reload() leaves old variables around in the module. For example, if the module initially contains "x = 3", it's loaded, the source file is changed to "y = 3", and then reloaded, the resulting loaded module will contain both x and y. I'm working on a way to safely clear the module without re-triggering the problem. ---------------------------------------------------------------------- Comment By: Russell Turpin (rturpin) Date: 2005-10-31 09:16 Message: Logged In: YES user_id=670280 There's a similar bug in Python 2.4. It causes the __import__ function to throw an AttributeError exception during safeimport(). I've patched our local copy of pydoc to fix this. The patch is to the safeimport() function. The patched lines are: # This keeps __import__ from throwing an exception on reloads. # del sys.modules[path] # This is sole original line module = sys.modules[path] # Added this line try: # Added this line reload(module) # Added this line except: # Added this line module = None # Added this line return module # Added this line This replaces the line: del sys.modules[path] ---------------------------------------------------------------------- Comment By: Eddie Parker (eparker) Date: 2004-08-31 14:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 08:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\Python21\Lib\pydoc.py", line 223, in safeimport module = __import__(path) File "c:\python21\lib\DemonstratePydocBug\TryThis.py", line 9, in ? Target = DemonstratePydocBug.Target AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' In the interpreter, everything's fine with both techniques for getting Target: C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.Target >>> Target = DemonstratePydocBug.Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:58 Message: Logged In: YES user_id=59803 WHOA. Belay that. I screwed up trying to run too many tests in a row without shutting down the interpreter. Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> DemonstratePydocBug.Target Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' >>> import DemonstratePydocBug.Target >>> DemonstratePydocBug.Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target FILE c:\python21\lib\demonstratepydocbug\target.py DESCRIPTION Target: module to help demonstrate the pydoc reload bug. See the docstring in __init__.py for full details. Reloading the description of this module in pydoc should work, but that's hardly unusual because it doesn't import *anything*. Try ReloadWorks and ReloadFails, instead. DATA __file__ = r'c:\python21 \lib\DemonstratePydocBug\Target.pyc' __name__ = 'DemonstratePydocBug.Target' >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target ... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:55 Message: Logged In: YES user_id=59803 >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) ... we get good stuff... >>> print DemonstratePydocBug.ReloadFails2 <module 'DemonstratePydocBug.ReloadFails2' from 'DemonstratePydocBug\ReloadFails2.py'> >>> pydoc.help(DemonstratePydocBug.ReloadFails2) ... we get good stuff... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:43 Message: Logged In: YES user_id=59803 I've found another demonstration case. Noting that from package import module gives you a variable called 'module', whilst import package.module gives you a variable called 'package', I thought I'd try out another import syntax which wouldn't break code that was trying out the first option: import package.module as module This also works under the Python 2.1 interpreter but breaks pydoc 1.38. I've attached an updated demonstration tarchive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 From noreply at sourceforge.net Thu Nov 3 06:11:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 21:11:46 -0800 Subject: [ python-Bugs-1346533 ] selectmodule.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346533, was opened at 2005-11-02 17:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346533&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Luke (luked) >Assigned to: Neal Norwitz (nnorwitz) Summary: selectmodule.c calls PyInt_AsLong without error checking Initial Comment: selectmodule.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.2 (#1, Nov 3 2005, 12:41:57) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import select >>> p = select.poll() >>> p.register(0) # stdin >>> p.poll(0x100000000) [(0, 4)] >>> 2 + 3 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-02 21:11 Message: Logged In: YES user_id=33168 Thanks! Committed revision 41388, 41389. (head) Committed revision 41390. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346533&group_id=5470 From noreply at sourceforge.net Thu Nov 3 06:20:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 21:20:23 -0800 Subject: [ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346547, was opened at 2005-11-02 18:34 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Luke (luked) Assigned to: Nobody/Anonymous (nobody) Summary: _subprocess.c calls PyInt_AsLong without error checking Initial Comment: _subprocess.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> si = subprocess.STARTUPINFO() >>> si.wShowWindow = 2**65 >>> obj = subprocess.Popen('notepad.exe', startupinfo=si) >>> 1+1 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-02 21:20 Message: Logged In: YES user_id=33168 This code (for startupinfo) is only valid on Windows. The problem seems to be at lines 379 and 380 in PC/_subprocess.c. I'll let someone who can test this one take care of it. The return result from getint() needs to be checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 From noreply at sourceforge.net Thu Nov 3 09:34:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 00:34:57 -0800 Subject: [ python-Bugs-417833 ] pydoc HTTP reload failure Message-ID: Bugs item #417833, was opened at 2001-04-21 07:10 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-03 00:34 Message: Logged In: YES user_id=45338 I've uploaded a fixed version of pydoc.py. Please give it a try and let me know if it works for you. Thanks. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-02 20:56 Message: Logged In: YES user_id=45338 I've been looking into this problem, and unfortunately, the solution isn't as straightforward as rturpin's patch. The (sorry, undocumented) original reason that safeimport uses "del sys.modules[path]" instead of simply calling reload() is that reload() leaves old variables around in the module. For example, if the module initially contains "x = 3", it's loaded, the source file is changed to "y = 3", and then reloaded, the resulting loaded module will contain both x and y. I'm working on a way to safely clear the module without re-triggering the problem. ---------------------------------------------------------------------- Comment By: Russell Turpin (rturpin) Date: 2005-10-31 09:16 Message: Logged In: YES user_id=670280 There's a similar bug in Python 2.4. It causes the __import__ function to throw an AttributeError exception during safeimport(). I've patched our local copy of pydoc to fix this. The patch is to the safeimport() function. The patched lines are: # This keeps __import__ from throwing an exception on reloads. # del sys.modules[path] # This is sole original line module = sys.modules[path] # Added this line try: # Added this line reload(module) # Added this line except: # Added this line module = None # Added this line return module # Added this line This replaces the line: del sys.modules[path] ---------------------------------------------------------------------- Comment By: Eddie Parker (eparker) Date: 2004-08-31 14:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 08:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\Python21\Lib\pydoc.py", line 223, in safeimport module = __import__(path) File "c:\python21\lib\DemonstratePydocBug\TryThis.py", line 9, in ? Target = DemonstratePydocBug.Target AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' In the interpreter, everything's fine with both techniques for getting Target: C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.Target >>> Target = DemonstratePydocBug.Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:58 Message: Logged In: YES user_id=59803 WHOA. Belay that. I screwed up trying to run too many tests in a row without shutting down the interpreter. Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> DemonstratePydocBug.Target Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' >>> import DemonstratePydocBug.Target >>> DemonstratePydocBug.Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target FILE c:\python21\lib\demonstratepydocbug\target.py DESCRIPTION Target: module to help demonstrate the pydoc reload bug. See the docstring in __init__.py for full details. Reloading the description of this module in pydoc should work, but that's hardly unusual because it doesn't import *anything*. Try ReloadWorks and ReloadFails, instead. DATA __file__ = r'c:\python21 \lib\DemonstratePydocBug\Target.pyc' __name__ = 'DemonstratePydocBug.Target' >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target ... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:55 Message: Logged In: YES user_id=59803 >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) ... we get good stuff... >>> print DemonstratePydocBug.ReloadFails2 <module 'DemonstratePydocBug.ReloadFails2' from 'DemonstratePydocBug\ReloadFails2.py'> >>> pydoc.help(DemonstratePydocBug.ReloadFails2) ... we get good stuff... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:43 Message: Logged In: YES user_id=59803 I've found another demonstration case. Noting that from package import module gives you a variable called 'module', whilst import package.module gives you a variable called 'package', I thought I'd try out another import syntax which wouldn't break code that was trying out the first option: import package.module as module This also works under the Python 2.1 interpreter but breaks pydoc 1.38. I've attached an updated demonstration tarchive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 From noreply at sourceforge.net Thu Nov 3 10:01:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 01:01:47 -0800 Subject: [ python-Bugs-651124 ] pydoc ignores $PAGER if TERM=='dumb' Message-ID: Bugs item #651124, was opened at 2002-12-09 14:00 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Ka-Ping Yee (ping) Summary: pydoc ignores $PAGER if TERM=='dumb' Initial Comment: bug: pydoc ignores $PAGER environment variable if TERM=='dumb' symptom: when using pydoc as a keyword helper system (set keywordprg) pydoc scrolls all over its contents without paging, since gvim sets its terminal type to 'dumb' for shell escape. Fix: patch included. function getpager() rearranged. Inyeol Lee ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-03 01:01 Message: Logged In: YES user_id=45338 Accepted. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 05:12 Message: Logged In: YES user_id=33168 Ping, do you agree with this patch? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2002-12-09 14:06 Message: Logged In: YES user_id=595280 description on symptom above is for gvim. it was not clear there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651124&group_id=5470 From noreply at sourceforge.net Thu Nov 3 11:33:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 02:33:21 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 17:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Rune Holm (titanstar) >Assigned to: Michael Hudson (mwh) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-11-03 10:33 Message: Logged In: YES user_id=6656 Uh, yeah, completely my fault -- don't know what I was thinking. Should be easy to fix, I'll have a patch for you soon. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-02 17:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Thu Nov 3 11:56:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 02:56:24 -0800 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by papadopo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 11:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python-2.4.2/include/python2.4 -c foo.cpp $ Same Solaris 8 workstation, no OS updates, same GCC and same Sun compilers. Oh well... I think it's still a good idea to include before , , , and . But that's your call, I don't mind as long as I'm able to build Python. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 09:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Thu Nov 3 13:24:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 04:24:29 -0800 Subject: [ python-Bugs-1346874 ] httplib simply ignores CONTINUE Message-ID: Bugs item #1346874, was opened at 2005-11-03 13:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Looijmans (cdwave) Assigned to: Nobody/Anonymous (nobody) Summary: httplib simply ignores CONTINUE Initial Comment: I bumped into this code in httplib.py HTTPConnection, begin(): # read until we get a non-100 response while True: version, status, reason = self._read_status() if status != CONTINUE: break # skip the header from the 100 response while True: skip = self.fp.readline().strip() if not skip: break if self.debuglevel > 0: print "header:", skip This basically silently eats any 100-continue response that the server may send to us. This is not according to the spec - the client should WAIT for the 100-continue, and then post the data. Because of this code snippet, it is impossible for a client to wait for a 100-continue response, since it is silently eaten by this code. A correct implementation would be: - Check the outgoing headers for "Expect: 100-continue" - If that is present, set an "expectcontinue" flag. - If the client tries to send data to the connection, or if the data member was set in the request, wait for the server to send the 100 response BEFORE sending out any data at all, if the flag is set. - If the server fails to send it, the connection will eventually time out. I'd be happy to provide an implementation myself, as it doesn't seem hard to implement and would really help my project. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470 From noreply at sourceforge.net Thu Nov 3 19:47:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 10:47:37 -0800 Subject: [ python-Bugs-754449 ] Exceptions when a thread exits Message-ID: Bugs item #754449, was opened at 2003-06-14 05:32 Message generated for change (Comment added) made by justincjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable jgoerzen at christoph:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive LocalExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive RemoteExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- Comment By: Justin Johnson (justincjohnson) Date: 2005-11-03 12:47 Message: Logged In: YES user_id=1049561 I'm seeing this problem still in Python 2.4.1 on Windows. Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 C:\src\Twisted>trial -r iocp twisted.test.test_iutils Using twisted.internet.iocpreactor reactor Running 6 tests. twisted.test.test_iutils UtilsTestCase testOutput ... ? [32;1m[OK]?[0m testOutputAndValue ... ? [32;1m[OK]?[0m testOutputSignal ... ? [32;1m[OK]?[0m testOutputWithErrorCollected ... ? [32;1m[OK]?[0m testOutputWithErrorIgnored ... ? [32;1m[OK]?[0m testValue ... ? [32;1m[OK]?[0m ------------------------------------------------------------------------------- Ran 6 tests in 1.513s PASSED (successes=6) Exception in thread iocpreactor.process_waiter.ProcessWaiter.waitForProcessExi t pid=2156 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap File "C:\Python24\lib\threading.py", line 422, in run File "C:\src\Twisted\twisted\internet\iocpreactor\process_wait er.py", line 165, in doWaitForProcessExit exceptions.TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-17 11:33 Message: Logged In: YES user_id=357491 Python 2.2 is no longer actively maintained, so I wouldn't count on the fix being backported. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2004-09-17 02:15 Message: Logged In: YES user_id=769182 I have this bug on Python 2.2.3 : occasionally getting a very similar stack when my daemon thread exits. I don't get the error for non-daemon threads. My problem seems pretty similar to carlosayam's problem, described in June. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-03 15:01 Message: Logged In: YES user_id=357491 For 2.3, rev.1.38.6.1 has the required fixes (required also backporting rev. 1.41 from HEAD). Thanks to everyone who tried to help with this nasty thing. And a special thanks to the Mnet guys for giving me a way to reproduce this bug consistently. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 22:57 Message: Logged In: YES user_id=357491 Fixed in 2.4 thanks to rev. 1.42 to Lib/threading. Don't know if this will be backported to 2.3 . Possible, but need someone else to agree first. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-03 01:05 Message: Logged In: YES user_id=990060 I don't understand one thing: how can python shut down itself and, at the same time, keep a python code running in a daemonised thread? or is that thread running in a different "threaded" python byte-code interpreter? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-03 00:25 Message: Logged In: YES user_id=31435 Brett, FYI, a daemon thread differs from a non-daemon thread in only one respect: Python shuts down when only daemon threads remain. It waits for non-daemon threads to finish. So a daemon thread can keep running after the interpreter has torn itself down completely. For that reason, problems in daemon threads doing non-trivial things are almost guaranteed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-03 00:08 Message: Logged In: YES user_id=357491 Yep, that is how Python cleans up a module; sets everything in the module to None and then removes it from sys.modules . As for your case, I don't know enough about daemonized threads. My patch for this only tries to let the exception make it to the top without 'threading' hiding the exception by causing its own exception from interpreter shutdown. In other words I don't know if this is a related issue or not. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-02 22:01 Message: Logged In: YES user_id=990060 bcannon said on 2004-02-17 >> Does anyone know how to cause this error in isolation? I'm getting the same error when I start a new thread, daemonise it and the thread goes into a very slow database operation (loading a large object); meanwhile the main thread starts a GUI; then I close the window, exiting the main loop and the python interpreter ends (or tries to end.) In relation to bcannon comment on how to reproduce the error (setting all variables to None in the module), my guess is that while exiting, the python interpreter is somehow freeing all variables in the module (cleaning the module or something), but the module is still running and that raises the error... is this possible? Note: if the thread is not daemonised, the problem desapears but the script (the python interpreter) takes a while to finish. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 23:36 Message: Logged In: YES user_id=357491 How to reproduce the bug: * Follow the instructions at http://mnetproject.org/repos/ on how to get a copy of the in-dev version of mnet (I used the instructions for using wget and it worked fine). * Run ``python setup.py``. Do realize that this app will download other Python code (crypto stuff mostly) to finish its install. Takes up about 54 MB on my machine after it is compiled. * Run ``python setup.py test -a``. This executes the testing suite. The bug manifests itself after the testing suite finishes execution. This will consistently cause the bug every time. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 13:45 Message: Logged In: YES user_id=357491 Discovered this is not fixed after all (previous fix didn't go far enough; still needed, though). Patch 954922 is the second attempt to fix this. This time, though, I had code that could trigger the problem reliably and thus this should be the proper, and final, fix. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 16:36 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 16:32 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-02 22:29 Message: Logged In: YES user_id=357491 To force this error I inserted code to set all attributes of the threading module to None and then throw and exception. After commenting out the two calls to currentThread in _Condition the thrown exception to trigger the problem propogated to the top correctly. I did have the clean-up function give out since I set *everything* to None, but it doesn't look like a normal issue as shown in the exception traceback in the OP. I don't think it is an issue. So it seems commenting the two calls to currentThread in _Condition solves the problem. But since this is threading code and the comment explicitly states it is for the side-effect I am going to try to get a second opinion. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-16 22:59 Message: Logged In: YES user_id=357491 Does anyone know how to cause this error in isolation? I have tried a bunch of different ways but cannot cause an exception to be raised at the correct point in Threading.__bootstrap() to lead to self.__stop() to be called while the interpreter is tearing itself down. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-09 19:18 Message: Logged In: YES user_id=357491 After staring at the code, I am not even sure if the calls for its side- effect are needed. If you call currentThread(), it either returns a value from _active which is a dict of running Thread instances indexed by thread idents, or a new _DummyThread instance that inserts itself into _active. Now the two calls in the _Condition class are purely for this possible side-effect. And yet at no point is anything from _active, through currentThread or direct access, even touched by a _Condition method. The only chance this might be an issue is if a _Condition instance uses an RLock instance for its locking, which is the default behavior. But this still makes the side-effect need useless. RLocks will call currentThread on their own and since this is all in the same thread the result won't change. And in this specific case of this bug, the _Condition instance is created with a Lock instance since that is what the Thread instance uses for constructing the _Condition instance it use, which is just thread.allocate_lock() which is obviously not an RLock. In other words I can't find the point to the side-effect in _Condition. I will try to come up with some testing code that reproduces the error and then see if just removing the calls in _Condition remove the error and still pass the regression tests. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2003-06-16 08:26 Message: Logged In: YES user_id=491567 I can confirm that this behavior is not present in Python 2.2 in the same version that I am using to test against Python 2.3. I will be on vacation for most of this and next week. I'll try to get to the logging script before I leave, but I might not get to it until I return. FYI, you can also obtain OfflineIMAP at http://quux.org/devel/offlineimap. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 01:58 Message: Logged In: YES user_id=357491 OK, following Tim's advice I checked and it seems that Thread calls a method while shutting itself down that calls Condition.notifyAll which calls currentThread which is a global. It would appear that offlineimap is leaving its threads running, the program gets shut down, the threads raise an error while shutting down (probably because things are being torn down), this triggers the stopping method in Thread, and this raises its own exception because of the teardown which is what we are seeing as the TypeError. So the question is whether Condition should store a local reference to currentThread or not. It is not the most pure solution since this shutdown issue is not Condition's, but the only other solution I can think of is to have Thread keep a reference to currentThread, inject it into the current frame's global namespace, call Condition.notifyAll, and then remove the reference from the frame again. I vote for the cleaner, less pure solution. =) Am I insane on this or does it at least sound like this is the problem and proper solution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 01:19 Message: Logged In: YES user_id=357491 Nuts. For some reason I thought the OP had said when threads were exiting. I will ask on python-dev for a good explanation of what happens when Python is shutting down. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-15 20:05 Message: Logged In: YES user_id=31435 Note that the OP said "when my application exits". When Python is tearing down the universe, it systematically sets module-global bindings to None. currentThread() is a module global. I can't make more time for this now, so for more info talk about it on Python-Dev. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 18:44 Message: Logged In: YES user_id=357491 Well, I'm stumped. I checked the diff from when 2.2 was initially released until now and the only change that seems to be related to any of this is that what is returned by currentThread is not saved in a variable. But since the error is the calling of currentThread itself and not saving the return value I don't see how that would affect anything. I also went through offlineimap but I didn't see anything there that seemed to be setting currentThread to None. Although since several files do ``import *`` so there still is a possibility of overwriting currentThread locally. So, for my owning learning and to help solve this, I have written a tracing function that writes to stderr using the logging package when it detects that either currentThread or threading.currentThread has been set to None, locally or globally (I assume the code is not injecting into builtins so I didn't bother checking there). The file is named tracer.py and I have attached it to this bug report. If you can execute ``sys.settrace(tracer.trace_currentThread)`` before offlinemap starts executing and immediately within each thread (it has to be called in *every* thread since tracing functions are no inherited from the main thread) it should print out a message when currentThread becomes None. If you *really* want to make this robust you can also have it check sys.modules['threading'] every time as well, but I figure there is not going to be much renaming and masking of currentThread. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-15 03:44 Message: Logged In: YES user_id=60903 Please see http://packages.debian.org/unstable/mail/offlineimap.html or for the tarball: http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 03:19 Message: Logged In: YES user_id=357491 I went to the FTP site and all I found was some huge, compressed files (after changing the path to ftp://ftp.debian.org/ debian/dists/sid/main/source); no specific program called offlinemap. If it is in one of those files can you just add the file to the bug report? As for the reported bug, it looks like currentThread is being redefined, although how that is happening is beyond me. I checked the 'threading' module and no where is currentThread redefined which could lead to None. Has the app being run been changed at all since Python 2.2 was released? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 From noreply at sourceforge.net Thu Nov 3 22:35:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 13:35:03 -0800 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-03 22:34 Message: Logged In: YES user_id=21627 Thanks for the update. I believe nothing in the POSIX spec mandates to include unistd.h before anything else (unlike sys/types.h, which often is prerequisite to other headers), so I'm closing this report. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-03 11:56 Message: Logged In: YES user_id=52414 Aaargh! I've rebuilt a version of Python 2.4.2 with Sun's C compiler and GNU's C++ compiler but I'm unable to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python-2.4.2/include/python2.4 -c foo.cpp $ Same Solaris 8 workstation, no OS updates, same GCC and same Sun compilers. Oh well... I think it's still a good idea to include before , , , and . But that's your call, I don't mind as long as I'm able to build Python. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-11-02 09:42 Message: Logged In: YES user_id=52414 Ah, I didn't explain myself clearly. I meant to say that must be included before other system headers such as , , , and in this specific case. I totally agree it has to be included after "pyconfig.h". For example if "pyconfig.h" defined _HPUX_SOURCE and was included before "pyconfig.h", then wrong system APIs may be triggered (or at least system APIs that were not intended to be specified). Now why should be included in front of other system headers? This is because: 1) triggers specific POSIX or Single UNIX Specification APIs 2) most if not all system headers do not include , so different APIs may be triggered before including and after including I can't provide a section of the POSIX specification that explictly states that must be included before . This is however implicit: http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html As you can see may or not define macros that trigger a specific API (POSIX.1-1988, SUSv1, SUSv2, SUSv3, etc.). I'll investigate what happens in the case of this specific failure and let you know. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-02 05:19 Message: Logged In: YES user_id=21627 Can you please point to the relevant section of the POSIX specification that states that unistdh.h must be included before stdlib.h? As for the specific problem: it may be that you are somehow working around the real problem by including unistd.h before Python.h. Python.h *must* be included before any system headers, as pyconfig.h defines certain compilation options which affect the feature tests. Including unistd.h before can actually break things, as structs may get defined differently depending on whether pyconfig.h was included first or not. So in the specific example, it would help if you could determine why ::btowc is defined in one case but not in the other. ---------------------------------------------------------------------- Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Fri Nov 4 02:51:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 17:51:38 -0800 Subject: [ python-Bugs-754449 ] Exceptions when a thread exits Message-ID: Bugs item #754449, was opened at 2003-06-14 03:32 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable jgoerzen at christoph:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive LocalExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive RemoteExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-03 17:51 Message: Logged In: YES user_id=357491 This is not Python's fault. If you look at what triggers the exception it is code from Twisted. All of this is happening because the threads being run by the test are not being properly torn down before the interpreter begins to tear itself down. If you make sure all the threads have terminated before ending the test I am sure the error will go away. ---------------------------------------------------------------------- Comment By: Justin Johnson (justincjohnson) Date: 2005-11-03 10:47 Message: Logged In: YES user_id=1049561 I'm seeing this problem still in Python 2.4.1 on Windows. Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 C:\src\Twisted>trial -r iocp twisted.test.test_iutils Using twisted.internet.iocpreactor reactor Running 6 tests. twisted.test.test_iutils UtilsTestCase testOutput ... ? [32;1m[OK]?[0m testOutputAndValue ... ? [32;1m[OK]?[0m testOutputSignal ... ? [32;1m[OK]?[0m testOutputWithErrorCollected ... ? [32;1m[OK]?[0m testOutputWithErrorIgnored ... ? [32;1m[OK]?[0m testValue ... ? [32;1m[OK]?[0m ------------------------------------------------------------------------------- Ran 6 tests in 1.513s PASSED (successes=6) Exception in thread iocpreactor.process_waiter.ProcessWaiter.waitForProcessExi t pid=2156 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap File "C:\Python24\lib\threading.py", line 422, in run File "C:\src\Twisted\twisted\internet\iocpreactor\process_wait er.py", line 165, in doWaitForProcessExit exceptions.TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-17 09:33 Message: Logged In: YES user_id=357491 Python 2.2 is no longer actively maintained, so I wouldn't count on the fix being backported. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2004-09-17 00:15 Message: Logged In: YES user_id=769182 I have this bug on Python 2.2.3 : occasionally getting a very similar stack when my daemon thread exits. I don't get the error for non-daemon threads. My problem seems pretty similar to carlosayam's problem, described in June. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-03 13:01 Message: Logged In: YES user_id=357491 For 2.3, rev.1.38.6.1 has the required fixes (required also backporting rev. 1.41 from HEAD). Thanks to everyone who tried to help with this nasty thing. And a special thanks to the Mnet guys for giving me a way to reproduce this bug consistently. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 20:57 Message: Logged In: YES user_id=357491 Fixed in 2.4 thanks to rev. 1.42 to Lib/threading. Don't know if this will be backported to 2.3 . Possible, but need someone else to agree first. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-02 23:05 Message: Logged In: YES user_id=990060 I don't understand one thing: how can python shut down itself and, at the same time, keep a python code running in a daemonised thread? or is that thread running in a different "threaded" python byte-code interpreter? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-02 22:25 Message: Logged In: YES user_id=31435 Brett, FYI, a daemon thread differs from a non-daemon thread in only one respect: Python shuts down when only daemon threads remain. It waits for non-daemon threads to finish. So a daemon thread can keep running after the interpreter has torn itself down completely. For that reason, problems in daemon threads doing non-trivial things are almost guaranteed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-02 22:08 Message: Logged In: YES user_id=357491 Yep, that is how Python cleans up a module; sets everything in the module to None and then removes it from sys.modules . As for your case, I don't know enough about daemonized threads. My patch for this only tries to let the exception make it to the top without 'threading' hiding the exception by causing its own exception from interpreter shutdown. In other words I don't know if this is a related issue or not. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-02 20:01 Message: Logged In: YES user_id=990060 bcannon said on 2004-02-17 >> Does anyone know how to cause this error in isolation? I'm getting the same error when I start a new thread, daemonise it and the thread goes into a very slow database operation (loading a large object); meanwhile the main thread starts a GUI; then I close the window, exiting the main loop and the python interpreter ends (or tries to end.) In relation to bcannon comment on how to reproduce the error (setting all variables to None in the module), my guess is that while exiting, the python interpreter is somehow freeing all variables in the module (cleaning the module or something), but the module is still running and that raises the error... is this possible? Note: if the thread is not daemonised, the problem desapears but the script (the python interpreter) takes a while to finish. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 21:36 Message: Logged In: YES user_id=357491 How to reproduce the bug: * Follow the instructions at http://mnetproject.org/repos/ on how to get a copy of the in-dev version of mnet (I used the instructions for using wget and it worked fine). * Run ``python setup.py``. Do realize that this app will download other Python code (crypto stuff mostly) to finish its install. Takes up about 54 MB on my machine after it is compiled. * Run ``python setup.py test -a``. This executes the testing suite. The bug manifests itself after the testing suite finishes execution. This will consistently cause the bug every time. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 11:45 Message: Logged In: YES user_id=357491 Discovered this is not fixed after all (previous fix didn't go far enough; still needed, though). Patch 954922 is the second attempt to fix this. This time, though, I had code that could trigger the problem reliably and thus this should be the proper, and final, fix. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 14:36 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 14:32 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-02 20:29 Message: Logged In: YES user_id=357491 To force this error I inserted code to set all attributes of the threading module to None and then throw and exception. After commenting out the two calls to currentThread in _Condition the thrown exception to trigger the problem propogated to the top correctly. I did have the clean-up function give out since I set *everything* to None, but it doesn't look like a normal issue as shown in the exception traceback in the OP. I don't think it is an issue. So it seems commenting the two calls to currentThread in _Condition solves the problem. But since this is threading code and the comment explicitly states it is for the side-effect I am going to try to get a second opinion. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-16 20:59 Message: Logged In: YES user_id=357491 Does anyone know how to cause this error in isolation? I have tried a bunch of different ways but cannot cause an exception to be raised at the correct point in Threading.__bootstrap() to lead to self.__stop() to be called while the interpreter is tearing itself down. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-09 17:18 Message: Logged In: YES user_id=357491 After staring at the code, I am not even sure if the calls for its side- effect are needed. If you call currentThread(), it either returns a value from _active which is a dict of running Thread instances indexed by thread idents, or a new _DummyThread instance that inserts itself into _active. Now the two calls in the _Condition class are purely for this possible side-effect. And yet at no point is anything from _active, through currentThread or direct access, even touched by a _Condition method. The only chance this might be an issue is if a _Condition instance uses an RLock instance for its locking, which is the default behavior. But this still makes the side-effect need useless. RLocks will call currentThread on their own and since this is all in the same thread the result won't change. And in this specific case of this bug, the _Condition instance is created with a Lock instance since that is what the Thread instance uses for constructing the _Condition instance it use, which is just thread.allocate_lock() which is obviously not an RLock. In other words I can't find the point to the side-effect in _Condition. I will try to come up with some testing code that reproduces the error and then see if just removing the calls in _Condition remove the error and still pass the regression tests. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2003-06-16 06:26 Message: Logged In: YES user_id=491567 I can confirm that this behavior is not present in Python 2.2 in the same version that I am using to test against Python 2.3. I will be on vacation for most of this and next week. I'll try to get to the logging script before I leave, but I might not get to it until I return. FYI, you can also obtain OfflineIMAP at http://quux.org/devel/offlineimap. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 23:58 Message: Logged In: YES user_id=357491 OK, following Tim's advice I checked and it seems that Thread calls a method while shutting itself down that calls Condition.notifyAll which calls currentThread which is a global. It would appear that offlineimap is leaving its threads running, the program gets shut down, the threads raise an error while shutting down (probably because things are being torn down), this triggers the stopping method in Thread, and this raises its own exception because of the teardown which is what we are seeing as the TypeError. So the question is whether Condition should store a local reference to currentThread or not. It is not the most pure solution since this shutdown issue is not Condition's, but the only other solution I can think of is to have Thread keep a reference to currentThread, inject it into the current frame's global namespace, call Condition.notifyAll, and then remove the reference from the frame again. I vote for the cleaner, less pure solution. =) Am I insane on this or does it at least sound like this is the problem and proper solution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 23:19 Message: Logged In: YES user_id=357491 Nuts. For some reason I thought the OP had said when threads were exiting. I will ask on python-dev for a good explanation of what happens when Python is shutting down. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-15 18:05 Message: Logged In: YES user_id=31435 Note that the OP said "when my application exits". When Python is tearing down the universe, it systematically sets module-global bindings to None. currentThread() is a module global. I can't make more time for this now, so for more info talk about it on Python-Dev. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 16:44 Message: Logged In: YES user_id=357491 Well, I'm stumped. I checked the diff from when 2.2 was initially released until now and the only change that seems to be related to any of this is that what is returned by currentThread is not saved in a variable. But since the error is the calling of currentThread itself and not saving the return value I don't see how that would affect anything. I also went through offlineimap but I didn't see anything there that seemed to be setting currentThread to None. Although since several files do ``import *`` so there still is a possibility of overwriting currentThread locally. So, for my owning learning and to help solve this, I have written a tracing function that writes to stderr using the logging package when it detects that either currentThread or threading.currentThread has been set to None, locally or globally (I assume the code is not injecting into builtins so I didn't bother checking there). The file is named tracer.py and I have attached it to this bug report. If you can execute ``sys.settrace(tracer.trace_currentThread)`` before offlinemap starts executing and immediately within each thread (it has to be called in *every* thread since tracing functions are no inherited from the main thread) it should print out a message when currentThread becomes None. If you *really* want to make this robust you can also have it check sys.modules['threading'] every time as well, but I figure there is not going to be much renaming and masking of currentThread. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-15 01:44 Message: Logged In: YES user_id=60903 Please see http://packages.debian.org/unstable/mail/offlineimap.html or for the tarball: http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 01:19 Message: Logged In: YES user_id=357491 I went to the FTP site and all I found was some huge, compressed files (after changing the path to ftp://ftp.debian.org/ debian/dists/sid/main/source); no specific program called offlinemap. If it is in one of those files can you just add the file to the bug report? As for the reported bug, it looks like currentThread is being redefined, although how that is happening is beyond me. I checked the 'threading' module and no where is currentThread redefined which could lead to None. Has the app being run been changed at all since Python 2.2 was released? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 From noreply at sourceforge.net Fri Nov 4 03:00:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 18:00:56 -0800 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-22 12:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-11-04 13:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-06 11:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-06 05:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 03:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 02:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-30 00:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 17:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 17:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 16:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 11:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 11:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-28 15:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 09:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-28 04:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 08:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 05:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-13 05:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 05:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 05:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-13 05:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 05:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 05:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 04:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 04:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 04:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 04:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 04:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 03:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 02:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-13 02:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-14 09:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 18:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Fri Nov 4 03:17:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 18:17:57 -0800 Subject: [ python-Bugs-1346874 ] httplib simply ignores CONTINUE Message-ID: Bugs item #1346874, was opened at 2005-11-03 04:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Looijmans (cdwave) Assigned to: Nobody/Anonymous (nobody) Summary: httplib simply ignores CONTINUE Initial Comment: I bumped into this code in httplib.py HTTPConnection, begin(): # read until we get a non-100 response while True: version, status, reason = self._read_status() if status != CONTINUE: break # skip the header from the 100 response while True: skip = self.fp.readline().strip() if not skip: break if self.debuglevel > 0: print "header:", skip This basically silently eats any 100-continue response that the server may send to us. This is not according to the spec - the client should WAIT for the 100-continue, and then post the data. Because of this code snippet, it is impossible for a client to wait for a 100-continue response, since it is silently eaten by this code. A correct implementation would be: - Check the outgoing headers for "Expect: 100-continue" - If that is present, set an "expectcontinue" flag. - If the client tries to send data to the connection, or if the data member was set in the request, wait for the server to send the 100 response BEFORE sending out any data at all, if the flag is set. - If the server fails to send it, the connection will eventually time out. I'd be happy to provide an implementation myself, as it doesn't seem hard to implement and would really help my project. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-03 18:17 Message: Logged In: YES user_id=33168 It's much easier to get a patch integrated since there should be less work than a bug. I encourage you to work on a patch. Don't forget that a patch, must do many things: 1) fix the code, 2) fix (or add!) tests, 3) fix the documentation with an appropriate \versionchanged (or \versionadded) tag, and finally 4) update Misc/NEWS. The old behaviour should generally be backwards compatible by default when adding new functionality. If it's a bug, it may still be desirable to maintain backwards compatibility. I don't know enough about HTTP to provide any guidance here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346874&group_id=5470 From noreply at sourceforge.net Fri Nov 4 03:58:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 18:58:49 -0800 Subject: [ python-Bugs-1347874 ] FeedParser does not comply with RFC2822 Message-ID: Bugs item #1347874, was opened at 2005-11-04 02:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Julian Phillips (quantumfyre) Assigned to: Nobody/Anonymous (nobody) Summary: FeedParser does not comply with RFC2822 Initial Comment: FeedParser (from Lib/email/FeedParser.py) uses the regular expression: ^(From |[\041-\071\073-\176]{2,}:|[\t ]) to recognise Mail headers. However RFC2822 says: field-name := 1*ftext which would give the regular expression: ^(From |[\041-\071\073-\176]{1,}:|[\t ]) This causes mails that use single character header field names to be parsed incorrectly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470 From noreply at sourceforge.net Fri Nov 4 05:08:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 20:08:05 -0800 Subject: [ python-Bugs-1347874 ] FeedParser does not comply with RFC2822 Message-ID: Bugs item #1347874, was opened at 2005-11-03 21:58 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Julian Phillips (quantumfyre) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: FeedParser does not comply with RFC2822 Initial Comment: FeedParser (from Lib/email/FeedParser.py) uses the regular expression: ^(From |[\041-\071\073-\176]{2,}:|[\t ]) to recognise Mail headers. However RFC2822 says: field-name := 1*ftext which would give the regular expression: ^(From |[\041-\071\073-\176]{1,}:|[\t ]) This causes mails that use single character header field names to be parsed incorrectly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1347874&group_id=5470 From noreply at sourceforge.net Fri Nov 4 05:20:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 20:20:22 -0800 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-22 12:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-11-04 15:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-04 13:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-06 11:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-06 05:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 03:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-30 02:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-30 00:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 17:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 17:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 16:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 11:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 11:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-28 15:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 09:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-28 04:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 08:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 05:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-13 05:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 05:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 05:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-13 05:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 05:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 05:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 04:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 04:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 04:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-13 04:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-13 04:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 03:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-13 02:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-13 02:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-14 09:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 18:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Fri Nov 4 14:33:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Nov 2005 05:33:25 -0800 Subject: [ python-Bugs-754449 ] Exceptions when a thread exits Message-ID: Bugs item #754449, was opened at 2003-06-14 05:32 Message generated for change (Comment added) made by justincjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Brett Cannon (bcannon) Summary: Exceptions when a thread exits Initial Comment: [forwarded from http://bugs.debian.org/195812] The application mentioned is offlineimap, available from ftp://ftp.debian.org/dists/unstable/main/source/. This behavior is new to Python 2.3. When my application exits, I get a lot of these messages: Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable jgoerzen at christoph:~/tree/offlineimap-3.99.18$ ./offlineimap.py -l log -d maildir -a Personal,Excel Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive LocalExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable Unhandled exception in thread started by <bound method ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep alive RemoteExcel, stopped daemon)>> Traceback (most recent call last): File "/usr/lib/python2.3/threading.py", line 426, in __bootstrap self.__stop() File "/usr/lib/python2.3/threading.py", line 435, in __stop self.__block.notifyAll() File "/usr/lib/python2.3/threading.py", line 239, in notifyAll self.notify(len(self.__waiters)) File "/usr/lib/python2.3/threading.py", line 221, in notify currentThread() # for side-effect TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- Comment By: Justin Johnson (justincjohnson) Date: 2005-11-04 07:33 Message: Logged In: YES user_id=1049561 Oh, I see. I realized the interpreter was shutting down, but I thought it was shutting down because of an exception in one of the threads, and that the bug in Python was preventing me from seeing the original exception raised in the thread. Now I see the light. Thanks for the response. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-11-03 19:51 Message: Logged In: YES user_id=357491 This is not Python's fault. If you look at what triggers the exception it is code from Twisted. All of this is happening because the threads being run by the test are not being properly torn down before the interpreter begins to tear itself down. If you make sure all the threads have terminated before ending the test I am sure the error will go away. ---------------------------------------------------------------------- Comment By: Justin Johnson (justincjohnson) Date: 2005-11-03 12:47 Message: Logged In: YES user_id=1049561 I'm seeing this problem still in Python 2.4.1 on Windows. Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 C:\src\Twisted>trial -r iocp twisted.test.test_iutils Using twisted.internet.iocpreactor reactor Running 6 tests. twisted.test.test_iutils UtilsTestCase testOutput ... ? [32;1m[OK]?[0m testOutputAndValue ... ? [32;1m[OK]?[0m testOutputSignal ... ? [32;1m[OK]?[0m testOutputWithErrorCollected ... ? [32;1m[OK]?[0m testOutputWithErrorIgnored ... ? [32;1m[OK]?[0m testValue ... ? [32;1m[OK]?[0m ------------------------------------------------------------------------------- Ran 6 tests in 1.513s PASSED (successes=6) Exception in thread iocpreactor.process_waiter.ProcessWaiter.waitForProcessExi t pid=2156 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "C:\Python24\lib\threading.py", line 442, in __bootstrap File "C:\Python24\lib\threading.py", line 422, in run File "C:\src\Twisted\twisted\internet\iocpreactor\process_wait er.py", line 165, in doWaitForProcessExit exceptions.TypeError: 'NoneType' object is not callable ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-09-17 11:33 Message: Logged In: YES user_id=357491 Python 2.2 is no longer actively maintained, so I wouldn't count on the fix being backported. ---------------------------------------------------------------------- Comment By: Geoffrey Bache (gjb1002) Date: 2004-09-17 02:15 Message: Logged In: YES user_id=769182 I have this bug on Python 2.2.3 : occasionally getting a very similar stack when my daemon thread exits. I don't get the error for non-daemon threads. My problem seems pretty similar to carlosayam's problem, described in June. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-03 15:01 Message: Logged In: YES user_id=357491 For 2.3, rev.1.38.6.1 has the required fixes (required also backporting rev. 1.41 from HEAD). Thanks to everyone who tried to help with this nasty thing. And a special thanks to the Mnet guys for giving me a way to reproduce this bug consistently. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-07-02 22:57 Message: Logged In: YES user_id=357491 Fixed in 2.4 thanks to rev. 1.42 to Lib/threading. Don't know if this will be backported to 2.3 . Possible, but need someone else to agree first. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-03 01:05 Message: Logged In: YES user_id=990060 I don't understand one thing: how can python shut down itself and, at the same time, keep a python code running in a daemonised thread? or is that thread running in a different "threaded" python byte-code interpreter? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-06-03 00:25 Message: Logged In: YES user_id=31435 Brett, FYI, a daemon thread differs from a non-daemon thread in only one respect: Python shuts down when only daemon threads remain. It waits for non-daemon threads to finish. So a daemon thread can keep running after the interpreter has torn itself down completely. For that reason, problems in daemon threads doing non-trivial things are almost guaranteed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-06-03 00:08 Message: Logged In: YES user_id=357491 Yep, that is how Python cleans up a module; sets everything in the module to None and then removes it from sys.modules . As for your case, I don't know enough about daemonized threads. My patch for this only tries to let the exception make it to the top without 'threading' hiding the exception by causing its own exception from interpreter shutdown. In other words I don't know if this is a related issue or not. ---------------------------------------------------------------------- Comment By: k (carlosayam) Date: 2004-06-02 22:01 Message: Logged In: YES user_id=990060 bcannon said on 2004-02-17 >> Does anyone know how to cause this error in isolation? I'm getting the same error when I start a new thread, daemonise it and the thread goes into a very slow database operation (loading a large object); meanwhile the main thread starts a GUI; then I close the window, exiting the main loop and the python interpreter ends (or tries to end.) In relation to bcannon comment on how to reproduce the error (setting all variables to None in the module), my guess is that while exiting, the python interpreter is somehow freeing all variables in the module (cleaning the module or something), but the module is still running and that raises the error... is this possible? Note: if the thread is not daemonised, the problem desapears but the script (the python interpreter) takes a while to finish. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 23:36 Message: Logged In: YES user_id=357491 How to reproduce the bug: * Follow the instructions at http://mnetproject.org/repos/ on how to get a copy of the in-dev version of mnet (I used the instructions for using wget and it worked fine). * Run ``python setup.py``. Do realize that this app will download other Python code (crypto stuff mostly) to finish its install. Takes up about 54 MB on my machine after it is compiled. * Run ``python setup.py test -a``. This executes the testing suite. The bug manifests itself after the testing suite finishes execution. This will consistently cause the bug every time. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-05-16 13:45 Message: Logged In: YES user_id=357491 Discovered this is not fixed after all (previous fix didn't go far enough; still needed, though). Patch 954922 is the second attempt to fix this. This time, though, I had code that could trigger the problem reliably and thus this should be the proper, and final, fix. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 16:36 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-08 16:32 Message: Logged In: YES user_id=357491 OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just removed the two calls to currentThread in the _Condition class that were commented to be for their side-effect). Just because I don't feel rock-solid on my fix to the point of it not changing some obscure semantics that I would be willing to put a gun to my head over it I am not going to backport this until I hear from someone who had this bug and reports that they have not had any issues for a long time. Otherwise I will just leave the fix in 2.4 only. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-03-02 22:29 Message: Logged In: YES user_id=357491 To force this error I inserted code to set all attributes of the threading module to None and then throw and exception. After commenting out the two calls to currentThread in _Condition the thrown exception to trigger the problem propogated to the top correctly. I did have the clean-up function give out since I set *everything* to None, but it doesn't look like a normal issue as shown in the exception traceback in the OP. I don't think it is an issue. So it seems commenting the two calls to currentThread in _Condition solves the problem. But since this is threading code and the comment explicitly states it is for the side-effect I am going to try to get a second opinion. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-16 22:59 Message: Logged In: YES user_id=357491 Does anyone know how to cause this error in isolation? I have tried a bunch of different ways but cannot cause an exception to be raised at the correct point in Threading.__bootstrap() to lead to self.__stop() to be called while the interpreter is tearing itself down. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-02-09 19:18 Message: Logged In: YES user_id=357491 After staring at the code, I am not even sure if the calls for its side- effect are needed. If you call currentThread(), it either returns a value from _active which is a dict of running Thread instances indexed by thread idents, or a new _DummyThread instance that inserts itself into _active. Now the two calls in the _Condition class are purely for this possible side-effect. And yet at no point is anything from _active, through currentThread or direct access, even touched by a _Condition method. The only chance this might be an issue is if a _Condition instance uses an RLock instance for its locking, which is the default behavior. But this still makes the side-effect need useless. RLocks will call currentThread on their own and since this is all in the same thread the result won't change. And in this specific case of this bug, the _Condition instance is created with a Lock instance since that is what the Thread instance uses for constructing the _Condition instance it use, which is just thread.allocate_lock() which is obviously not an RLock. In other words I can't find the point to the side-effect in _Condition. I will try to come up with some testing code that reproduces the error and then see if just removing the calls in _Condition remove the error and still pass the regression tests. ---------------------------------------------------------------------- Comment By: John Goerzen (jgoerzen) Date: 2003-06-16 08:26 Message: Logged In: YES user_id=491567 I can confirm that this behavior is not present in Python 2.2 in the same version that I am using to test against Python 2.3. I will be on vacation for most of this and next week. I'll try to get to the logging script before I leave, but I might not get to it until I return. FYI, you can also obtain OfflineIMAP at http://quux.org/devel/offlineimap. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 01:58 Message: Logged In: YES user_id=357491 OK, following Tim's advice I checked and it seems that Thread calls a method while shutting itself down that calls Condition.notifyAll which calls currentThread which is a global. It would appear that offlineimap is leaving its threads running, the program gets shut down, the threads raise an error while shutting down (probably because things are being torn down), this triggers the stopping method in Thread, and this raises its own exception because of the teardown which is what we are seeing as the TypeError. So the question is whether Condition should store a local reference to currentThread or not. It is not the most pure solution since this shutdown issue is not Condition's, but the only other solution I can think of is to have Thread keep a reference to currentThread, inject it into the current frame's global namespace, call Condition.notifyAll, and then remove the reference from the frame again. I vote for the cleaner, less pure solution. =) Am I insane on this or does it at least sound like this is the problem and proper solution? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-16 01:19 Message: Logged In: YES user_id=357491 Nuts. For some reason I thought the OP had said when threads were exiting. I will ask on python-dev for a good explanation of what happens when Python is shutting down. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-15 20:05 Message: Logged In: YES user_id=31435 Note that the OP said "when my application exits". When Python is tearing down the universe, it systematically sets module-global bindings to None. currentThread() is a module global. I can't make more time for this now, so for more info talk about it on Python-Dev. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 18:44 Message: Logged In: YES user_id=357491 Well, I'm stumped. I checked the diff from when 2.2 was initially released until now and the only change that seems to be related to any of this is that what is returned by currentThread is not saved in a variable. But since the error is the calling of currentThread itself and not saving the return value I don't see how that would affect anything. I also went through offlineimap but I didn't see anything there that seemed to be setting currentThread to None. Although since several files do ``import *`` so there still is a possibility of overwriting currentThread locally. So, for my owning learning and to help solve this, I have written a tracing function that writes to stderr using the logging package when it detects that either currentThread or threading.currentThread has been set to None, locally or globally (I assume the code is not injecting into builtins so I didn't bother checking there). The file is named tracer.py and I have attached it to this bug report. If you can execute ``sys.settrace(tracer.trace_currentThread)`` before offlinemap starts executing and immediately within each thread (it has to be called in *every* thread since tracing functions are no inherited from the main thread) it should print out a message when currentThread becomes None. If you *really* want to make this robust you can also have it check sys.modules['threading'] every time as well, but I figure there is not going to be much renaming and masking of currentThread. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-15 03:44 Message: Logged In: YES user_id=60903 Please see http://packages.debian.org/unstable/mail/offlineimap.html or for the tarball: http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-15 03:19 Message: Logged In: YES user_id=357491 I went to the FTP site and all I found was some huge, compressed files (after changing the path to ftp://ftp.debian.org/ debian/dists/sid/main/source); no specific program called offlinemap. If it is in one of those files can you just add the file to the bug report? As for the reported bug, it looks like currentThread is being redefined, although how that is happening is beyond me. I checked the 'threading' module and no where is currentThread redefined which could lead to None. Has the app being run been changed at all since Python 2.2 was released? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470 From noreply at sourceforge.net Fri Nov 4 18:10:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Nov 2005 09:10:56 -0800 Subject: [ python-Bugs-1348477 ] pydoc seems to run some scripts! Message-ID: Bugs item #1348477, was opened at 2005-11-04 17:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 From noreply at sourceforge.net Sat Nov 5 00:58:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Nov 2005 15:58:01 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-04 23:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Sat Nov 5 06:05:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Nov 2005 21:05:04 -0800 Subject: [ python-Bugs-417833 ] pydoc HTTP reload failure Message-ID: Bugs item #417833, was opened at 2001-04-21 07:10 Message generated for change (Comment added) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-04 21:05 Message: Logged In: YES user_id=45338 Fix has been committed to revision 41400. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-03 00:34 Message: Logged In: YES user_id=45338 I've uploaded a fixed version of pydoc.py. Please give it a try and let me know if it works for you. Thanks. ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-11-02 20:56 Message: Logged In: YES user_id=45338 I've been looking into this problem, and unfortunately, the solution isn't as straightforward as rturpin's patch. The (sorry, undocumented) original reason that safeimport uses "del sys.modules[path]" instead of simply calling reload() is that reload() leaves old variables around in the module. For example, if the module initially contains "x = 3", it's loaded, the source file is changed to "y = 3", and then reloaded, the resulting loaded module will contain both x and y. I'm working on a way to safely clear the module without re-triggering the problem. ---------------------------------------------------------------------- Comment By: Russell Turpin (rturpin) Date: 2005-10-31 09:16 Message: Logged In: YES user_id=670280 There's a similar bug in Python 2.4. It causes the __import__ function to throw an AttributeError exception during safeimport(). I've patched our local copy of pydoc to fix this. The patch is to the safeimport() function. The patched lines are: # This keeps __import__ from throwing an exception on reloads. # del sys.modules[path] # This is sole original line module = sys.modules[path] # Added this line try: # Added this line reload(module) # Added this line except: # Added this line module = None # Added this line return module # Added this line This replaces the line: del sys.modules[path] ---------------------------------------------------------------------- Comment By: Eddie Parker (eparker) Date: 2004-08-31 14:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 16:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 08:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\Python21\Lib\pydoc.py", line 223, in safeimport module = __import__(path) File "c:\python21\lib\DemonstratePydocBug\TryThis.py", line 9, in ? Target = DemonstratePydocBug.Target AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' In the interpreter, everything's fine with both techniques for getting Target: C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.Target >>> Target = DemonstratePydocBug.Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:58 Message: Logged In: YES user_id=59803 WHOA. Belay that. I screwed up trying to run too many tests in a row without shutting down the interpreter. Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> DemonstratePydocBug.Target Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' >>> import DemonstratePydocBug.Target >>> DemonstratePydocBug.Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target FILE c:\python21\lib\demonstratepydocbug\target.py DESCRIPTION Target: module to help demonstrate the pydoc reload bug. See the docstring in __init__.py for full details. Reloading the description of this module in pydoc should work, but that's hardly unusual because it doesn't import *anything*. Try ReloadWorks and ReloadFails, instead. DATA __file__ = r'c:\python21 \lib\DemonstratePydocBug\Target.pyc' __name__ = 'DemonstratePydocBug.Target' >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target ... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:55 Message: Logged In: YES user_id=59803 >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) ... we get good stuff... >>> print DemonstratePydocBug.ReloadFails2 <module 'DemonstratePydocBug.ReloadFails2' from 'DemonstratePydocBug\ReloadFails2.py'> >>> pydoc.help(DemonstratePydocBug.ReloadFails2) ... we get good stuff... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 07:43 Message: Logged In: YES user_id=59803 I've found another demonstration case. Noting that from package import module gives you a variable called 'module', whilst import package.module gives you a variable called 'package', I thought I'd try out another import syntax which wouldn't break code that was trying out the first option: import package.module as module This also works under the Python 2.1 interpreter but breaks pydoc 1.38. I've attached an updated demonstration tarchive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 From noreply at sourceforge.net Sat Nov 5 17:31:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 08:31:02 -0800 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 19:29 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:31 Message: Logged In: YES user_id=413 oh good i see you already suggested the simple thread calling lock_detect that I was about to suggest. :) regardless a thread isn't needed. see dbenv.set_lk_detect which tells BerkeleyDB to run deadlock detection automatically anytime a lock conflict occurs. http://www.sleepycat.com/docs/api_c/env_set_lk_detect.html Just add e.set_lk_detect(db.DB_LOCK_DEFAULT) to bsddb/__init__.py's _openDBEnv() function. That causes hammer.py to get DBLockDeadlockError exceptions as expected (dying if the main thread gets one). No lock_detect thread needed. The bsddb legacy interface in __init__.py could have all of its database accesses wrapped in the bsddb.dbutils.DeadlockWrap function. to prevent this. (testing now) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 20:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 18:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-05 18:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 12:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 10:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 09:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 07:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 00:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 00:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 23:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-27 22:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 16:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 11:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 15:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 12:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 12:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 12:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 11:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 10:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 09:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 09:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 16:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 01:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Sat Nov 5 17:51:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 08:51:37 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Manlio Perillo (manlioperillo) Assigned to: Nobody/Anonymous (nobody) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Sat Nov 5 17:54:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 08:54:40 -0800 Subject: [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 19:29 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:54 Message: Logged In: YES user_id=413 modifying bsddb/__init__.py to wrap all calls with DeadlockWrap will be a bit of a pita (but would be doable). I've attached an example wrapped_hammer.py that demonstrates the _openDBEnv change as well as DeadlockWrap wrapping to work properly. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2005-11-05 08:31 Message: Logged In: YES user_id=413 oh good i see you already suggested the simple thread calling lock_detect that I was about to suggest. :) regardless a thread isn't needed. see dbenv.set_lk_detect which tells BerkeleyDB to run deadlock detection automatically anytime a lock conflict occurs. http://www.sleepycat.com/docs/api_c/env_set_lk_detect.html Just add e.set_lk_detect(db.DB_LOCK_DEFAULT) to bsddb/__init__.py's _openDBEnv() function. That causes hammer.py to get DBLockDeadlockError exceptions as expected (dying if the main thread gets one). No lock_detect thread needed. The bsddb legacy interface in __init__.py could have all of its database accesses wrapped in the bsddb.dbutils.DeadlockWrap function. to prevent this. (testing now) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 20:20 Message: Logged In: YES user_id=14198 The db_deadlock program ends up being equivalent to a thread repeatedly calling: dbenv.lock_detect(bsddb.db.DB_LOCK_DEFAULT, 0) For completeness, I attach deadlock_hammer.py - a version that uses yet another thread to perform this lock detection. It also catches the deadlock exceptions, printing but ignoring them. Also, due to the way shutdown is less than graceful, I found I needed to add DB_RECOVER_FATAL to the env flags, otherwise I would often hang on open unless I clobbered the DB directory. On both my box (where it took a little while to see a deadlock) and on a dual-processor box (which provoked it much quicker), this version seems to run forever (although with sporadic performance) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-03 18:00 Message: Logged In: YES user_id=14198 Sadly, I believe bsddb is working "as designed". Quoting from http://www.sleepycat.com/docs/api_c/env_open.html "When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well." So I dig into my bsddb build tree, and found db_deadlock.exe. Sure enough, once studly_hammer.py had deadlocked, executing db_deadlock in the DB directory got things running again - although the threads all eventually died with: bsddb._db.DBLockDeadlockError: (-30996, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock') Obviously it is PITA to need to run an external daemon, and as Python doesn't distribute db_deadlock.exe, the sleepycat license may mean not all applications are allowed to distribute it. This program also polls for deadlocks, meaning your app may hang as long as the poll period. All in all, it seems to suck :) ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-10-05 18:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 12:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 10:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 09:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 07:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying <wink>. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 00:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 00:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 23:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-27 22:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 16:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 11:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 15:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 12:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 12:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 12:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 11:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 10:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 09:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 09:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 16:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 01:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Sat Nov 5 18:09:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 09:09:21 -0800 Subject: [ python-Bugs-495682 ] cannot handle http_proxy with user:pass@ Message-ID: Bugs item #495682, was opened at 2001-12-21 01:22 Message generated for change (Comment added) made by jonico You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: cannot handle http_proxy with user:pass@ Initial Comment: [please CC 120013 at bugs.debian.org; the original report can be found at http://bugs.debian.org/120013 ] I tried to use an http_proxy variable which looks like: http://user:pass at proxy:3128/ with pass like \jkIoPd{ And I got this error : Traceback (most recent call last): File "/usr/bin/reportbug", line 1146, in ? main() File "/usr/bin/reportbug", line 628, in main http_proxy) File "/usr/lib/site-python/reportbug_ui_text.py", line 314, in handle_bts_query archived=archived) File "/usr/lib/site-python/debianbts.py", line 575, in get_reports result = get_cgi_reports(package, system, http_proxy, archived) File "/usr/lib/site-python/debianbts.py", line 494, in get_cgi_reports page = urlopen(url, proxies=proxies) File "/usr/lib/site-python/debianbts.py", line 382, in urlopen return _urlopener.open(url) File "/usr/lib/python2.1/urllib.py", line 176, in open return getattr(self, name)(url) File "/usr/lib/python2.1/urllib.py", line 277, in open_http h = httplib.HTTP(host) File "/usr/lib/python2.1/httplib.py", line 663, in __init__ self._conn = self._connection_class(host, port) File "/usr/lib/python2.1/httplib.py", line 342, in __init__ self._set_hostport(host, port) File "/usr/lib/python2.1/httplib.py", line 348, in _set_hostport port = int(host[i+1:]) ValueError: invalid literal for int(): \jkIoPd {@proxy:3128 But if I use http_proxy=http://10.0.0.1:3128/, it works well. ---------------------------------------------------------------------- Comment By: Johannes Nicolai (jonico) Date: 2005-11-05 18:09 Message: Logged In: YES user_id=863272 I have proposed a patch for this in the patch section: 1349118 is the number of the patch URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1349118&group_id=5470&atid=305470 The patch also solves some other issues with proxies (now it correct handles protocols, where a proxy was specified but not supported and https proxies will also be used if a host requires www-authentification) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-28 23:28 Message: Logged In: YES user_id=6380 This is a feature request. If someone submits a patch, we'll happily apply it. It looks like urllib2 already supports this feature; you could try using that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=495682&group_id=5470 From noreply at sourceforge.net Sat Nov 5 23:46:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 14:46:34 -0800 Subject: [ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n" Message-ID: Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Manlio Perillo (manlioperillo) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 From noreply at sourceforge.net Sun Nov 6 03:07:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Nov 2005 18:07:15 -0800 Subject: [ python-Bugs-1349316 ] xmlrpclib does not use http proxy Message-ID: Bugs item #1349316, was opened at 2005-11-06 02:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: greatred (greatred) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib does not use http proxy Initial Comment: The xmlrpclib class ServerProxy does not seem to be able to make use of a HTTP proxy. This makes it unusable behind a firewall where the proxy is the only access to the destination server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 From noreply at sourceforge.net Sun Nov 6 22:58:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 13:58:35 -0800 Subject: [ python-Bugs-1349732 ] urllib.urlencode provides two features in one param Message-ID: Bugs item #1349732, was opened at 2005-11-06 23:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlencode provides two features in one param Initial Comment: Using the 2.4 distribution. It seems that urlencode knows how to handle unicode input with quote_plus and ascii encoding, but it only does that when doseq is True. 1) There's no mention of that useful feature in the documentation. 2) If I want to encode unicode data without doseq's feature, there's no way to do so. Although it's rare to use doseq's intended function, they shouldn't be connected. Shouldn't values be checked with _is_unicode and handled correctly in both modes of doseq? One reason I see that *might* make the unicode check cause problems is the comment says "preserve old behavior" when doseq is False. Could such a check affect the behaviour of old code? If it can, the unicode handling could be another optional parameter. Also, the docstring is really unclear as to the purpose of doseq. Can an small example be added? (I saw no PEP guidelines for how examples should be given in docstrings, or if they're even allowed, so perhaps this fits just the regular documentation) With query={"key": ("val1", "val2") doseq=1 yields: key=val1&key=val2 doseq=0 yields: key=%28%27val1%27%2C+%27val2%27%29 After the correct solution is settled, I'll gladly submit a patch with the fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349732&group_id=5470 From noreply at sourceforge.net Mon Nov 7 07:31:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 22:31:02 -0800 Subject: [ python-Bugs-1349977 ] urllib2 blocked from news.google.com Message-ID: Bugs item #1349977, was opened at 2005-11-07 06:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoisie (asyncster) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 blocked from news.google.com Initial Comment: It seems that google is blocking requests from clients with urllib 2.4 as the user-agent. If you telnet to news.google.com and type: GET / HTTP/1.1 Host: news.google.com User-agent: Python-urllib/2.4 You get a HTTP/1.1 403 Forbidden ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 From noreply at sourceforge.net Mon Nov 7 08:21:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 23:21:54 -0800 Subject: [ python-Bugs-1349977 ] urllib2 blocked from news.google.com Message-ID: Bugs item #1349977, was opened at 2005-11-06 22:31 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoisie (asyncster) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 blocked from news.google.com Initial Comment: It seems that google is blocking requests from clients with urllib 2.4 as the user-agent. If you telnet to news.google.com and type: GET / HTTP/1.1 Host: news.google.com User-agent: Python-urllib/2.4 You get a HTTP/1.1 403 Forbidden ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-06 23:21 Message: Logged In: YES user_id=357491 I can verify this using urllib.urlretrieve() from the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 From noreply at sourceforge.net Mon Nov 7 09:55:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 00:55:32 -0800 Subject: [ python-Bugs-1350060 ] built-in method .__cmp__ Message-ID: Bugs item #1350060, was opened at 2005-11-07 08:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: built-in method .__cmp__ Initial Comment: Bound methods of built-in objects have a strange __cmp__/__hash__ combination: they compare equal only if their __self__ are identical, but they hash based on the hash of __self__ instead of its _Py_HashPointer(). Built-in methods should consistently be based on the identity *or* the equality of __self__. For reference, regular instance methods are based on the equality. So I propose to fix built-in method objects in the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 From noreply at sourceforge.net Mon Nov 7 12:26:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 03:26:34 -0800 Subject: [ python-Bugs-1350188 ] "setdlopenflags" leads to crash upon "import" Message-ID: Bugs item #1350188, was opened at 2005-11-07 22:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John Pye (jdpipe) Assigned to: Nobody/Anonymous (nobody) Summary: "setdlopenflags" leads to crash upon "import" Initial Comment: While playing around with correct values of the dl.RTLD_xxxx flags in the dl module, I found that I could crash python as follows: python -v [...] >>> import sys; import dl dlopen("/usr/lib/python2.4/lib-dynload/dlmodule.so", 2); import dl # dynamically loaded from /usr/lib/python2.4/lib-dynload/dlmodule.so >>> sys.setdlopenflags(15) >>> import ascend # ascend.pyc matches ascend.py import ascend # precompiled from ascend.pyc dlopen("./_ascend.so", f); python: Objects/stringobject.c:105: PyString_FromString: Assertion `str != ((void *)0)' failed. Aborted JP ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 From noreply at sourceforge.net Mon Nov 7 15:38:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 06:38:19 -0800 Subject: [ python-Bugs-1349977 ] urllib2 blocked from news.google.com Message-ID: Bugs item #1349977, was opened at 2005-11-07 06:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hoisie (asyncster) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 blocked from news.google.com Initial Comment: It seems that google is blocking requests from clients with urllib 2.4 as the user-agent. If you telnet to news.google.com and type: GET / HTTP/1.1 Host: news.google.com User-agent: Python-urllib/2.4 You get a HTTP/1.1 403 Forbidden ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-11-07 14:38 Message: Logged In: YES user_id=6656 In what crazy universe is this a Python bug? It's up to google what they do with http requests, surely. If you are reasonably sure that your use does not violate the terms of use for google news: http://news.google.com/intl/en_us/terms_google_news.html Then you can experiment with getting urllib to send a different User-Agent header. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-11-07 07:21 Message: Logged In: YES user_id=357491 I can verify this using urllib.urlretrieve() from the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 From noreply at sourceforge.net Mon Nov 7 17:53:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 08:53:36 -0800 Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs Message-ID: Bugs item #1350498, was opened at 2005-11-07 11:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 From noreply at sourceforge.net Mon Nov 7 19:25:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 10:25:03 -0800 Subject: [ python-Bugs-1350573 ] zlib.crc32 doesn't handle 0xffffffff seed Message-ID: Bugs item #1350573, was opened at 2005-11-07 18:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350573&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Danny Yoo (dyoo) Assigned to: Nobody/Anonymous (nobody) Summary: zlib.crc32 doesn't handle 0xffffffff seed Initial Comment: Reported by John Schmidt: zlibc.crc32 doesn't appear to properly parse its seed argument. For example: ###### >>> zlib.crc32('foobar',0xFFFFFFFF)) OverflowError: long int too large to convert to int ###### This appears to be fixed if we make the included patch to zlibmodule. I haven't tested this on a 64-bit platform, though; can someone look into this? Hope this helps! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350573&group_id=5470 From noreply at sourceforge.net Mon Nov 7 22:20:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 13:20:10 -0800 Subject: [ python-Bugs-1349977 ] urllib2 blocked from news.google.com Message-ID: Bugs item #1349977, was opened at 2005-11-06 22:31 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Michael Hoisie (asyncster) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 blocked from news.google.com Initial Comment: It seems that google is blocking requests from clients with urllib 2.4 as the user-agent. If you telnet to news.google.com and type: GET / HTTP/1.1 Host: news.google.com User-agent: Python-urllib/2.4 You get a HTTP/1.1 403 Forbidden ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-07 13:20 Message: Logged In: YES user_id=357491 It isn't a Python bug, but then again it got my attention which means I can contact people within Google to see if they can find out what happened. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-07 06:38 Message: Logged In: YES user_id=6656 In what crazy universe is this a Python bug? It's up to google what they do with http requests, surely. If you are reasonably sure that your use does not violate the terms of use for google news: http://news.google.com/intl/en_us/terms_google_news.html Then you can experiment with getting urllib to send a different User-Agent header. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-11-06 23:21 Message: Logged In: YES user_id=357491 I can verify this using urllib.urlretrieve() from the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349977&group_id=5470 From noreply at sourceforge.net Tue Nov 8 00:19:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 15:19:18 -0800 Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs Message-ID: Bugs item #1350498, was opened at 2005-11-07 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 From noreply at sourceforge.net Tue Nov 8 00:26:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 15:26:22 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-05 00:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:26 Message: Logged In: YES user_id=21627 I don't understand your remark " and allow for easy compilation of extensions". Don't you need a copy of VC6 for that? I don't understand how this is inherently different from VC.NET 2003... only that Microsoft don't longer offers VC6 for sale. Many people only have VC.NET available, but no copy of VC6. Anyway, would you like to contribute patches to make this work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Tue Nov 8 00:36:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 15:36:47 -0800 Subject: [ python-Feature Requests-1324176 ] fix for ms stdio tables Message-ID: Feature Requests item #1324176, was opened at 2005-10-11 21:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vambola Kotkas (kotk) Assigned to: Nobody/Anonymous (nobody) Summary: fix for ms stdio tables Initial Comment: Hopefully its right tracker for such request. I am mainly C++ developer but recently it become desirable to embed python as python24.dll into my existing app to make some of features scriptable. I don't want it to have any visible UI or to deal with GUI or the like. However ms has made it so that each dll has its own rtl ioinfo table that is loaded at program start. In other words .. some other dll or exe itself cannot simply redirect python24.dll stdin stdout stderr runtime. It probably has to be done from within python for these redirections to really take effect. I think it is actually very simple to fix that dll problem on C level by making some callable thing into python24.dll that does nothing but fixes dlls ioinfo table to contain real stdio for the process. Example: #include #include void Py_FixMSstdioPITA(void) { /*fix stdin*/ HANDLE hReal = GetStdHandle (STD_INPUT_HANDLE); HANDLE hKnown = _get_osfhandle(_fileno (stdin)); int Number; if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_RDONLY); _dup2(Number,_fileno(stdin)); } /*fix stdout*/ hReal = GetStdHandle (STD_OUTPUT_HANDLE); hKnown = _get_osfhandle(_fileno(stdout)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stdout)); } /*fix stderr*/ hReal = GetStdHandle (STD_ERROR_HANDLE); hKnown = _get_osfhandle(_fileno(stderr)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stderr)); } } I want just call it from outside after any io redirection done in my code ... so python has his stdio all right and done. If something like this is already implemented there in similar or some other way then sorry didnt find it. If its agains general python ideology of some sort then sorry didnt know of it. Let me know please. Best wishes, Vambola Kotkas ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:36 Message: Logged In: YES user_id=21627 I don't understand the remark "has its own rtl ioinfo table". ioinfo is a type - what table are you referring to? If you are talking about __pioinfo: this certainly isn't defined per DLL. Instead, each copy of the MS C runtime has one copy. Python (in 2.4) uses msvcr71.dll. So as long as you also link against msvcr71.dll, you can modify the CRT that Python uses without modifying python24.dll. IOW, you can use your function in your application, and be done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 From noreply at sourceforge.net Tue Nov 8 03:32:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 18:32:53 -0800 Subject: [ python-Bugs-1350188 ] "setdlopenflags" leads to crash upon "import" Message-ID: Bugs item #1350188, was opened at 2005-11-07 03:26 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: John Pye (jdpipe) >Assigned to: Neal Norwitz (nnorwitz) Summary: "setdlopenflags" leads to crash upon "import" Initial Comment: While playing around with correct values of the dl.RTLD_xxxx flags in the dl module, I found that I could crash python as follows: python -v [...] >>> import sys; import dl dlopen("/usr/lib/python2.4/lib-dynload/dlmodule.so", 2); import dl # dynamically loaded from /usr/lib/python2.4/lib-dynload/dlmodule.so >>> sys.setdlopenflags(15) >>> import ascend # ascend.pyc matches ascend.py import ascend # precompiled from ascend.pyc dlopen("./_ascend.so", f); python: Objects/stringobject.c:105: PyString_FromString: Assertion `str != ((void *)0)' failed. Aborted JP ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 From noreply at sourceforge.net Tue Nov 8 03:45:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 18:45:19 -0800 Subject: [ python-Bugs-1348477 ] pydoc seems to run some scripts! Message-ID: Bugs item #1348477, was opened at 2005-11-04 12:10 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-11-07 21:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 From noreply at sourceforge.net Tue Nov 8 04:00:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 19:00:29 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-04 23:58 Message generated for change (Comment added) made by davidmcnab You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- >Comment By: David McNab (davidmcnab) Date: 2005-11-08 03:00 Message: Logged In: YES user_id=35522 Thank you for your reply. In desperation, I started downloading an evaluation version of msvs.net 2003 from bittorrent. But before the download was even halfway complete, I had already installed mingw on my winbox and sorted out the intricacies of compiling 3rd party libs, and building working python extensions, using only mingw. As a result, I am now free of the shackles of proprietary MS toolchains, and am comfortable with mingw - especially since most of the multiplatform 3rd party libs I've seen offer good build support for MinGW. All my extensions, and others' extensions I'm using, are now building quite happily with MinGW. >From this perspective, I no longer have interest in being able to build extensions with MS tools - freeware MSVC compilers or otherwise. In fact, depending on a proprietary toolchain to build Free/Opensource software now feels ludicrous. Therefore, I'd be perfectly comfortable if you want to close this support ticket. Cheers David ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 23:26 Message: Logged In: YES user_id=21627 I don't understand your remark " and allow for easy compilation of extensions". Don't you need a copy of VC6 for that? I don't understand how this is inherently different from VC.NET 2003... only that Microsoft don't longer offers VC6 for sale. Many people only have VC.NET available, but no copy of VC6. Anyway, would you like to contribute patches to make this work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Tue Nov 8 06:21:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 21:21:40 -0800 Subject: [ python-Bugs-1178148 ] cgitb.py report wrong line number Message-ID: Bugs item #1178148, was opened at 2005-04-06 16:04 Message generated for change (Settings changed) made by ping You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Ka-Ping Yee (ping) Summary: cgitb.py report wrong line number Initial Comment: Given code like try: raise 'bug' except ValueError: pass # cgitb.py think 'bug' is here cgitb.py will report that the exception 'bug' is at the pass line. This is a time waster until you figure that this problem exists. ---------------------------------------------------------------------- >Comment By: Ka-Ping Yee (ping) Date: 2005-11-07 21:21 Message: Logged In: YES user_id=45338 I'm going to close this. I've tested it in Python 2.3.5, 2.4.1, and 2.5a0. It works correctly in every case, so it was probably fixed between 2.3 and 2.3.5. ---------------------------------------------------------------------- Comment By: Barry Alan Scott (barry-scott) Date: 2005-04-20 12:57 Message: Logged In: YES user_id=28665 I ran your example on Mac OS X 10.3.9 and its shipped Python 2.3 The attached exctest.html clear show the problem. Did this get fixed in 2.4? ---------------------------------------------------------------------- Comment By: Ka-Ping Yee (ping) Date: 2005-04-18 11:29 Message: Logged In: YES user_id=45338 Can't reproduce this problem. When i test the provided case, cgitb reports the error on the "raise" line as it should. See the attached file for my test case; cgitb highlights line 6 ("raise 'spam'"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178148&group_id=5470 From noreply at sourceforge.net Tue Nov 8 07:17:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 22:17:27 -0800 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 13:26 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-07 22:17 Message: Logged In: YES user_id=341410 On Windows and Linux, I have been able to map positive, nonzero portions of files for quite some time. The only use-case I can see in using an mmap of size 0 is if the file was just created, and a user wanted to immediately resize the mmap to be larger. This can be worked-around with a simple fp.write('\0'), followed by a mmap call with size 1. Resize as desired/necessary. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 14:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Tue Nov 8 07:21:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Nov 2005 22:21:54 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-04 15:58 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-07 22:21 Message: Logged In: YES user_id=341410 I'm not sure this request should be closed. One of the reasons that Python 2.4 compilation was switched to the 7.1 compiler was that it was supposed to be possible to compile Python and extension modules with the free .net compiler. If users cannot compile with the free .net compiler right now, then it seems that there is a bit of a problem. ---------------------------------------------------------------------- Comment By: David McNab (davidmcnab) Date: 2005-11-07 19:00 Message: Logged In: YES user_id=35522 Thank you for your reply. In desperation, I started downloading an evaluation version of msvs.net 2003 from bittorrent. But before the download was even halfway complete, I had already installed mingw on my winbox and sorted out the intricacies of compiling 3rd party libs, and building working python extensions, using only mingw. As a result, I am now free of the shackles of proprietary MS toolchains, and am comfortable with mingw - especially since most of the multiplatform 3rd party libs I've seen offer good build support for MinGW. All my extensions, and others' extensions I'm using, are now building quite happily with MinGW. >From this perspective, I no longer have interest in being able to build extensions with MS tools - freeware MSVC compilers or otherwise. In fact, depending on a proprietary toolchain to build Free/Opensource software now feels ludicrous. Therefore, I'd be perfectly comfortable if you want to close this support ticket. Cheers David ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 15:26 Message: Logged In: YES user_id=21627 I don't understand your remark " and allow for easy compilation of extensions". Don't you need a copy of VC6 for that? I don't understand how this is inherently different from VC.NET 2003... only that Microsoft don't longer offers VC6 for sale. Many people only have VC.NET available, but no copy of VC6. Anyway, would you like to contribute patches to make this work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Tue Nov 8 09:03:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 00:03:24 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-05 00:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 09:03 Message: Logged In: YES user_id=21627 I disagree that one of the reasons to use VC 7.1 was that a free Microsoft compiler was available - it was never one of the reasons why I considered switching. Instead, the reasons were: - MS no longer ships VC6, so many users only had VC7.1 and where requesting that this was used, - VC 7.1 solves a few problems, most notably, IPv6 support can be built with that compiler, but not with VC6, and people where requesting IPv6 support on Windows. So I agree that this request should be closed; I personally have no plans to work on it for the next few years. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 07:21 Message: Logged In: YES user_id=341410 I'm not sure this request should be closed. One of the reasons that Python 2.4 compilation was switched to the 7.1 compiler was that it was supposed to be possible to compile Python and extension modules with the free .net compiler. If users cannot compile with the free .net compiler right now, then it seems that there is a bit of a problem. ---------------------------------------------------------------------- Comment By: David McNab (davidmcnab) Date: 2005-11-08 04:00 Message: Logged In: YES user_id=35522 Thank you for your reply. In desperation, I started downloading an evaluation version of msvs.net 2003 from bittorrent. But before the download was even halfway complete, I had already installed mingw on my winbox and sorted out the intricacies of compiling 3rd party libs, and building working python extensions, using only mingw. As a result, I am now free of the shackles of proprietary MS toolchains, and am comfortable with mingw - especially since most of the multiplatform 3rd party libs I've seen offer good build support for MinGW. All my extensions, and others' extensions I'm using, are now building quite happily with MinGW. >From this perspective, I no longer have interest in being able to build extensions with MS tools - freeware MSVC compilers or otherwise. In fact, depending on a proprietary toolchain to build Free/Opensource software now feels ludicrous. Therefore, I'd be perfectly comfortable if you want to close this support ticket. Cheers David ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:26 Message: Logged In: YES user_id=21627 I don't understand your remark " and allow for easy compilation of extensions". Don't you need a copy of VC6 for that? I don't understand how this is inherently different from VC.NET 2003... only that Microsoft don't longer offers VC6 for sale. Many people only have VC.NET available, but no copy of VC6. Anyway, would you like to contribute patches to make this work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Tue Nov 8 11:07:31 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 02:07:31 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-04 23:58 Message generated for change (Comment added) made by kylotan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None Status: Open Resolution: None Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- Comment By: B Sizer (kylotan) Date: 2005-11-08 10:07 Message: Logged In: YES user_id=206950 I was under the impression that it was possible to build Python extensions using the free MS tools. Several people in comp.lang.python have said as much. The original poster of this bug may wish to check http://www.vrplumber.com/programming/mstoolkit/ for further details. However, if it is now not the case, it is imperative that someone addresses this. There is little point having a free language if it requires a non-free compiler (in either sense of the word) to build the extensions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 08:03 Message: Logged In: YES user_id=21627 I disagree that one of the reasons to use VC 7.1 was that a free Microsoft compiler was available - it was never one of the reasons why I considered switching. Instead, the reasons were: - MS no longer ships VC6, so many users only had VC7.1 and where requesting that this was used, - VC 7.1 solves a few problems, most notably, IPv6 support can be built with that compiler, but not with VC6, and people where requesting IPv6 support on Windows. So I agree that this request should be closed; I personally have no plans to work on it for the next few years. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 06:21 Message: Logged In: YES user_id=341410 I'm not sure this request should be closed. One of the reasons that Python 2.4 compilation was switched to the 7.1 compiler was that it was supposed to be possible to compile Python and extension modules with the free .net compiler. If users cannot compile with the free .net compiler right now, then it seems that there is a bit of a problem. ---------------------------------------------------------------------- Comment By: David McNab (davidmcnab) Date: 2005-11-08 03:00 Message: Logged In: YES user_id=35522 Thank you for your reply. In desperation, I started downloading an evaluation version of msvs.net 2003 from bittorrent. But before the download was even halfway complete, I had already installed mingw on my winbox and sorted out the intricacies of compiling 3rd party libs, and building working python extensions, using only mingw. As a result, I am now free of the shackles of proprietary MS toolchains, and am comfortable with mingw - especially since most of the multiplatform 3rd party libs I've seen offer good build support for MinGW. All my extensions, and others' extensions I'm using, are now building quite happily with MinGW. >From this perspective, I no longer have interest in being able to build extensions with MS tools - freeware MSVC compilers or otherwise. In fact, depending on a proprietary toolchain to build Free/Opensource software now feels ludicrous. Therefore, I'd be perfectly comfortable if you want to close this support ticket. Cheers David ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 23:26 Message: Logged In: YES user_id=21627 I don't understand your remark " and allow for easy compilation of extensions". Don't you need a copy of VC6 for that? I don't understand how this is inherently different from VC.NET 2003... only that Microsoft don't longer offers VC6 for sale. Many people only have VC.NET available, but no copy of VC6. Anyway, would you like to contribute patches to make this work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Tue Nov 8 12:09:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 03:09:02 -0800 Subject: [ python-Bugs-1348477 ] pydoc seems to run some scripts! Message-ID: Bugs item #1348477, was opened at 2005-11-04 17:10 Message generated for change (Comment added) made by olly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! ---------------------------------------------------------------------- >Comment By: Olly Betts (olly) Date: 2005-11-08 11:09 Message: Logged In: YES user_id=14972 So I guess this is a bug report for that missing check in regextest.py in the python distribution. Is running a script which is missing this check an inherent feature of how pydoc works then? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-11-08 02:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 From noreply at sourceforge.net Tue Nov 8 16:16:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 07:16:18 -0800 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 15:26 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-11-08 09:16 Message: Logged In: YES user_id=197677 If the file was created by another process or specified as a parameter, the code might not be free to write into it. Asking os.stat() for the file size works on both platforms. I have not tested on any other platform, but I do not see any reason it would not work. fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) Even if the file were just created, surely asking os.stat() for the file size would not have more overhead than writing to the file. Does it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 00:17 Message: Logged In: YES user_id=341410 On Windows and Linux, I have been able to map positive, nonzero portions of files for quite some time. The only use-case I can see in using an mmap of size 0 is if the file was just created, and a user wanted to immediately resize the mmap to be larger. This can be worked-around with a simple fp.write('\0'), followed by a mmap call with size 1. Resize as desired/necessary. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 16:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Tue Nov 8 17:13:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 08:13:10 -0800 Subject: [ python-Bugs-1348477 ] pydoc seems to run some scripts! Message-ID: Bugs item #1348477, was opened at 2005-11-04 12:10 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Olly Betts (olly) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2005-11-08 11:13 Message: Logged In: YES user_id=139309 pydoc imports modules, it doesn't run scripts. It just so happens that regextest isn't written correctly and does things it shouldn't do when imported. You should file a new bug on regextest.py, or at least change the summary accordingly... but a new bug would end up in the summary again, and would be more likely to be fixed. ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2005-11-08 06:09 Message: Logged In: YES user_id=14972 So I guess this is a bug report for that missing check in regextest.py in the python distribution. Is running a script which is missing this check an inherent feature of how pydoc works then? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-11-07 21:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 From noreply at sourceforge.net Tue Nov 8 18:52:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 09:52:12 -0800 Subject: [ python-Bugs-1351545 ] win32serviceutil bug Message-ID: Bugs item #1351545, was opened at 2005-11-08 17:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Graber (tgraber_us) Assigned to: Nobody/Anonymous (nobody) Summary: win32serviceutil bug Initial Comment: When trying to call service restart or start, the following error message is received. The utility is not handling embeded spaces in the SERVICE_NAME. error: Traceback (most recent call last): File "C:\Python24\Tools\scripts\serviceinfo.py", line 23, in ? service_info(action, machine, service) File "C:\Python24\Tools\scripts\serviceinfo.py", line 11, in service_info win32serviceutil.RestartService(service, machine) File "C:\Python24\lib\site-packages\win32 \lib\win32serviceutil.py", line 409, in RestartService raise win32service.error, (hr, name, msg) pywintypes.error: (1060, 'OpenService', 'The specified service does not exist as an installed service.') Service entry on server using sc query: SERVICE_NAME: JDEdwards OneWorld XE B733 Queue DISPLAY_NAME: JDEdwards OneWorld XE B733 Queue TYPE : 110 WIN32_OWN_PROCESS (interactive) STATE : 4 RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 From noreply at sourceforge.net Tue Nov 8 19:11:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 10:11:46 -0800 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 13:26 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 10:11 Message: Logged In: YES user_id=341410 According to the documentation, in Windows, passing a 'length' of 0 will map the entire file. On 'Unix', it does not discuss what happens when you use a length of 0. The behavior on undefined arguments in the case of linux could almost be expected (though perhaps should be clarified in documentation), and being that the 'cygwin' platform isn't Windows (it's a unix-like environment in Windows), expecting it to perform like Windows, is probably Wasn't your bug report that you could not map 0 bytes from the file, or that passing '0' did not do what you expected on Linux and/or cygwin? If so, then maybe the documentation should be updated. To respond to "wouldn't os.stat(filename).st_size be good to pass during mmap creation time?" Of course, I do that myself, and I would expect most sane people to do the same. os.fstat(fp.fileno()).st_size also works. So, what is your bug report again, and why is this bug report open? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-11-08 07:16 Message: Logged In: YES user_id=197677 If the file was created by another process or specified as a parameter, the code might not be free to write into it. Asking os.stat() for the file size works on both platforms. I have not tested on any other platform, but I do not see any reason it would not work. fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) Even if the file were just created, surely asking os.stat() for the file size would not have more overhead than writing to the file. Does it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-07 22:17 Message: Logged In: YES user_id=341410 On Windows and Linux, I have been able to map positive, nonzero portions of files for quite some time. The only use-case I can see in using an mmap of size 0 is if the file was just created, and a user wanted to immediately resize the mmap to be larger. This can be worked-around with a simple fp.write('\0'), followed by a mmap call with size 1. Resize as desired/necessary. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 14:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Tue Nov 8 19:51:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 10:51:04 -0800 Subject: [ python-Feature Requests-1348719 ] please support the free visual studio sdk compiler Message-ID: Feature Requests item #1348719, was opened at 2005-11-05 00:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 Please note that this 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 Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: David McNab (davidmcnab) Assigned to: Nobody/Anonymous (nobody) Summary: please support the free visual studio sdk compiler Initial Comment: Hi, I noticed, with some pain, that while pythons 2.1 to 2.3 are built with msvc6, and allow for easy compilation of extensions. However, the official binary distro of python2.4 for windows is built with ms vs .net 2003 (version 7.1). I've tried using the .net framework sdk compiler: (http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en) also the Visual C++ Toolkit: (http://www.microsoft.com/downloads/details.aspx?FamilyID=272be09d-40bb-49fd-9cb0-4bfa122fa91b&DisplayLang=en) but in both cases, distutils complains that it can't find a suitable compiler ("error: Python was built with version 7.1 of visual studio..."). I did some hacking on distutils/msvccompiler.py, and noticed that this module is searching for certain registry keys that are only written by the non-free Visual Studio .NET 2003 compiler. As it is, this situation imposes on developers a deterrent against upgrading to python 2.4. There are millions of msvc6 installations out there, but for many, the cost of upgrading to msvs .net 2003 is prohibitive. I have considered building python2.4 from source using msvc6 (I notice the project/workspace files are present in the source), but feel this is unwise because I could end up building extension modules that are binary-incompatible with everyone else's python2.4 I (and countless others, I'm sure) would really appreciate it if the python devs could rework things to make it possible to build python2.4 extensions using the free ms compilers mentioned above). Cheers david ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 19:51 Message: Logged In: YES user_id=21627 As the OP points out, you can use a free compiler (mingw). I'm closing this report: if somebody with an actual, current need has the wish that Python is changed in some precise and verifiable way, please submit a new report. There is no point in guessing what does and doesn't work. People who are experimenting with this are encouraged to propose patches, of course. ---------------------------------------------------------------------- Comment By: B Sizer (kylotan) Date: 2005-11-08 11:07 Message: Logged In: YES user_id=206950 I was under the impression that it was possible to build Python extensions using the free MS tools. Several people in comp.lang.python have said as much. The original poster of this bug may wish to check http://www.vrplumber.com/programming/mstoolkit/ for further details. However, if it is now not the case, it is imperative that someone addresses this. There is little point having a free language if it requires a non-free compiler (in either sense of the word) to build the extensions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 09:03 Message: Logged In: YES user_id=21627 I disagree that one of the reasons to use VC 7.1 was that a free Microsoft compiler was available - it was never one of the reasons why I considered switching. Instead, the reasons were: - MS no longer ships VC6, so many users only had VC7.1 and where requesting that this was used, - VC 7.1 solves a few problems, most notably, IPv6 support can be built with that compiler, but not with VC6, and people where requesting IPv6 support on Windows. So I agree that this request should be closed; I personally have no plans to work on it for the next few years. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 07:21 Message: Logged In: YES user_id=341410 I'm not sure this request should be closed. One of the reasons that Python 2.4 compilation was switched to the 7.1 compiler was that it was supposed to be possible to compile Python and extension modules with the free .net compiler. If users cannot compile with the free .net compiler right now, then it seems that there is a bit of a problem. ---------------------------------------------------------------------- Comment By: David McNab (davidmcnab) Date: 2005-11-08 04:00 Message: Logged In: YES user_id=35522 Thank you for your reply. In desperation, I started downloading an evaluation version of msvs.net 2003 from bittorrent. But before the download was even halfway complete, I had already installed mingw on my winbox and sorted out the intricacies of compiling 3rd party libs, and building working python extensions, using only mingw. As a result, I am now free of the shackles of proprietary MS toolchains, and am comfortable with mingw - especially since most of the multiplatform 3rd party libs I've seen offer good build support for MinGW. All my extensions, and others' extensions I'm using, are now building quite happily with MinGW. >From this perspective, I no longer have interest in being able to build extensions with MS tools - freeware MSVC compilers or otherwise. In fact, depending on a proprietary toolchain to build Free/Opensource software now feels ludicrous. Therefore, I'd be perfectly comfortable if you want to close this support ticket. Cheers David ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:26 Message: Logged In: YES user_id=21627 I don't understand your remark " and allow for easy compilation of extensions". Don't you need a copy of VC6 for that? I don't understand how this is inherently different from VC.NET 2003... only that Microsoft don't longer offers VC6 for sale. Many people only have VC.NET available, but no copy of VC6. Anyway, would you like to contribute patches to make this work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1348719&group_id=5470 From noreply at sourceforge.net Tue Nov 8 20:15:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 11:15:42 -0800 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 15:26 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-11-08 13:15 Message: Logged In: YES user_id=197677 The bug report is still right here in this listing. What are the possible solutions? 1) Not have the Windows version map the entire file length. Could break existing code, so not likely. 2) Have the UNIX version map the entire file when a length of 0 is passed. Since the fp is passed, the code can get length from os.fstat(fp.fileno()).st_size. There could be some code handling this exception whose operation would change if this modification were made. 3) Modify the documentation to be more explicit about valid and invalid length values on the UNIX version. Providing and example using fp.fstat(fp.fileno()).st_size would be very helpful. I see the third option as the only viable path at this point. Letting the Windows path use zero as a magic indicator is an impediment to writing cross-platform code. An example in the documentation of how it could be done is sorely needed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 12:11 Message: Logged In: YES user_id=341410 According to the documentation, in Windows, passing a 'length' of 0 will map the entire file. On 'Unix', it does not discuss what happens when you use a length of 0. The behavior on undefined arguments in the case of linux could almost be expected (though perhaps should be clarified in documentation), and being that the 'cygwin' platform isn't Windows (it's a unix-like environment in Windows), expecting it to perform like Windows, is probably Wasn't your bug report that you could not map 0 bytes from the file, or that passing '0' did not do what you expected on Linux and/or cygwin? If so, then maybe the documentation should be updated. To respond to "wouldn't os.stat(filename).st_size be good to pass during mmap creation time?" Of course, I do that myself, and I would expect most sane people to do the same. os.fstat(fp.fileno()).st_size also works. So, what is your bug report again, and why is this bug report open? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-11-08 09:16 Message: Logged In: YES user_id=197677 If the file was created by another process or specified as a parameter, the code might not be free to write into it. Asking os.stat() for the file size works on both platforms. I have not tested on any other platform, but I do not see any reason it would not work. fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) Even if the file were just created, surely asking os.stat() for the file size would not have more overhead than writing to the file. Does it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 00:17 Message: Logged In: YES user_id=341410 On Windows and Linux, I have been able to map positive, nonzero portions of files for quite some time. The only use-case I can see in using an mmap of size 0 is if the file was just created, and a user wanted to immediately resize the mmap to be larger. This can be worked-around with a simple fp.write('\0'), followed by a mmap call with size 1. Resize as desired/necessary. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 16:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Tue Nov 8 20:37:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 11:37:34 -0800 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 13:26 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 11:37 Message: Logged In: YES user_id=341410 You could just pass fp.fstat(fp.fileno()).st_size to all of your instances, not just the unix ones. Right now, Python exposes the underlying mmap implementation. Windows automatically handles the statting/etc., for using the full size of the file in an mmap. Other platforms don't. While it would seem reasonable to have the unix specific implementation automatically perform an os.fstat(), actually calling the requisite code in os from mmapmodule.c is a pain in the ass (in my experience), and duplicating the code in mmapmodule.c is a poor idea. I would suggest you offer a documentation patch in the patch tracker to state the behavior of Unix mmap and suggested cross-platform workarounds. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-11-08 11:15 Message: Logged In: YES user_id=197677 The bug report is still right here in this listing. What are the possible solutions? 1) Not have the Windows version map the entire file length. Could break existing code, so not likely. 2) Have the UNIX version map the entire file when a length of 0 is passed. Since the fp is passed, the code can get length from os.fstat(fp.fileno()).st_size. There could be some code handling this exception whose operation would change if this modification were made. 3) Modify the documentation to be more explicit about valid and invalid length values on the UNIX version. Providing and example using fp.fstat(fp.fileno()).st_size would be very helpful. I see the third option as the only viable path at this point. Letting the Windows path use zero as a magic indicator is an impediment to writing cross-platform code. An example in the documentation of how it could be done is sorely needed. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-08 10:11 Message: Logged In: YES user_id=341410 According to the documentation, in Windows, passing a 'length' of 0 will map the entire file. On 'Unix', it does not discuss what happens when you use a length of 0. The behavior on undefined arguments in the case of linux could almost be expected (though perhaps should be clarified in documentation), and being that the 'cygwin' platform isn't Windows (it's a unix-like environment in Windows), expecting it to perform like Windows, is probably Wasn't your bug report that you could not map 0 bytes from the file, or that passing '0' did not do what you expected on Linux and/or cygwin? If so, then maybe the documentation should be updated. To respond to "wouldn't os.stat(filename).st_size be good to pass during mmap creation time?" Of course, I do that myself, and I would expect most sane people to do the same. os.fstat(fp.fileno()).st_size also works. So, what is your bug report again, and why is this bug report open? ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-11-08 07:16 Message: Logged In: YES user_id=197677 If the file was created by another process or specified as a parameter, the code might not be free to write into it. Asking os.stat() for the file size works on both platforms. I have not tested on any other platform, but I do not see any reason it would not work. fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) Even if the file were just created, surely asking os.stat() for the file size would not have more overhead than writing to the file. Does it? ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-11-07 22:17 Message: Logged In: YES user_id=341410 On Windows and Linux, I have been able to map positive, nonzero portions of files for quite some time. The only use-case I can see in using an mmap of size 0 is if the file was just created, and a user wanted to immediately resize the mmap to be larger. This can be worked-around with a simple fp.write('\0'), followed by a mmap call with size 1. Resize as desired/necessary. ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 14:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Tue Nov 8 22:29:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 13:29:23 -0800 Subject: [ python-Bugs-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Bugs item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351692&group_id=5470 From noreply at sourceforge.net Tue Nov 8 22:43:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 13:43:38 -0800 Subject: [ python-Bugs-1351707 ] zipimport produces incomplete IOError instances Message-ID: Bugs item #1351707, was opened at 2005-11-08 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport produces incomplete IOError instances Initial Comment: The get_data() method on the zipimport.zipimporter object produces IOError exceptions that only have an error message. It should use PyErr_SetFromErrnoWithFilename() instead of PyErr_Format() for IOError exceptions. This should be fixed for both Python 2.4.3 and 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 From noreply at sourceforge.net Wed Nov 9 01:32:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 16:32:32 -0800 Subject: [ python-Feature Requests-1324176 ] fix for ms stdio tables Message-ID: Feature Requests item #1324176, was opened at 2005-10-11 22:46 Message generated for change (Comment added) made by kotk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vambola Kotkas (kotk) Assigned to: Nobody/Anonymous (nobody) Summary: fix for ms stdio tables Initial Comment: Hopefully its right tracker for such request. I am mainly C++ developer but recently it become desirable to embed python as python24.dll into my existing app to make some of features scriptable. I don't want it to have any visible UI or to deal with GUI or the like. However ms has made it so that each dll has its own rtl ioinfo table that is loaded at program start. In other words .. some other dll or exe itself cannot simply redirect python24.dll stdin stdout stderr runtime. It probably has to be done from within python for these redirections to really take effect. I think it is actually very simple to fix that dll problem on C level by making some callable thing into python24.dll that does nothing but fixes dlls ioinfo table to contain real stdio for the process. Example: #include #include void Py_FixMSstdioPITA(void) { /*fix stdin*/ HANDLE hReal = GetStdHandle (STD_INPUT_HANDLE); HANDLE hKnown = _get_osfhandle(_fileno (stdin)); int Number; if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_RDONLY); _dup2(Number,_fileno(stdin)); } /*fix stdout*/ hReal = GetStdHandle (STD_OUTPUT_HANDLE); hKnown = _get_osfhandle(_fileno(stdout)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stdout)); } /*fix stderr*/ hReal = GetStdHandle (STD_ERROR_HANDLE); hKnown = _get_osfhandle(_fileno(stderr)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stderr)); } } I want just call it from outside after any io redirection done in my code ... so python has his stdio all right and done. If something like this is already implemented there in similar or some other way then sorry didnt find it. If its agains general python ideology of some sort then sorry didnt know of it. Let me know please. Best wishes, Vambola Kotkas ---------------------------------------------------------------------- >Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 02:32 Message: Logged In: YES user_id=698026 Yes, first i did use that function in my application but it surprizingly did not help. Googling about python IO redirection indicated that some others have had similar difficulties. So i debugged around and noticed that the very table that my above function was meant to fix (possibly right that it was named __pioinfo ... MS maps windows handles to CRT FILE pointers there) had various locations. Maybe it was because compiler /M option differed between the module where i did IO redirection and with what python24.dll was compiled. Like... say msvcr71d.dll was loaded for it but msvcr71.dll loaded for python24.dll? :-/ I check it over again when i get time. Thanks. ---------------------------------------------------------------------- Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 02:32 Message: Logged In: YES user_id=698026 Thank you. I've moved this feature request to PEP 42, "Feature Requests". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 01:36 Message: Logged In: YES user_id=21627 I don't understand the remark "has its own rtl ioinfo table". ioinfo is a type - what table are you referring to? If you are talking about __pioinfo: this certainly isn't defined per DLL. Instead, each copy of the MS C runtime has one copy. Python (in 2.4) uses msvcr71.dll. So as long as you also link against msvcr71.dll, you can modify the CRT that Python uses without modifying python24.dll. IOW, you can use your function in your application, and be done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 From noreply at sourceforge.net Wed Nov 9 04:12:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 19:12:23 -0800 Subject: [ python-Feature Requests-1324176 ] fix for ms stdio tables Message-ID: Feature Requests item #1324176, was opened at 2005-10-11 22:46 Message generated for change (Comment added) made by kotk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vambola Kotkas (kotk) Assigned to: Nobody/Anonymous (nobody) Summary: fix for ms stdio tables Initial Comment: Hopefully its right tracker for such request. I am mainly C++ developer but recently it become desirable to embed python as python24.dll into my existing app to make some of features scriptable. I don't want it to have any visible UI or to deal with GUI or the like. However ms has made it so that each dll has its own rtl ioinfo table that is loaded at program start. In other words .. some other dll or exe itself cannot simply redirect python24.dll stdin stdout stderr runtime. It probably has to be done from within python for these redirections to really take effect. I think it is actually very simple to fix that dll problem on C level by making some callable thing into python24.dll that does nothing but fixes dlls ioinfo table to contain real stdio for the process. Example: #include #include void Py_FixMSstdioPITA(void) { /*fix stdin*/ HANDLE hReal = GetStdHandle (STD_INPUT_HANDLE); HANDLE hKnown = _get_osfhandle(_fileno (stdin)); int Number; if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_RDONLY); _dup2(Number,_fileno(stdin)); } /*fix stdout*/ hReal = GetStdHandle (STD_OUTPUT_HANDLE); hKnown = _get_osfhandle(_fileno(stdout)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stdout)); } /*fix stderr*/ hReal = GetStdHandle (STD_ERROR_HANDLE); hKnown = _get_osfhandle(_fileno(stderr)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stderr)); } } I want just call it from outside after any io redirection done in my code ... so python has his stdio all right and done. If something like this is already implemented there in similar or some other way then sorry didnt find it. If its agains general python ideology of some sort then sorry didnt know of it. Let me know please. Best wishes, Vambola Kotkas ---------------------------------------------------------------------- >Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 05:12 Message: Logged In: YES user_id=698026 Right, python24.dll is compiled with /MD option. I was testing it under debug version and that is compiled with /MDd option. When i change the compiler option /MDd to /MD in my apps debug version then the function works outside too. Thanks ---------------------------------------------------------------------- Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 02:32 Message: Logged In: YES user_id=698026 Yes, first i did use that function in my application but it surprizingly did not help. Googling about python IO redirection indicated that some others have had similar difficulties. So i debugged around and noticed that the very table that my above function was meant to fix (possibly right that it was named __pioinfo ... MS maps windows handles to CRT FILE pointers there) had various locations. Maybe it was because compiler /M option differed between the module where i did IO redirection and with what python24.dll was compiled. Like... say msvcr71d.dll was loaded for it but msvcr71.dll loaded for python24.dll? :-/ I check it over again when i get time. Thanks. ---------------------------------------------------------------------- Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 02:32 Message: Logged In: YES user_id=698026 Thank you. I've moved this feature request to PEP 42, "Feature Requests". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 01:36 Message: Logged In: YES user_id=21627 I don't understand the remark "has its own rtl ioinfo table". ioinfo is a type - what table are you referring to? If you are talking about __pioinfo: this certainly isn't defined per DLL. Instead, each copy of the MS C runtime has one copy. Python (in 2.4) uses msvcr71.dll. So as long as you also link against msvcr71.dll, you can modify the CRT that Python uses without modifying python24.dll. IOW, you can use your function in your application, and be done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 From noreply at sourceforge.net Wed Nov 9 06:28:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 21:28:33 -0800 Subject: [ python-Feature Requests-1324176 ] fix for ms stdio tables Message-ID: Feature Requests item #1324176, was opened at 2005-10-11 21:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Vambola Kotkas (kotk) Assigned to: Nobody/Anonymous (nobody) Summary: fix for ms stdio tables Initial Comment: Hopefully its right tracker for such request. I am mainly C++ developer but recently it become desirable to embed python as python24.dll into my existing app to make some of features scriptable. I don't want it to have any visible UI or to deal with GUI or the like. However ms has made it so that each dll has its own rtl ioinfo table that is loaded at program start. In other words .. some other dll or exe itself cannot simply redirect python24.dll stdin stdout stderr runtime. It probably has to be done from within python for these redirections to really take effect. I think it is actually very simple to fix that dll problem on C level by making some callable thing into python24.dll that does nothing but fixes dlls ioinfo table to contain real stdio for the process. Example: #include #include void Py_FixMSstdioPITA(void) { /*fix stdin*/ HANDLE hReal = GetStdHandle (STD_INPUT_HANDLE); HANDLE hKnown = _get_osfhandle(_fileno (stdin)); int Number; if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_RDONLY); _dup2(Number,_fileno(stdin)); } /*fix stdout*/ hReal = GetStdHandle (STD_OUTPUT_HANDLE); hKnown = _get_osfhandle(_fileno(stdout)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stdout)); } /*fix stderr*/ hReal = GetStdHandle (STD_ERROR_HANDLE); hKnown = _get_osfhandle(_fileno(stderr)); if (hReal != hKnown && hReal != INVALID_HANDLE_VALUE) { Number = _open_osfhandle (hReal, _O_BINARY|_O_WRONLY); _dup2(Number,_fileno(stderr)); } } I want just call it from outside after any io redirection done in my code ... so python has his stdio all right and done. If something like this is already implemented there in similar or some other way then sorry didnt find it. If its agains general python ideology of some sort then sorry didnt know of it. Let me know please. Best wishes, Vambola Kotkas ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-09 06:28 Message: Logged In: YES user_id=21627 It normally shouldn't happen that you get two copies of msvcr71.dll. To analyse this problem, you should look at your application in depends.exe; if it shows different versions of the CRT, you lose. In your case, it would have shown both msvcr71.dll and msvcr71d.dll, each having its own notion of stdio. Never ever mix different CRT versions. It will not only not work; it may even crash. Closing this as "works for me". ---------------------------------------------------------------------- Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 04:12 Message: Logged In: YES user_id=698026 Right, python24.dll is compiled with /MD option. I was testing it under debug version and that is compiled with /MDd option. When i change the compiler option /MDd to /MD in my apps debug version then the function works outside too. Thanks ---------------------------------------------------------------------- Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 01:32 Message: Logged In: YES user_id=698026 Yes, first i did use that function in my application but it surprizingly did not help. Googling about python IO redirection indicated that some others have had similar difficulties. So i debugged around and noticed that the very table that my above function was meant to fix (possibly right that it was named __pioinfo ... MS maps windows handles to CRT FILE pointers there) had various locations. Maybe it was because compiler /M option differed between the module where i did IO redirection and with what python24.dll was compiled. Like... say msvcr71d.dll was loaded for it but msvcr71.dll loaded for python24.dll? :-/ I check it over again when i get time. Thanks. ---------------------------------------------------------------------- Comment By: Vambola Kotkas (kotk) Date: 2005-11-09 01:32 Message: Logged In: YES user_id=698026 Thank you. I've moved this feature request to PEP 42, "Feature Requests". ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:36 Message: Logged In: YES user_id=21627 I don't understand the remark "has its own rtl ioinfo table". ioinfo is a type - what table are you referring to? If you are talking about __pioinfo: this certainly isn't defined per DLL. Instead, each copy of the MS C runtime has one copy. Python (in 2.4) uses msvcr71.dll. So as long as you also link against msvcr71.dll, you can modify the CRT that Python uses without modifying python24.dll. IOW, you can use your function in your application, and be done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1324176&group_id=5470 From noreply at sourceforge.net Wed Nov 9 07:44:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 22:44:24 -0800 Subject: [ python-Bugs-1351545 ] win32serviceutil bug Message-ID: Bugs item #1351545, was opened at 2005-11-08 09:52 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Graber (tgraber_us) >Assigned to: Neal Norwitz (nnorwitz) Summary: win32serviceutil bug Initial Comment: When trying to call service restart or start, the following error message is received. The utility is not handling embeded spaces in the SERVICE_NAME. error: Traceback (most recent call last): File "C:\Python24\Tools\scripts\serviceinfo.py", line 23, in ? service_info(action, machine, service) File "C:\Python24\Tools\scripts\serviceinfo.py", line 11, in service_info win32serviceutil.RestartService(service, machine) File "C:\Python24\lib\site-packages\win32 \lib\win32serviceutil.py", line 409, in RestartService raise win32service.error, (hr, name, msg) pywintypes.error: (1060, 'OpenService', 'The specified service does not exist as an installed service.') Service entry on server using sc query: SERVICE_NAME: JDEdwards OneWorld XE B733 Queue DISPLAY_NAME: JDEdwards OneWorld XE B733 Queue TYPE : 110 WIN32_OWN_PROCESS (interactive) STATE : 4 RUNNING (STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN) WIN32_EXIT_CODE : 0 (0x0) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-08 22:44 Message: Logged In: YES user_id=33168 This bug is in win32all (win32com or whatever the package is called). It's not a standard part of Python. You will need to file a bug report with whoever distributes the package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351545&group_id=5470 From noreply at sourceforge.net Wed Nov 9 08:03:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 23:03:20 -0800 Subject: [ python-Bugs-1350188 ] "setdlopenflags" leads to crash upon "import" Message-ID: Bugs item #1350188, was opened at 2005-11-07 03:26 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: John Pye (jdpipe) Assigned to: Neal Norwitz (nnorwitz) Summary: "setdlopenflags" leads to crash upon "import" Initial Comment: While playing around with correct values of the dl.RTLD_xxxx flags in the dl module, I found that I could crash python as follows: python -v [...] >>> import sys; import dl dlopen("/usr/lib/python2.4/lib-dynload/dlmodule.so", 2); import dl # dynamically loaded from /usr/lib/python2.4/lib-dynload/dlmodule.so >>> sys.setdlopenflags(15) >>> import ascend # ascend.pyc matches ascend.py import ascend # precompiled from ascend.pyc dlopen("./_ascend.so", f); python: Objects/stringobject.c:105: PyString_FromString: Assertion `str != ((void *)0)' failed. Aborted JP ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-08 23:03 Message: Logged In: YES user_id=33168 Thanks! I don't have ascend.so. I tried importing time and it crashed hard. I checked in a fix for me. Let me know if it doesn't fix the problem for you. Committed revision 41412. Committed revision 41413. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 From noreply at sourceforge.net Wed Nov 9 08:09:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 23:09:28 -0800 Subject: [ python-Bugs-1348477 ] pydoc seems to run some scripts! Message-ID: Bugs item #1348477, was opened at 2005-11-04 09:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Olly Betts (olly) >Assigned to: Neal Norwitz (nnorwitz) Summary: pydoc seems to run some scripts! Initial Comment: Ubuntu 5.10 "Breezy Badger" Linux 2.6.10 Python 2.4.2 Running pydoc on some scripts (for example regextest.py as supplied with python) just seems to hang: pydoc /usr/share/doc/python2.4/examples/Demo/comparisons/regextest.py Feeding it EOF (Ctrl-D) makes it actually generate documentation and exit. But as well as showing the documentation, I get output which appears to be the script actually having run with itself as an argument! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-08 23:09 Message: Logged In: YES user_id=33168 I'm feeling generous tonight. :-) Thanks for the report. I updated regextest program. Committed revision 41414. Committed revision 41415. (2.4) ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-11-08 08:13 Message: Logged In: YES user_id=139309 pydoc imports modules, it doesn't run scripts. It just so happens that regextest isn't written correctly and does things it shouldn't do when imported. You should file a new bug on regextest.py, or at least change the summary accordingly... but a new bug would end up in the summary again, and would be more likely to be fixed. ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2005-11-08 03:09 Message: Logged In: YES user_id=14972 So I guess this is a bug report for that missing check in regextest.py in the python distribution. Is running a script which is missing this check an inherent feature of how pydoc works then? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-11-07 18:45 Message: Logged In: YES user_id=139309 Some scripts are broken, this one is missing a check to see if it's a script or a module: if __name__ == "__main__": main() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1348477&group_id=5470 From noreply at sourceforge.net Wed Nov 9 10:14:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 01:14:50 -0800 Subject: [ python-Bugs-1350188 ] "setdlopenflags" leads to crash upon "import" Message-ID: Bugs item #1350188, was opened at 2005-11-07 22:26 Message generated for change (Comment added) made by jdpipe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: John Pye (jdpipe) Assigned to: Neal Norwitz (nnorwitz) Summary: "setdlopenflags" leads to crash upon "import" Initial Comment: While playing around with correct values of the dl.RTLD_xxxx flags in the dl module, I found that I could crash python as follows: python -v [...] >>> import sys; import dl dlopen("/usr/lib/python2.4/lib-dynload/dlmodule.so", 2); import dl # dynamically loaded from /usr/lib/python2.4/lib-dynload/dlmodule.so >>> sys.setdlopenflags(15) >>> import ascend # ascend.pyc matches ascend.py import ascend # precompiled from ascend.pyc dlopen("./_ascend.so", f); python: Objects/stringobject.c:105: PyString_FromString: Assertion `str != ((void *)0)' failed. Aborted JP ---------------------------------------------------------------------- >Comment By: John Pye (jdpipe) Date: 2005-11-09 20:14 Message: Logged In: YES user_id=849068 Hi Neal, Yeah the ascend.so thing is something I'm working on with SWIG, basically some bindings for ASCEND, see http://pye.dyndns.org/ascend/. I'm probably not going to check out and build python from sources, so I'll just have to take your word for it ;-) Cheers JP ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 18:03 Message: Logged In: YES user_id=33168 Thanks! I don't have ascend.so. I tried importing time and it crashed hard. I checked in a fix for me. Let me know if it doesn't fix the problem for you. Committed revision 41412. Committed revision 41413. (2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350188&group_id=5470 From noreply at sourceforge.net Wed Nov 9 16:03:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 07:03:07 -0800 Subject: [ python-Bugs-799428 ] tk_focusNext() fails Message-ID: Bugs item #799428, was opened at 2003-09-02 23:58 Message generated for change (Comment added) made by douardda You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Perry Greenfield (perrygreenfield) Assigned to: Nobody/Anonymous (nobody) Summary: tk_focusNext() fails Initial Comment: Calls to the widget method tk_focusNext() fail with "unsubscriptable object" error. Looking at the Tkinter.py code for the routine shows this statement: name = self.tk.call('tk_focusNext', self._w) (line 433) which used to return a string in 2.2 but now returns a "cmdName object". When this is passed to self._nametowidget(name), it fails when it tries to subscript name (line 1006) since the object does not support indexing. Perhaps str(name) or name.string is more appropriate now? (when that change is made, it works--well, I tested name.string and that worked) Perry Greenfield (perry at stsci.edu) ---------------------------------------------------------------------- Comment By: David Douard (douardda) Date: 2005-11-09 16:03 Message: Logged In: YES user_id=692511 The problem is still not resolved for now (AFAIK). Here is a very simple patch for Tkinter.py: *** 432,442 **** --- 432,446 ---- to 0.""" name = self.tk.call('tk_focusNext', self._w) if not name: return None + try: name=name.string + except: pass return self._nametowidget(name) def tk_focusPrev(self): """Return previous widget in the focus order. See tk_focusNext for details.""" name = self.tk.call('tk_focusPrev', self._w) if not name: return None + try: name=name.string + except: pass return self._nametowidget(name) def after(self, ms, func=None, *args): """Call function once after given time. Note: I have made this (try/except) cause I have encountered cases where "name" was still a string (well, at least with Python 2.3.1). David (david.douard*gmail.com) ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-09-07 17:23 Message: Logged In: YES user_id=2772 Presumably, _nametowidget() should be modified to work properly with a "cmdName object", rather than modifying each site that gets a widget path from a tk command. ---------------------------------------------------------------------- Comment By: Perry Greenfield (perrygreenfield) Date: 2003-09-03 15:29 Message: Logged In: YES user_id=252130 Presumably the same problem exists with tk_focusPrev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=799428&group_id=5470 From noreply at sourceforge.net Wed Nov 9 22:43:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 13:43:13 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 01:08 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 23:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 14:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 20:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 13:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 19:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 17:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Wed Nov 9 22:45:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 13:45:05 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Wed Nov 9 23:26:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 14:26:06 -0800 Subject: [ python-Bugs-1352621 ] SVN webbrowser.py fix 41419 didn't Message-ID: Bugs item #1352621, was opened at 2005-11-09 14:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: SVN webbrowser.py fix 41419 didn't Initial Comment: The new fix of setting remote_background to True and adding an & in the "simplier command" case can't work. If remote_background is True, then the first os.system call will always succeed and thus the second one will never be called. So if the web browser isn't already running, it will never start up. As I alluded to in my previous bug submission 1338995, the real fix will involve using the subprocess module -- I will try to find some time to develop and test a patch and submit it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1352621&group_id=5470 From noreply at sourceforge.net Thu Nov 10 01:46:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 16:46:55 -0800 Subject: [ python-Bugs-1351707 ] zipimport produces incomplete IOError instances Message-ID: Bugs item #1351707, was opened at 2005-11-09 07:43 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport produces incomplete IOError instances Initial Comment: The get_data() method on the zipimport.zipimporter object produces IOError exceptions that only have an error message. It should use PyErr_SetFromErrnoWithFilename() instead of PyErr_Format() for IOError exceptions. This should be fixed for both Python 2.4.3 and 2.5. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-10 10:46 Message: Logged In: YES user_id=315535 Patch against HEAD here: http://sourceforge.net/tracker/index.php?func=detail&aid=1352711&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&group_id=5470 From noreply at sourceforge.net Thu Nov 10 06:48:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 21:48:11 -0800 Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs Message-ID: Bugs item #1350498, was opened at 2005-11-07 08:52 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) >Assigned to: Brett Cannon (bcannon) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 21:48 Message: Logged In: YES user_id=33168 Brett, did you finish updating all these docs? Is this bug dead now? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 15:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 From noreply at sourceforge.net Thu Nov 10 08:42:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 23:42:41 -0800 Subject: [ python-Bugs-1092502 ] Memory leak in socket.py on Mac OS X 10.3 Message-ID: Bugs item #1092502, was opened at 2004-12-29 03:09 Message generated for change (Comment added) made by a_lauer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: bacchusrx (bacchusrx) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak in socket.py on Mac OS X 10.3 Initial Comment: Some part of socket.py leaks memory on Mac OS X 10.3 (both with the python 2.3 that ships with the OS and with python 2.4). I encountered the problem in John Goerzen's offlineimap. Transfers of messages over a certain size would cause the program to bail with malloc errors, eg *** malloc: vm_allocate(size=5459968) failed (error code=3) *** malloc[13730]: error: Can't allocate region Inspecting the process as it runs shows that python's total memory size grows wildly during such transfers. The bug manifests in _fileobject.read() in socket.py. You can replicate the problem easily using the attached example with "nc -l -p 9330 < /dev/zero" running on some some remote host. The way _fileobject.read() is written, socket.recv is called with the larger of the minimum rbuf size or whatever's left to be read. Whatever is received is then appended to a buffer which is joined and returned at the end of function. It looks like each time through the loop, space for recv_size is allocated but not freed, so if the loop runs for enough iterations, python exhausts the memory available to it. You can sidestep the condition if recv_size is small (like _fileobject.default_bufsize small). I can't replicate this problem with python 2.3 on FreeBSD 4.9 or FreeBSD 5.2, nor on Mac OS X 10.3 if the logic from _fileobject.read() is re-written in Perl (for example). ---------------------------------------------------------------------- Comment By: Andreas Lauer (a_lauer) Date: 2005-11-10 08:42 Message: Logged In: YES user_id=1376343 The problem also occurs in rare cases under Windows XP with Python 2.3.4. I Suspect the code line recv_size = max(self._rbufsize, left) in socket.py to be a part of the problem. In the case that I investigated, this caused >600 allocations of up to 5 MBytes (which came in 8 KB packets). Sure, the memory allocator should be able to handle this in _socket.recv (first it allocates the X MBytes buffer, which is later resized with _PyString_Resize), but it I think the correct line in socket.py is recv_size = min(self._rbufsize, left). At least, after this my problem was gone. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-02 03:25 Message: Logged In: YES user_id=139309 that code paste is missing an "int i" at the beginning of main.. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-02 03:23 Message: Logged In: YES user_id=139309 #include #define NUM_ALLOCATIONS 100000 #define ALLOC_SIZE 10485760 #define ALLOC_RESIZE 1492 int main(int argc, char **argv) { /* exiting will free all this leaked memory */ for (i = 0; i < NUM_ALLOCATIONS; i++) { void *orig_ptr, *new_ptr; size_t new_size, orig_size; orig_ptr = malloc(ALLOC_SIZE); orig_size = malloc_size(orig_ptr); if (orig_ptr == NULL) { printf("failure to malloc %d\n", i); abort(); } new_ptr = realloc(orig_ptr, ALLOC_RESIZE); new_size = malloc_size(new_ptr); printf("resized %d[%p] -> %d[%p]\n", orig_size, orig_ptr, new_size, new_ptr); if (new_ptr == NULL) { printf("failure to realloc %d\n", i); abort(); } } return 0; } ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-02 03:22 Message: Logged In: YES user_id=139309 Ok. I've tracked it down. realloc(...) on Darwin doesn't actually resize memory unless it *has* to. For shrinking an allocation, it does not have to, therefore realloc(...) with a smaller size is a no-op. It seems that this may be a misunderstanding by Python. The man page for realloc(...) does not say that it will EVER free memory, EXCEPT in the case where it has to allocate a larger region. I'll attach an example that demonstrates this outside of Python. ---------------------------------------------------------------------- Comment By: bacchusrx (bacchusrx) Date: 2005-01-02 00:01 Message: Logged In: YES user_id=646321 I've been able to replicate the problem reliably on both 10.3.5 and 10.3.7. I've attached two more examples to demonstrate: Try this: Do, "dd if=/dev/zero of=./data bs=1024 count=10240" and save server.pl wherever you put "data". Have three terminals open. In one, run "perl server.pl -s0.25". In another, run "top -ovsize" and in the third run "python example2.py". After about 100 iterations, python's vsize is +1GB (just about the value of cumulative_req in example2.py) and if left running will cause a malloc error at around 360 iterations with a vsize over 3.6GB (again, just about what cumulative_req reports). Mind you, we've only received ~512kbytes. server.pl differs from the netcat method in that it (defaults) to sending only 1492 bytes at a time (configurable with the -b switch) and sleeps for however many seconds specified with the -s switch. This guarantees enough iterations to raise the error each time around. When omittting the -s switch to server.pl, I don't get the error, but throughput is good enough that the loop in readFromSockUntil() only runs a few times. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 07:27 Message: Logged In: YES user_id=139309 I just played with a bit more. If I catch the MemoryError and try again, most of the time it will work (sometimes on the second try). These malloc faults seem to be some kind of temporary condition. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2005-01-01 07:18 Message: Logged In: YES user_id=139309 I can't reproduce this on either version of Python a 10.3.7 machine w/ 1gb ram. Python's total memory usage seems stable to me even if the read is in a while loop. I can't see anything in sock_recv or _fileobject.read that will in any way leak memory. With a really large buffer size (always >17mb, but it does vary with each run) it will get a memory error but the Python process doesn't grow beyond 50mb at the samples I looked at. That's pretty much the amount of RAM I'd expect it to use. It is kind of surprising it doesn't want to allocate a buffer of that size, because I have the RAM for it.. but I don't think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092502&group_id=5470 From noreply at sourceforge.net Thu Nov 10 10:05:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 01:05:10 -0800 Subject: [ python-Bugs-1250389 ] The -m option to python does not search zip files Message-ID: Bugs item #1250389, was opened at 2005-08-03 02:55 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-10 19:05 Message: Logged In: YES user_id=1038590 I agree this is a significant limitation on -m, although I think it actually pales in comparison to the fact you can't use modules inside packages. So please take a look at PEP 328 and provide feedback on it. I've had absolutely *zero* feedback on it since I wrote it, and have had to assume that no-one else was bothered by the current limitations. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-08-12 04:33 Message: Logged In: YES user_id=113328 I have looked into this, and it appears that _PyImportHooks_Init is getting called properly, and the zipimport mechanism is getting initialised (python -v -m a where a.py is in a zip file on sys.path shows this). The problem seems to be that main.c calls, in Py_Main, _PyImport_FindModule, with the "loader" argument set to NULL, which disables handling of PEP 302 style import hooks. This makes sense, to the extent that the current code needs a real FILE* to call PyRun_AnyFileExFlags, it should be possible (by calling PyRun_SimpleStringFlags instead, maybe?) to execute a module loaded from a hook. Unfortunately, I can't take this any further at present, as I don't have the means to build Python in order to test a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 From noreply at sourceforge.net Thu Nov 10 11:26:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 02:26:34 -0800 Subject: [ python-Bugs-1250389 ] The -m option to python does not search zip files Message-ID: Bugs item #1250389, was opened at 2005-08-02 17:55 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2005-11-10 10:26 Message: Logged In: YES user_id=113328 I assume you meant PEP 338. I'm completely in favour of that. I didn't give feedback simply because I had nothing constructive to add beyond "+1"... (And I agree that PEP 338 is more important than this bug - but I'd like to see both sorted :-)) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-11-10 09:05 Message: Logged In: YES user_id=1038590 I agree this is a significant limitation on -m, although I think it actually pales in comparison to the fact you can't use modules inside packages. So please take a look at PEP 328 and provide feedback on it. I've had absolutely *zero* feedback on it since I wrote it, and have had to assume that no-one else was bothered by the current limitations. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2005-08-11 19:33 Message: Logged In: YES user_id=113328 I have looked into this, and it appears that _PyImportHooks_Init is getting called properly, and the zipimport mechanism is getting initialised (python -v -m a where a.py is in a zip file on sys.path shows this). The problem seems to be that main.c calls, in Py_Main, _PyImport_FindModule, with the "loader" argument set to NULL, which disables handling of PEP 302 style import hooks. This makes sense, to the extent that the current code needs a real FILE* to call PyRun_AnyFileExFlags, it should be possible (by calling PyRun_SimpleStringFlags instead, maybe?) to execute a module loaded from a hook. Unfortunately, I can't take this any further at present, as I don't have the means to build Python in order to test a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 From noreply at sourceforge.net Thu Nov 10 15:48:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 06:48:23 -0800 Subject: [ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__ Message-ID: Bugs item #1328278, was opened at 2005-10-17 11:22 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Josh Marshall (jpmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: __getslice__ taking priority over __getitem__ Initial Comment: When creating a class that uses __getitem__ to implement slicing, if __getattr__ is also implemented, slicing will fail. This is due to the (deprecated) __getslice__ method being called before __getitem__. The attached file demonstrates this. If __getitem__ is implemented on its own, all is rosy. When we add __getattr__ and do not raise an AttributeError when __getslice__ is searched for, the slicing fails. If we raise this AttributeError, __getitem__ is called next. The only other reference I could find to this bug is on the jython mailing list, from 2003: http://sourceforge.net/mailarchive/forum.php? thread_id=2350972&forum_id=5586 My question is; why is __getslice__ called before __getitem__? I assumed that because it is deprecated, it would be the last resort for a slicing. Is this planned to be fixed, or is there existing behaviour that is reliant on it? ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-11 00:48 Message: Logged In: YES user_id=315535 This seems to be the documented, expected behavior: http://www.python.org/doc/2.4.2/ref/sequence-methods.html As to _why_ __getslice__ is called before __getitem__, I'm not sure - but it's right there in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 From noreply at sourceforge.net Thu Nov 10 17:34:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 08:34:30 -0800 Subject: [ python-Bugs-1353269 ] poplib.POP3_SSL() class incompatible with socket.timeout Message-ID: Bugs item #1353269, was opened at 2005-11-10 10:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Charles (melicertes) Assigned to: Nobody/Anonymous (nobody) Summary: poplib.POP3_SSL() class incompatible with socket.timeout Initial Comment: If you call socket.setdefaulttimeout() to enable timeout mode, then create a POP3-over-SSL connection by instantiating a poplib.POP3_SSL() object, the resulting connection can hang because the underlying socket.ssl() object doesn't work when timeouts are enabled. If, after creating the POP3_SSL object, you call object.conn.sock.setblocking(1), the hangs will not happen. This is exactly the same bug as happened with IMAP SSL connections, as I reported in bug #977680. The Python documentation still does not mention that socket SSL support is not compatible with socket timeout support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353269&group_id=5470 From noreply at sourceforge.net Thu Nov 10 19:22:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 10:22:43 -0800 Subject: [ python-Feature Requests-1353344 ] python.desktop Message-ID: Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 From noreply at sourceforge.net Thu Nov 10 21:25:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 12:25:56 -0800 Subject: [ python-Bugs-1353433 ] Http redirection error in urllib2.py Message-ID: Bugs item #1353433, was opened at 2005-11-10 15:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Dehn (dehn) Assigned to: Nobody/Anonymous (nobody) Summary: Http redirection error in urllib2.py Initial Comment: A url request returns a redirect that contains a space ' ' character. Python urllib2.py does not replace this character with '%20' and fails. Entering a line after line 507 of: newurl=re.sub(' ','%20',newurl) Corrects my problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353433&group_id=5470 From noreply at sourceforge.net Thu Nov 10 22:10:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 13:10:05 -0800 Subject: [ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346547, was opened at 2005-11-03 03:34 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Luke (luked) >Assigned to: Fredrik Lundh (effbot) Summary: _subprocess.c calls PyInt_AsLong without error checking Initial Comment: _subprocess.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> si = subprocess.STARTUPINFO() >>> si.wShowWindow = 2**65 >>> obj = subprocess.Popen('notepad.exe', startupinfo=si) >>> 1+1 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-03 06:20 Message: Logged In: YES user_id=33168 This code (for startupinfo) is only valid on Windows. The problem seems to be at lines 379 and 380 in PC/_subprocess.c. I'll let someone who can test this one take care of it. The return result from getint() needs to be checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 From noreply at sourceforge.net Thu Nov 10 22:49:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 13:49:09 -0800 Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs Message-ID: Bugs item #1350498, was opened at 2005-11-07 08:52 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Brett Cannon (bcannon) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-10 13:49 Message: Logged In: YES user_id=357491 Everything but tools.html has been fixed. That doc really just needs to be replaced (see python-dev and the thread on the dev FAQ update for any discussion on the topic) and so fixing it is not on my list of things to do. =) I will leave this bug open, though, until the doc is deleted. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 21:48 Message: Logged In: YES user_id=33168 Brett, did you finish updating all these docs? Is this bug dead now? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 15:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 From noreply at sourceforge.net Thu Nov 10 23:16:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 14:16:38 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 16:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Thu Nov 10 23:43:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 14:43:33 -0800 Subject: [ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346547, was opened at 2005-11-03 03:34 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Luke (luked) Assigned to: Fredrik Lundh (effbot) Summary: _subprocess.c calls PyInt_AsLong without error checking Initial Comment: _subprocess.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> si = subprocess.STARTUPINFO() >>> si.wShowWindow = 2**65 >>> obj = subprocess.Popen('notepad.exe', startupinfo=si) >>> 1+1 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-10 23:43 Message: Logged In: YES user_id=38376 I've added a fix to the subprocess patch over at http://www.python.org/sf/1351997 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-03 06:20 Message: Logged In: YES user_id=33168 This code (for startupinfo) is only valid on Windows. The problem seems to be at lines 379 and 380 in PC/_subprocess.c. I'll let someone who can test this one take care of it. The return result from getint() needs to be checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 From noreply at sourceforge.net Thu Nov 10 23:56:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 14:56:22 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Fri Nov 11 04:31:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 19:31:17 -0800 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 15:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this 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.4 Status: Open Resolution: Accepted Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-11-10 22:31 Message: Logged In: YES user_id=31435 Is this still an issue in 2.4.2? I downloaded the zip file, and didn't have any problem importing the .py file on Windows using 2.4.2. A number of problems with encoding directives were fixed in 2.4.2, so I doubt that's an accident ;-) ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 13:10 Message: Logged In: YES user_id=598066 http://sourceforge.net/tracker/? func=detail&aid=1166627&group_id=78018&atid=551954 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 03:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 02:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 06:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 12:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-14 19:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 04:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 08:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 07:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 05:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Fri Nov 11 06:20:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 21:20:09 -0800 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-15 07:20 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) Assigned to: Nobody/Anonymous (nobody) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-11-11 16:20 Message: Logged In: YES user_id=14198 Thanks Tim! I can confirm that I can no longer reproduce it with the svn release24-maint branch - so I'm going out on a limb and closing it. I haven't tested Linux, so it would be great of some others could also confirm it fixed (or reopen it if not) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-11-11 14:31 Message: Logged In: YES user_id=31435 Is this still an issue in 2.4.2? I downloaded the zip file, and didn't have any problem importing the .py file on Windows using 2.4.2. A number of problems with encoding directives were fixed in 2.4.2, so I doubt that's an accident ;-) ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-05 03:10 Message: Logged In: YES user_id=598066 http://sourceforge.net/tracker/? func=detail&aid=1166627&group_id=78018&atid=551954 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 17:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 16:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 20:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-03 02:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-15 09:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 18:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-22 00:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 23:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 21:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Fri Nov 11 08:24:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Nov 2005 23:24:00 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Skip Montanaro (montanaro) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 23:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Fri Nov 11 09:44:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 00:44:29 -0800 Subject: [ python-Bugs-869197 ] setgroups rejects long integer arguments Message-ID: Bugs item #869197, was opened at 2004-01-02 10:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: setgroups rejects long integer arguments Initial Comment: os.setgroups ought to accept long integer arguments, just as os.setgid does. I think this worked in an earlier version of Python - or maybe it was that string.atol used to return a non-long integer if the number was small enough, so I didn't encounter long integers at all. >>> import os >>> os.setgid(1L) >>> os.setgroups((1L,)) Traceback (most recent call last): File "", line 1, in ? TypeError: groups must be integers >>> import sys >>> print sys.version 2.3.3 (#1, Dec 30 2003, 22:52:56) [GCC 3.2.3] ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:44 Message: Logged In: YES user_id=1188172 Adding enhanced patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:52 Message: Logged In: YES user_id=21627 Would that be the time to check that the value fits into a gid_t? I think the strategy would be this: - assign the value to grouplist[i] - read it back again - check if this is still the same value ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=1188172 Attaching patch against CVS head. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 From noreply at sourceforge.net Fri Nov 11 09:45:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 00:45:06 -0800 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 00:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Martin v. L?wis (loewis) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:45 Message: Logged In: YES user_id=1188172 Ping! ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-18 12:07 Message: Logged In: YES user_id=1188172 Attaching patch (including doc changes). For I and k, it creates an int if it fits, else a long. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:59 Message: Logged In: YES user_id=21627 I'm not sure what it should do: the other option would be to create an int if it fits, else a long. For 2.4.x atleast, this would give better backwards compatibility given the status quo. I certainly agree that the documentation should be updated. Patches are welcome. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:02 Message: Logged In: YES user_id=1188172 I think you're right. Do you too, Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Fri Nov 11 09:52:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 00:52:57 -0800 Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs Message-ID: Bugs item #1350498, was opened at 2005-11-07 17:52 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Brett Cannon (bcannon) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:52 Message: Logged In: YES user_id=1188172 www.python.org/patches says: We appreciate it if you send patches relative to the `current svn tree System Message: WARNING/2 (./index.ht, line 33); backlink Inline interpreted text or phrase reference start-string without end-string. `_. These are our latest sources. Even a patch relative to the latest alpha or beta release may be way out of date. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-11-10 22:49 Message: Logged In: YES user_id=357491 Everything but tools.html has been fixed. That doc really just needs to be replaced (see python-dev and the thread on the dev FAQ update for any discussion on the topic) and so fixing it is not on my list of things to do. =) I will leave this bug open, though, until the doc is deleted. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 06:48 Message: Logged In: YES user_id=33168 Brett, did you finish updating all these docs? Is this bug dead now? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-08 00:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 From noreply at sourceforge.net Fri Nov 11 10:28:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 01:28:35 -0800 Subject: [ python-Bugs-1353793 ] Error in documentation for os.walk Message-ID: Bugs item #1353793, was opened at 2005-11-11 10:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Geisler (mgeisler) Assigned to: Nobody/Anonymous (nobody) Summary: Error in documentation for os.walk Initial Comment: There's a mistake in the example given for os.walk on this page: http://docs.python.org/lib/os-file-dir.html The line with sum should read print sum([getsize(join(root, name)) for name in files]), with square brackets. Otherwise, thanks for the excellent documentation! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470 From noreply at sourceforge.net Fri Nov 11 15:50:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 06:50:12 -0800 Subject: [ python-Bugs-1353793 ] Error in documentation for os.walk Message-ID: Bugs item #1353793, was opened at 2005-11-11 04:28 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin Geisler (mgeisler) Assigned to: Nobody/Anonymous (nobody) Summary: Error in documentation for os.walk Initial Comment: There's a mistake in the example given for os.walk on this page: http://docs.python.org/lib/os-file-dir.html The line with sum should read print sum([getsize(join(root, name)) for name in files]), with square brackets. Otherwise, thanks for the excellent documentation! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-11-11 09:50 Message: Logged In: YES user_id=31435 Your URL is for the Python 2.4.2 docs, where the example works fine as given. If you're using an earlier version of Python, the example will not work as given (it relies on generator expressions, which were introduced in 2.4). For example, if you're using Python 2.3.5, you should look at the docs for 2.3 instead: http://www.python.org/doc/2.3.5/lib/os-file-dir.html Note that square brackets _are_ in that example, because Python 2.3.5 required them. Current Pythons (2.4+) do not, so I'm closing this as Not-A-Bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470 From noreply at sourceforge.net Fri Nov 11 15:56:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 06:56:35 -0800 Subject: [ python-Bugs-1163244 ] Syntax error on large file with MBCS encoding Message-ID: Bugs item #1163244, was opened at 2005-03-14 15:20 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 Please note that this 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.4 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Tim N. van der Leeuw (tnleeuw) >Assigned to: Mark Hammond (mhammond) Summary: Syntax error on large file with MBCS encoding Initial Comment: Large files generated by make-py.py from the win32all extensions cannot be compiled by Python2.4.1rc1 - they give a syntax error. This is a regression from 2.3.5 (With Python2.4, the interpreter crashes. That is fixed now.) Removing the mbcs encoding line from the top of the file, compilation succeeds. File should be attached, as zip-file. Probably requires win32all extensions to be installed to be compiled / imported (generated using build 203 of the win32all extensions). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-11-11 09:56 Message: Logged In: YES user_id=31435 [Mark] > I can confirm that I can no longer reproduce it > with the svn release24-maint branch Did you know 2.4.2 final was released? That happened September 28. So if someone has this problem, ask them to try the released 2.4.2 (no need to muck with release24- maint). Leaving this closed, but assigned to Mark just so he'll get this note. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-11 00:20 Message: Logged In: YES user_id=14198 Thanks Tim! I can confirm that I can no longer reproduce it with the svn release24-maint branch - so I'm going out on a limb and closing it. I haven't tested Linux, so it would be great of some others could also confirm it fixed (or reopen it if not) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-11-10 22:31 Message: Logged In: YES user_id=31435 Is this still an issue in 2.4.2? I downloaded the zip file, and didn't have any problem importing the .py file on Windows using 2.4.2. A number of problems with encoding directives were fixed in 2.4.2, so I doubt that's an accident ;-) ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 13:10 Message: Logged In: YES user_id=598066 http://sourceforge.net/tracker/? func=detail&aid=1166627&group_id=78018&atid=551954 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-08-04 03:50 Message: Logged In: YES user_id=539787 Are you sure about the bug number? pywin32 seems not to have such a bug. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-08-04 02:56 Message: Logged In: YES user_id=598066 Is pywin32 bug 1166627 relevant/related? ---------------------------------------------------------------------- Comment By: Simon Dahlbacka (sdahlbac) Date: 2005-07-21 06:38 Message: Logged In: YES user_id=750513 For what it's worth: I have two files (that I unfortunately cannot attach) which works fine on 2.3 that now on 2.4.1 produces spurious syntax errors when they have # -*- coding: ascii -*- if I change that to something that does not match the coding regex I do not get any syntax error (winxp) ---------------------------------------------------------------------- Comment By: Niki Spahiev (nikis) Date: 2005-06-02 12:11 Message: Logged In: YES user_id=27708 i have reproductable test case with encoding cp1251 file is 1594 bytes long, how to attach it? ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-04-14 19:40 Message: Logged In: YES user_id=89016 Importing foo2.py on Linux (with the current CVS HEAD version of Python) gives me a segmentation fault with the following stacktrace: 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 880 classname = inst->in_class->cl_name; (gdb) bt #0 0x080606cc in instance_repr (inst=0xb7c158bc) at Objects/classobject.c:880 #1 0x08082235 in PyObject_Repr (v=0xb7c158bc) at Objects/object.c:308 #2 0x080f3ccd in err_input (err=0xbfffe000) at Python/pythonrun.c:1478 #3 0x080f3956 in PyParser_SimpleParseFileFlags (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257, flags=0) at Python/pythonrun.c:1348 #4 0x080f3982 in PyParser_SimpleParseFile (fp=0x818d6e0, filename=0xbfffe530 "foo2.py", start=257) at Python/pythonrun.c:1355 #5 0x080e6fef in parse_source_module (pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:761 #6 0x080e72db in load_source_module (name=0xbfffe9d0 "foo2", pathname=0xbfffe530 "foo2.py", fp=0x818d6e0) at Python/import.c:885 #7 0x080e86b4 in load_module (name=0xbfffe9d0 "foo2", fp=0x818d6e0, buf=0xbfffe530 "foo2.py", type=1, loader=0x0) at Python/import.c:1656 #8 0x080e9d52 in import_submodule (mod=0x8145768, subname=0xbfffe9d0 "foo2", fullname=0xbfffe9d0 "foo2") at Python/import.c:2250 #9 0x080e9511 in load_next (mod=0x8145768, altmod=0x8145768, p_name=0xbfffedf0, buf=0xbfffe9d0 "foo2", p_buflen=0xbfffe9cc) at Python/import.c:2070 #10 0x080e8e5e in import_module_ex (name=0x0, globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1905 #11 0x080e914b in PyImport_ImportModuleEx (name=0xb7cd8824 "foo2", globals=0xb7d62e94, locals=0xb7d62e94, fromlist=0x8145768) at Python/import.c:1946 #12 0x080b5c87 in builtin___import__ (self=0x0, args=0xb7d1e634) at Python/bltinmodule.c:45 #13 0x0811d32e in PyCFunction_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/methodobject.c:73 #14 0x0805d188 in PyObject_Call (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Objects/abstract.c:1757 #15 0x080ca79d in PyEval_CallObjectWithKeywords (func=0xb7d523ec, arg=0xb7d1e634, kw=0x0) at Python/ceval.c:3425 #16 0x080c6719 in PyEval_EvalFrame (f=0x816dd7c) at Python/ceval.c:2026 #17 0x080c8fdd in PyEval_EvalCodeEx (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2736 #18 0x080bffb0 in PyEval_EvalCode (co=0xb7cf1ef0, globals=0xb7d62e94, locals=0xb7d62e94) at Python/ceval.c:490 #19 0x080f361d in run_node (n=0xb7d122d0, filename=0x8123ba3 "", globals=0xb7d62e94, locals=0xb7d62e94, flags=0xbffff584) at Python/pythonrun.c:1265 #20 0x080f1f58 in PyRun_InteractiveOneFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:762 #21 0x080f1c93 in PyRun_InteractiveLoopFlags (fp=0xb7e94720, filename=0x8123ba3 "", flags=0xbffff584) at Python/pythonrun.c:695 #22 0x080f1af6 in PyRun_AnyFileExFlags (fp=0xb7e94720, filename=0x8123ba3 "", closeit=0, flags=0xbffff584) at Python/pythonrun.c:658 #23 0x08055e45 in Py_Main (argc=1, argv=0xbffff634) at Modules/main.c:484 #24 0x08055366 in main (argc=1, argv=0xbffff634) at Modules/python.c:23 The value object in err_input() (in the E_DECODE case) seems to be bogus (it gives me a refcount of -606348325). ---------------------------------------------------------------------- Comment By: Timo Linna (tilinna) Date: 2005-04-09 04:09 Message: Logged In: YES user_id=1074183 Seems that the connection to n*512 blocks is very likely, and it's not just MBCS-related. I managed to reproduce this with a file that contains an ascii-coding declaration, close-to-1024 bytes section, extra crlf and a comment which raises a SyntaxError in Py2.4.1. Could this be linked to the new codec buffering code? See: www.python.org/sf/1178484 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-21 08:34 Message: Logged In: YES user_id=539787 Could be irrelevant but... are the other block sizes close to n*512 (eg 1536 is 3*512) marks? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-21 07:11 Message: Logged In: YES user_id=14198 I believe this is a different bug than the recent "long-lines" errors (see below). I can reproduce this with a file that uses neither long lines, nor any pywin32 extensions (2.4 branch, trunk) A Python source file containing: -- start snippet -- # -*- coding: mbcs -*- <1532 characters of code or comments> x = {} -- end snippet -- Will yield a SyntaxError when attempting to import the module. Running the module as a script does not provoke the error. To reproduce, there must be exactly 1532 characters where specified (see the attached file for a demo). Adding or removing even a single character will prevent the error. It is possible to replace characters with any others, including valid code, and still see the error - however, the number of characters must remain the same .cr/lf pairs can also be replaced with any other 2 characters. There are other "block sizes" that will provoke the error, but this is the only one I have nailed. Apart from the "block" of 1532 characters, the coding line and the blank line before the dict assignment also appear critical. Unlike the other characters in the block, this last cr/lf pair can not be replaced with comments. I can't provoke the error with other encodings (note there are no encoded characters in the sample - it is trivial). To reproduce, save the attached file on Windows and execute: > python -c "import foo2" Traceback (most recent call last): File "", line 1, in ? File "foo2.py", line 24 x = {} ^ SyntaxError: invalid syntax Note that Python 2.3 and earlier all work. Also note that "python foo2.py" also works. The code is clearly valid. Haven't tried to repro on Linux (mbcs isn't available there, and I can't get a test case that doesn't use it) Other pointers/notes: pywin32 bug 1085454 is related to long-lines, by all accounts that underlying error has been fixed - I can't verify this as pywin32 no longer generates insanely long lines. I can confirm Python bugs 1101726/1089395 still crashes Python 2.3+. I believe all (including this) are discrete bugs. [foo2.py is my attachment - ya gotta love sourceforge :)] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2005-03-20 05:28 Message: Logged In: YES user_id=539787 Useful pointers: in Python-dev, this has been characterised as related to pywin32 bug 1085454. Also related to www.python.org/sf/1101726 and www.python.org/sf/1089395. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470 From noreply at sourceforge.net Fri Nov 11 16:03:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 07:03:40 -0800 Subject: [ python-Bugs-1354052 ] logging: Default handlers broken Message-ID: Bugs item #1354052, was opened at 2005-11-11 10:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan S. Joseph (jsjoseph) Assigned to: Nobody/Anonymous (nobody) Summary: logging: Default handlers broken Initial Comment: Hi, There is a strange behaviour in logging. When a new logger is created, its doesn't have any handlers... until the root logger is invoked, at which point the new logger uses the same handler as the root handler. See the following code snippet as an illustration of the bug: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import * >>> z = getLogger("z") >>> z.warning("The Larch.") No handlers could be found for logger "z" >>> warning("Bicycle Repair Man!") WARNING:root:Bicycle Repair Man! >>> z.warning("The Larch.") WARNING:z:The Larch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470 From noreply at sourceforge.net Fri Nov 11 17:13:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 08:13:29 -0800 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 12:49 Message generated for change (Comment added) made by bheld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule)?; Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. ---------------------------------------------------------------------- >Comment By: Ben Held (bheld) Date: 2005-11-11 16:13 Message: Logged In: YES user_id=1327580 Turns out this is not a Python issue, but a SWIG issue. It only leaks for modules that were created with SWIG. Please close this item ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 06:02 Message: Logged In: YES user_id=33168 I just tested with Python 2.4.2 on Linux with valgrind. It doesn't report any leaks. So this could be specific to Python 2.3.5, Windows, VC++ 6.0 or some other variation. Can you provide more info? For example, what module are you passing on the command line? Can you provide that code? What objects specifically do you think are leaking? Where were they allocated? ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-09-14 18:09 Message: Logged In: YES user_id=1327580 This behavior is evident with Python 2.3.5 built on Windows with VC++ 6.0. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2005-09-14 17:53 Message: Logged In: YES user_id=1344176 I've been unable to verify this on Linux. I've tested python versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5 on Debian 3.1 under kernel 2.6.8. I used the sample program provided by Ben, modified with an infinite loop over the PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for 1 second after every 25 iterations. I tested reloading the modules distutils, os.path, distutils.command.sdist for 300+ iterations each under each python version. No memory leak was observed. ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-08-16 13:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 13:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Fri Nov 11 18:47:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 09:47:44 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Mark Hirota (markhirota) Date: 2005-11-11 09:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 14:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Fri Nov 11 19:21:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 10:21:13 -0800 Subject: [ python-Bugs-1354265 ] Interactive help fails with Windows Installer Message-ID: Bugs item #1354265, was opened at 2005-11-11 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=105470&aid=1354265&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help fails with Windows Installer Initial Comment: help> SPECIALMETHODS Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. help> The problem appears to be that the MS Help .chm is used and no HTML docs are provided. Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&group_id=5470 From noreply at sourceforge.net Fri Nov 11 20:46:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 11:46:55 -0800 Subject: [ python-Bugs-1256669 ] Significant memory leak with PyImport_ReloadModule Message-ID: Bugs item #1256669, was opened at 2005-08-11 14:49 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Ben Held (bheld) Assigned to: Nobody/Anonymous (nobody) Summary: Significant memory leak with PyImport_ReloadModule Initial Comment: Having recently upgraded to Python 2.4, I am having a large memory leak with the following code built with VC++ 6.0: PyObject *pName, *pModule; Py_Initialize(); pName = PyString_FromString(argv[1]); pModule = PyImport_Import(pName); Py_DECREF(pName); PyObject* pModule2 = PyImport_ReloadModule(pModule)?; Py_DECREF(pModule2); Py_DECREF(pModule); Py_Finalize(); return 0; I get leaks of over 500 kb. I have another program which is much more complex, in which every call to PyImport_ReloadModule is leaking 200+ kb, even though I am calling Py_DECREF correctly. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 20:46 Message: Logged In: YES user_id=1188172 Closing as requested. ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-11-11 17:13 Message: Logged In: YES user_id=1327580 Turns out this is not a Python issue, but a SWIG issue. It only leaks for modules that were created with SWIG. Please close this item ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-20 08:02 Message: Logged In: YES user_id=33168 I just tested with Python 2.4.2 on Linux with valgrind. It doesn't report any leaks. So this could be specific to Python 2.3.5, Windows, VC++ 6.0 or some other variation. Can you provide more info? For example, what module are you passing on the command line? Can you provide that code? What objects specifically do you think are leaking? Where were they allocated? ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-09-14 20:09 Message: Logged In: YES user_id=1327580 This behavior is evident with Python 2.3.5 built on Windows with VC++ 6.0. ---------------------------------------------------------------------- Comment By: Collin Winter (collinwinter) Date: 2005-09-14 19:53 Message: Logged In: YES user_id=1344176 I've been unable to verify this on Linux. I've tested python versions 2.2.3, 2.3.5 and 2.4.1, all compiled with gcc 3.3.5 on Debian 3.1 under kernel 2.6.8. I used the sample program provided by Ben, modified with an infinite loop over the PyImport_ReloadModule/PyDECREF(pModule2) lines, sleeping for 1 second after every 25 iterations. I tested reloading the modules distutils, os.path, distutils.command.sdist for 300+ iterations each under each python version. No memory leak was observed. ---------------------------------------------------------------------- Comment By: Ben Held (bheld) Date: 2005-08-16 15:56 Message: Logged In: YES user_id=1327580 Boundschecker shows the leak and I have verified this by watching the process memory increase via the task manager. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-08-13 15:34 Message: Logged In: YES user_id=21627 How do you know there is a memory leak? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1256669&group_id=5470 From noreply at sourceforge.net Fri Nov 11 20:50:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 11:50:06 -0800 Subject: [ python-Bugs-1328278 ] __getslice__ taking priority over __getitem__ Message-ID: Bugs item #1328278, was opened at 2005-10-17 03:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Josh Marshall (jpmarshall) Assigned to: Nobody/Anonymous (nobody) Summary: __getslice__ taking priority over __getitem__ Initial Comment: When creating a class that uses __getitem__ to implement slicing, if __getattr__ is also implemented, slicing will fail. This is due to the (deprecated) __getslice__ method being called before __getitem__. The attached file demonstrates this. If __getitem__ is implemented on its own, all is rosy. When we add __getattr__ and do not raise an AttributeError when __getslice__ is searched for, the slicing fails. If we raise this AttributeError, __getitem__ is called next. The only other reference I could find to this bug is on the jython mailing list, from 2003: http://sourceforge.net/mailarchive/forum.php? thread_id=2350972&forum_id=5586 My question is; why is __getslice__ called before __getitem__? I assumed that because it is deprecated, it would be the last resort for a slicing. Is this planned to be fixed, or is there existing behaviour that is reliant on it? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 20:50 Message: Logged In: YES user_id=1188172 You're correct. __getslice__ is supported for backwards compatibility, and its semantics cannot change (before 3.0, that is). ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-10 15:48 Message: Logged In: YES user_id=315535 This seems to be the documented, expected behavior: http://www.python.org/doc/2.4.2/ref/sequence-methods.html As to _why_ __getslice__ is called before __getitem__, I'm not sure - but it's right there in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1328278&group_id=5470 From noreply at sourceforge.net Fri Nov 11 21:24:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 12:24:29 -0800 Subject: [ python-Bugs-1350498 ] CVS migration not in www.python.org docs Message-ID: Bugs item #1350498, was opened at 2005-11-07 08:52 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Brett Cannon (bcannon) Summary: CVS migration not in www.python.org docs Initial Comment: The development head has recently moved from CVS on sourceforge to subversion on python.org. The www.python.org documentation still sends people to the sourceforge cvs via (1) The left hand navigation link (main page) under Documenation section, python project, cvs. (The similar link on http://www.python.org/dev/ has been updated.) (2) The text of http://www.python.org/dev/ still says that deveopment takes place on sourceforge and sends people to the sourceforge cvs browser It also includes a link to (sourceforge) CVS instructions, but no mention of subversion. (3) The tools link then points to http://www.python. org/dev/tools.html, which still refers to CVS and CVS instructions. (4) The developer FAQ (http://www.python.org/dev/ devfaq.html) contains sections 1.2 and 1.4 for subversion (combine them?) and 1.3 for CVS -- section 1.3 seems to imply that the CVS tree is still active. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-11-11 12:24 Message: Logged In: YES user_id=357491 Fixed. Thanks, Reinhold. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 00:52 Message: Logged In: YES user_id=1188172 www.python.org/patches says: We appreciate it if you send patches relative to the `current svn tree System Message: WARNING/2 (./index.ht, line 33); backlink Inline interpreted text or phrase reference start-string without end-string. `_. These are our latest sources. Even a patch relative to the latest alpha or beta release may be way out of date. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-11-10 13:49 Message: Logged In: YES user_id=357491 Everything but tools.html has been fixed. That doc really just needs to be replaced (see python-dev and the thread on the dev FAQ update for any discussion on the topic) and so fixing it is not on my list of things to do. =) I will leave this bug open, though, until the doc is deleted. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-09 21:48 Message: Logged In: YES user_id=33168 Brett, did you finish updating all these docs? Is this bug dead now? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-07 15:19 Message: Logged In: YES user_id=21627 I fixed the first two. The latter will be modified later this year, or next year. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350498&group_id=5470 From noreply at sourceforge.net Sat Nov 12 00:41:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 15:41:29 -0800 Subject: [ python-Bugs-1353793 ] Error in documentation for os.walk Message-ID: Bugs item #1353793, was opened at 2005-11-11 10:28 Message generated for change (Comment added) made by mgeisler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470 Please note that this 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: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Martin Geisler (mgeisler) Assigned to: Nobody/Anonymous (nobody) Summary: Error in documentation for os.walk Initial Comment: There's a mistake in the example given for os.walk on this page: http://docs.python.org/lib/os-file-dir.html The line with sum should read print sum([getsize(join(root, name)) for name in files]), with square brackets. Otherwise, thanks for the excellent documentation! ---------------------------------------------------------------------- >Comment By: Martin Geisler (mgeisler) Date: 2005-11-12 00:41 Message: Logged In: YES user_id=1264592 Ups, I'm sorry for the noise then... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-11-11 15:50 Message: Logged In: YES user_id=31435 Your URL is for the Python 2.4.2 docs, where the example works fine as given. If you're using an earlier version of Python, the example will not work as given (it relies on generator expressions, which were introduced in 2.4). For example, if you're using Python 2.3.5, you should look at the docs for 2.3 instead: http://www.python.org/doc/2.3.5/lib/os-file-dir.html Note that square brackets _are_ in that example, because Python 2.3.5 required them. Current Pythons (2.4+) do not, so I'm closing this as Not-A-Bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353793&group_id=5470 From noreply at sourceforge.net Sat Nov 12 02:51:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 17:51:33 -0800 Subject: [ python-Bugs-1354052 ] logging: Default handlers broken Message-ID: Bugs item #1354052, was opened at 2005-11-11 07:03 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jonathan S. Joseph (jsjoseph) >Assigned to: Vinay Sajip (vsajip) Summary: logging: Default handlers broken Initial Comment: Hi, There is a strange behaviour in logging. When a new logger is created, its doesn't have any handlers... until the root logger is invoked, at which point the new logger uses the same handler as the root handler. See the following code snippet as an illustration of the bug: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import * >>> z = getLogger("z") >>> z.warning("The Larch.") No handlers could be found for logger "z" >>> warning("Bicycle Repair Man!") WARNING:root:Bicycle Repair Man! >>> z.warning("The Larch.") WARNING:z:The Larch. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-11 17:51 Message: Logged In: YES user_id=33168 This may have been fixed recently. Vinay? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470 From noreply at sourceforge.net Sat Nov 12 03:51:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Nov 2005 18:51:54 -0800 Subject: [ python-Bugs-1354052 ] logging: Default handlers broken Message-ID: Bugs item #1354052, was opened at 2005-11-11 15:03 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jonathan S. Joseph (jsjoseph) Assigned to: Vinay Sajip (vsajip) Summary: logging: Default handlers broken Initial Comment: Hi, There is a strange behaviour in logging. When a new logger is created, its doesn't have any handlers... until the root logger is invoked, at which point the new logger uses the same handler as the root handler. See the following code snippet as an illustration of the bug: Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from logging import * >>> z = getLogger("z") >>> z.warning("The Larch.") No handlers could be found for logger "z" >>> warning("Bicycle Repair Man!") WARNING:root:Bicycle Repair Man! >>> z.warning("The Larch.") WARNING:z:The Larch. ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2005-11-12 02:51 Message: Logged In: YES user_id=308438 This is not a bug, this is by design. See the documentation for basicConfig() in http://docs.python.org/lib/module-logging.html where you will see that the module-level convenience functions (debug(), info(), warning(), etc.) call basicConfig() automatically if the root logger has no handlers. The idea is, if you are using the convenience functions, you will be using logging in a simple way - hence, basicConfig() is called for you. If you had used the root logger directly, e.g. after from logging import * by using getLogger().warning("Bicycle Repair Man!") rather than warning("Bicycle Repair Man!") then no handlers would have been added. You would not have received the "No handlers could be found", as that is a one-off message. In the latest revisions, if you set raiseExceptions to 0 (typically for production, not development) then that message is suppressed completely. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-12 01:51 Message: Logged In: YES user_id=33168 This may have been fixed recently. Vinay? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354052&group_id=5470 From noreply at sourceforge.net Sat Nov 12 11:28:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 02:28:04 -0800 Subject: [ python-Bugs-1346547 ] _subprocess.c calls PyInt_AsLong without error checking Message-ID: Bugs item #1346547, was opened at 2005-11-03 03:34 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Luke (luked) Assigned to: Fredrik Lundh (effbot) Summary: _subprocess.c calls PyInt_AsLong without error checking Initial Comment: _subprocess.c calls PyInt_AsLong without checking whether the conversion produced an error. This bug can cause an error to be reported at the wrong point, eg: Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> si = subprocess.STARTUPINFO() >>> si.wShowWindow = 2**65 >>> obj = subprocess.Popen('notepad.exe', startupinfo=si) >>> 1+1 OverflowError: long int too large to convert to int >>> ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:28 Message: Logged In: YES user_id=38376 Fixed along with #1351997. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-10 23:43 Message: Logged In: YES user_id=38376 I've added a fix to the subprocess patch over at http://www.python.org/sf/1351997 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-03 06:20 Message: Logged In: YES user_id=33168 This code (for startupinfo) is only valid on Windows. The problem seems to be at lines 379 and 380 in PC/_subprocess.c. I'll let someone who can test this one take care of it. The return result from getint() needs to be checked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346547&group_id=5470 From noreply at sourceforge.net Sat Nov 12 11:32:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 02:32:40 -0800 Subject: [ python-Bugs-1349316 ] xmlrpclib does not use http proxy Message-ID: Bugs item #1349316, was opened at 2005-11-06 03:07 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: greatred (greatred) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib does not use http proxy Initial Comment: The xmlrpclib class ServerProxy does not seem to be able to make use of a HTTP proxy. This makes it unusable behind a firewall where the proxy is the only access to the destination server. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:32 Message: Logged In: YES user_id=38376 To handle this, you can use a custom transport. Here's an example: http://lowlife.jp/nobonobo/wiki/xmlrpcwithproxy.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349316&group_id=5470 From noreply at sourceforge.net Sat Nov 12 11:57:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 02:57:40 -0800 Subject: [ python-Bugs-1316069 ] gzip.GzipFile.seek missing second argument Message-ID: Bugs item #1316069, was opened at 2005-10-07 21:34 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile.seek missing second argument Initial Comment: It would nice if GzipFile.seek matched file.seek and BZ2File.seek and took a second argument. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:57 Message: Logged In: YES user_id=38376 I've posted a trivial patch over at www.python.org/sf/1355023 (can patches be attached to bugs, or do we always want them over at the patch tracker?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 From noreply at sourceforge.net Sat Nov 12 12:05:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 03:05:38 -0800 Subject: [ python-Bugs-1296433 ] expat crash python Message-ID: Bugs item #1296433, was opened at 2005-09-20 16:10 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 6 Submitted By: Mike Rozhnov (rozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: expat crash python Initial Comment: This simple script crash python. Parsing of commented xml string work good. (i.e. raised exception not crash python) Buffer overflow during convertion to unicode? Tested on Win XP and linux with kernel 2.4 with same results. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 12:05 Message: Logged In: YES user_id=38376 Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with expat 1.95.8). Try upgrading your expat and see if the problem goes away. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 23:54 Message: Logged In: YES user_id=33168 I can reproduce on Linux with current CVS and expat 1.95.5-2. Note the size of the data only needs to be greater than 1024. xml = "%s" % ('a' * 1025) I am not certain this problem is specific to Python. It might be down in expat only. Need to investigate further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 From noreply at sourceforge.net Sat Nov 12 14:18:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 05:18:41 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 16:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Skip Montanaro (montanaro) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 07:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-11 01:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Sat Nov 12 16:49:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 07:49:46 -0800 Subject: [ python-Bugs-1343671 ] Broken docs for os.removedirs Message-ID: Bugs item #1343671, was opened at 2005-10-31 12:30 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 Please note that this 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: David K?gedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:49 Message: Logged In: YES user_id=38376 Are you sure you understand how the function works? Given "spam/egg/bacon", it first attempts to do an rmdir on spam/egg/bacon. If that fails, the function raises an exception. Otherwise, it proceeds to rmdir spam/egg and spam. Errors during the latter stage are ignored. If you want to remove directories whether they're empty or not, use shutil.rmtree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 From noreply at sourceforge.net Sat Nov 12 16:54:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 07:54:22 -0800 Subject: [ python-Bugs-1343671 ] Broken docs for os.removedirs Message-ID: Bugs item #1343671, was opened at 2005-10-31 12:30 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 Please note that this 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: David K?gedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:54 Message: Logged In: YES user_id=38376 (I've changed the docstring from "remove a leaf directory and empty all intermediate ones" to "remove a leaf directory and all empty intermediate ones". both the docstring and the docs could need some clarification, but the text you propose is not really an improvement...) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:49 Message: Logged In: YES user_id=38376 Are you sure you understand how the function works? Given "spam/egg/bacon", it first attempts to do an rmdir on spam/egg/bacon. If that fails, the function raises an exception. Otherwise, it proceeds to rmdir spam/egg and spam. Errors during the latter stage are ignored. If you want to remove directories whether they're empty or not, use shutil.rmtree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 From noreply at sourceforge.net Sat Nov 12 17:43:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 08:43:53 -0800 Subject: [ python-Bugs-1261714 ] precompiled code and nameError. Message-ID: Bugs item #1261714, was opened at 2005-08-17 08:50 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Menshakov (megath) Assigned to: Nobody/Anonymous (nobody) Summary: precompiled code and nameError. Initial Comment: i experienced problem with call'ing python unmarshalled and eval'ed code. similar problem described in mailing list, but unfortunately has not got any solution or work-around. http://mail.python.org/pipermail/c++-sig/2003-October/006094.html actually I have code like this: ------------- import m class A: def do(self): print m.User().GetName() ------------ test.py a = A() a.do() running script from python works perfectly. but when I call 'do' from c++ code I get following error : PyObject_CallMethod: exceptions.NameError:global name 'm' is not defined I checked locals dictionary, it contains missing name ('m'). ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 17:43 Message: Logged In: YES user_id=38376 How do you call "do" from your C++ code? "m" isn't a local variable, so what you stuff into the locals directory doesn't matter; the important thing is that the module associated with the function (A.do.im_func.func_globals) contains the right thing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 08:30 Message: Logged In: YES user_id=33168 Can you provide the c++ code? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261714&group_id=5470 From noreply at sourceforge.net Sat Nov 12 17:59:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 08:59:15 -0800 Subject: [ python-Bugs-1177811 ] Exec Inside A Function Message-ID: Bugs item #1177811, was opened at 2005-04-06 16:30 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Wilkinson (andrew_j_w) Assigned to: Nobody/Anonymous (nobody) Summary: Exec Inside A Function Initial Comment: When 'exec'ing code that creates a function inside a function the defined function (fact in the example below) is created with the module level namespace as it's parent scope. The following should return 2 however it raises a NameError as fact is not defined. def f(): ? ? exec """ def fact(x): ? ? if x==1: ? ? ? ? return 1 ? ? else: ? ? ? ? return x*fact(x-1) """ ? ? return fact f()(2) If you run following code... def f(): ? ? exec """ def fact(x): ? ? if x==1: ? ? ? ? return 1 ? ? else: ? ? ? ? return x*fact(x-1) """ in locals() ? ? return fact ... it works as expected. The documentation states that "In all cases, if the optional parts are omitted, the code is executed in the current scope." That is clearly not the case here as the 'fact' function is set with the module level scope as it's parent scope. It would appear to me that either this a documentation bug or a flaw in exec. I sincerely hope this a bug in exec and not the desired behaviour as it doesn't make any sense to me... ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 17:59 Message: Logged In: YES user_id=38376 As described in the language reference, scope analysis is done statically, during compilation. If the compiler cannot see your innermost function (because you've hidden it inside a string literal), it obviously cannot take any variables in there into account when generating code for the outer scopes. (I sincerely hope that this is a contrived example, and that you're not trying to use exec in this way in real code. Python might be a highly dynamic language, but it's not this dynamic.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177811&group_id=5470 From noreply at sourceforge.net Sat Nov 12 20:29:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 11:29:16 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 20:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Sat Nov 12 21:02:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 12:02:10 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 16:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 15:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 14:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 12:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 17:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 16:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Sat Nov 12 21:05:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 12:05:52 -0800 Subject: [ python-Bugs-1092701 ] os.remove fails on win32 with read-only file Message-ID: Bugs item #1092701, was opened at 2004-12-29 15:30 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092701&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: Joshua Weage (jpweage) Assigned to: Nobody/Anonymous (nobody) Summary: os.remove fails on win32 with read-only file Initial Comment: On Windows XP SP2 and Python 2.3.3 or 2.4 a call to os.remove returns Errno 13 permission denied on a read-only file. On linux, python will delete a read-only file. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 21:05 Message: Logged In: YES user_id=38376 No followups in over 6 months. Closing. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-02-14 12:31 Message: Logged In: YES user_id=38376 This is a platform issue; Windows associates delete privileges with the file, Unix with the directory. I doubt it's a good idea to "fix" Python's remove by making it incompatible with the C library's implementation. (on the C level, unlink() is the same thing as remove(), btw). ---------------------------------------------------------------------- Comment By: Robert Brewer (aminusfu) Date: 2005-01-01 10:13 Message: Logged In: YES user_id=967320 Yup. I can reproduce that on Win2k. Seems posixmodule.c uses _unlink, _wunlink, which are documented at MS as failing on readonly: "Each of these functions returns 0 if successful. Otherwise, the function returns ?1 and sets errno to EACCES, which means the path specifies a read-only file, or to ENOENT, which means the file or path is not found or the path specified a directory." Seems others have "fixed" it by just changing the mode and trying again: http://sources.redhat.com/ml/cygwin/2001-05/msg01209.html https://www.cvshome.org/cyclic/cvs/unoff-watcom.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1092701&group_id=5470 From noreply at sourceforge.net Sat Nov 12 21:53:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 12:53:12 -0800 Subject: [ python-Bugs-1296433 ] expat crash python Message-ID: Bugs item #1296433, was opened at 2005-09-20 07:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 6 Submitted By: Mike Rozhnov (rozhnov) Assigned to: Nobody/Anonymous (nobody) Summary: expat crash python Initial Comment: This simple script crash python. Parsing of commented xml string work good. (i.e. raised exception not crash python) Buffer overflow during convertion to unicode? Tested on Win XP and linux with kernel 2.4 with same results. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-12 12:53 Message: Logged In: YES user_id=33168 I had recently upgraded to expat 1.95.8, so I was hopeful. But it still crashed for me on linux. I did get a better stack trace which allowed me to come up with a patch that solves the problem and passes all the tests. The patch seems a bit odd and I think there might be another problem going on here. It would be great if someone more familiar with xmlparse could take a look at the patch and figure out if it's right or not. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 03:05 Message: Logged In: YES user_id=38376 Works for me under 2.3.2 (with expat 1.95.6) and 2.4.1 (with expat 1.95.8). Try upgrading your expat and see if the problem goes away. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 14:54 Message: Logged In: YES user_id=33168 I can reproduce on Linux with current CVS and expat 1.95.5-2. Note the size of the data only needs to be greater than 1024. xml = "%s" % ('a' * 1025) I am not certain this problem is specific to Python. It might be down in expat only. Need to investigate further. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296433&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:14:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:14:17 -0800 Subject: [ python-Bugs-1355826 ] shutil.move() does not preserve ownership Message-ID: Bugs item #1355826, was opened at 2005-11-13 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355826&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: lightweight (sprif) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move() does not preserve ownership Initial Comment: shutil.move() does not preserve file and directory ownership when moving a whole directory tree to a different filesystem. This does not happen when shutil.move() is used to move a directory tree within the same filesystem. Version: python 2.4.2 I have had a look at the source code in shutil.py and noticed that shutil.copystat() does not copy the ownership information, whereas "stat" command does output information about the ownership (on GNU/Linux at least). The only discussion I found refering to file / directory ownership and possible security implications (if any) can be found here: http://mail.python.org/pipermail/python-bugs-list/2004-November/025985.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355826&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:16:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:16:11 -0800 Subject: [ python-Bugs-869197 ] setgroups rejects long integer arguments Message-ID: Bugs item #869197, was opened at 2004-01-02 10:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: setgroups rejects long integer arguments Initial Comment: os.setgroups ought to accept long integer arguments, just as os.setgid does. I think this worked in an earlier version of Python - or maybe it was that string.atol used to return a non-long integer if the number was small enough, so I didn't encounter long integers at all. >>> import os >>> os.setgid(1L) >>> os.setgroups((1L,)) Traceback (most recent call last): File "", line 1, in ? TypeError: groups must be integers >>> import sys >>> print sys.version 2.3.3 (#1, Dec 30 2003, 22:52:56) [GCC 3.2.3] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:16 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. Please remove the unused variable check, though. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:44 Message: Logged In: YES user_id=1188172 Adding enhanced patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:52 Message: Logged In: YES user_id=21627 Would that be the time to check that the value fits into a gid_t? I think the strategy would be this: - assign the value to grouplist[i] - read it back again - check if this is still the same value ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=1188172 Attaching patch against CVS head. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:20:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:20:53 -0800 Subject: [ python-Bugs-1354265 ] Interactive help fails with Windows Installer Message-ID: Bugs item #1354265, was opened at 2005-11-11 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help fails with Windows Installer Initial Comment: help> SPECIALMETHODS Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. help> The problem appears to be that the MS Help .chm is used and no HTML docs are provided. Colin W. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:20 Message: Logged In: YES user_id=21627 That is deliberate; you have to download the HTML documentation manually, from http://docs.python.org/download.html Alternatively, just invoke hh -decompile c:\python24\doc\html c:\python24\python24.chm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:31:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:31:27 -0800 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 00:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Adal Chiriliuc (adalx) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:31 Message: Logged In: YES user_id=21627 The patch looks wrong: for 'I' (capital i), you va_arg unsigned long; I think 'I' should do unsigned int instead. A minor nit: why does it move the 'l' case (lower L)? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:45 Message: Logged In: YES user_id=1188172 Ping! ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-18 12:07 Message: Logged In: YES user_id=1188172 Attaching patch (including doc changes). For I and k, it creates an int if it fits, else a long. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:59 Message: Logged In: YES user_id=21627 I'm not sure what it should do: the other option would be to create an int if it fits, else a long. For 2.4.x atleast, this would give better backwards compatibility given the status quo. I certainly agree that the documentation should be updated. Patches are welcome. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:02 Message: Logged In: YES user_id=1188172 I think you're right. Do you too, Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Sun Nov 13 11:45:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 02:45:52 -0800 Subject: [ python-Bugs-1316069 ] gzip.GzipFile.seek missing second argument Message-ID: Bugs item #1316069, was opened at 2005-10-07 21:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile.seek missing second argument Initial Comment: It would nice if GzipFile.seek matched file.seek and BZ2File.seek and took a second argument. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:45 Message: Logged In: YES user_id=21627 Patches can (and should) be attached to the bugs if possible. With SF access control, only the submitter and a patch admin may do so, though. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:57 Message: Logged In: YES user_id=38376 I've posted a trivial patch over at www.python.org/sf/1355023 (can patches be attached to bugs, or do we always want them over at the patch tracker?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 From noreply at sourceforge.net Sun Nov 13 12:17:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 03:17:39 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 11:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Sun Nov 13 14:27:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 05:27:11 -0800 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 07:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Sun Nov 13 15:01:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 06:01:33 -0800 Subject: [ python-Bugs-1354265 ] Interactive help fails with Windows Installer Message-ID: Bugs item #1354265, was opened at 2005-11-11 13:21 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help fails with Windows Installer Initial Comment: help> SPECIALMETHODS Sorry, topic and keyword documentation is not available because the Python HTML documentation files could not be found. If you have installed them, please set the environment variable PYTHONDOCS to indicate their location. help> The problem appears to be that the MS Help .chm is used and no HTML docs are provided. Colin W. ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-11-13 09:01 Message: Logged In: YES user_id=285587 Many thanks, the hh -decompile method is simple. Maybe a note could be added to the Windows installer, or perhaps the installer could do it. Incidentally, for my machine, the command was: hh -decompile c:\python24\doc\html c:\python24\Doc\python24.chm ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 05:20 Message: Logged In: YES user_id=21627 That is deliberate; you have to download the HTML documentation manually, from http://docs.python.org/download.html Alternatively, just invoke hh -decompile c:\python24\doc\html c:\python24\python24.chm ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1354265&group_id=5470 From noreply at sourceforge.net Sun Nov 13 15:41:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 06:41:02 -0800 Subject: [ python-Bugs-1355903 ] Division Error Message-ID: Bugs item #1355903, was opened at 2005-11-13 14:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Azimuth (azimuth84) Assigned to: Nobody/Anonymous (nobody) Summary: Division Error Initial Comment: The division operation "7.0/5" yields 1.399999 instead of 1.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355903&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:52:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:52:07 -0800 Subject: [ python-Bugs-1355903 ] Division Error Message-ID: Bugs item #1355903, was opened at 2005-11-13 15:41 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Azimuth (azimuth84) Assigned to: Nobody/Anonymous (nobody) Summary: Division Error Initial Comment: The division operation "7.0/5" yields 1.399999 instead of 1.4 ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-13 16:52 Message: Logged In: YES user_id=38376 This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for more information: http://www.python.org/doc/2.2.1/tut/node14.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355903&group_id=5470 From noreply at sourceforge.net Sun Nov 13 16:54:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 07:54:07 -0800 Subject: [ python-Bugs-1343671 ] Broken docs for os.removedirs Message-ID: Bugs item #1343671, was opened at 2005-10-31 12:30 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 Please note that this 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: 3 Submitted By: David K?gedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:54 Message: Logged In: YES user_id=38376 (I've changed the docstring from "remove a leaf directory and empty all intermediate ones" to "remove a leaf directory and all empty intermediate ones". both the docstring and the docs could need some clarification, but the text you propose is not really an improvement...) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:49 Message: Logged In: YES user_id=38376 Are you sure you understand how the function works? Given "spam/egg/bacon", it first attempts to do an rmdir on spam/egg/bacon. If that fails, the function raises an exception. Otherwise, it proceeds to rmdir spam/egg and spam. Errors during the latter stage are ignored. If you want to remove directories whether they're empty or not, use shutil.rmtree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:24:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:24:56 -0800 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 23:27 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 02:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:44:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:44:11 -0800 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 07:27 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-13 10:44 Message: Logged In: YES user_id=44345 I was thinking it might be something like that. Perhaps asdl_c.py should be modified to accept an output flag (--output=[hc] or -h/-c) so it only generates one file or the other. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-13 10:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:45:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:45:29 -0800 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 23:27 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 02:45 Message: Logged In: YES user_id=315535 Already on it :) Shall have a patch up shortly. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 02:44 Message: Logged In: YES user_id=44345 I was thinking it might be something like that. Perhaps asdl_c.py should be modified to accept an output flag (--output=[hc] or -h/-c) so it only generates one file or the other. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 02:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Sun Nov 13 17:58:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 08:58:01 -0800 Subject: [ python-Bugs-1355883 ] make depend/clean issues w/ ast Message-ID: Bugs item #1355883, was opened at 2005-11-13 23:27 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: make depend/clean issues w/ ast Initial Comment: I noticed two issues with the ast vis a vis building and cleaning. Haven't had a chance to look into them, however... 1. From a fresh checkout, execute configure, then "make -j2". It will run Parser/asdl_c.py twice simultaneously. This can obviously lead to corrupt Python-ast.[ch] files. 2. Neither "make clean" nor "make distclean" delete the Python-ast.[ch] files. "make distclean" at least should. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 02:58 Message: Logged In: YES user_id=315535 Fix for part 1 here: http://sourceforge.net/tracker/index.php?func=detail&aid=1355971&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 02:45 Message: Logged In: YES user_id=315535 Already on it :) Shall have a patch up shortly. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 02:44 Message: Logged In: YES user_id=44345 I was thinking it might be something like that. Perhaps asdl_c.py should be modified to accept an output flag (--output=[hc] or -h/-c) so it only generates one file or the other. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-14 02:24 Message: Logged In: YES user_id=315535 The first problem is being caused by a simple misunderstanding/oversight in Makefile.pre.in. The rule for a target will be called for each target. In our case, we have Python-ast.h and Python-ast.c in our list of targets. So asdl_c.py gets called once for each target. Hope this makes sense. :) If not I can bang up a patch so you can at least see what I'm on about. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&group_id=5470 From noreply at sourceforge.net Sun Nov 13 22:11:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 13:11:29 -0800 Subject: [ python-Bugs-1343671 ] Broken docs for os.removedirs Message-ID: Bugs item #1343671, was opened at 2005-10-31 12:30 Message generated for change (Comment added) made by d_kagedal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 Please note that this 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: 3 Submitted By: David K?gedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. ---------------------------------------------------------------------- >Comment By: David K?gedal (d_kagedal) Date: 2005-11-13 22:11 Message: Logged In: YES user_id=1260741 > Are you sure you understand how the function works? No I'm not. But that's the whole point of this bug report. Reading the documentation didn't help. Saying "Removes directories recursively" means something different to me than what you describe, so I think it's easy to mislead already there. When it sans that "rightmost path segments will be pruned away", that doesn't tell me that anything will be removed from the file system, does it? My suggestion for new doc string wasn't meant to be accepted, but more to describe what information the original contained. How about this then: Removes the given directory, just like rmdir(). In addition, if the removal was successful, the parent directories mentioned in the 'path' argument are removed if they are now empty. This is done by removing the last path segment from the given path and trying to remove the directory given by the remaining path, until there is nothing left of the original path string. No exception will be raised while trying to remove parent directories. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:54 Message: Logged In: YES user_id=38376 (I've changed the docstring from "remove a leaf directory and empty all intermediate ones" to "remove a leaf directory and all empty intermediate ones". both the docstring and the docs could need some clarification, but the text you propose is not really an improvement...) ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 16:49 Message: Logged In: YES user_id=38376 Are you sure you understand how the function works? Given "spam/egg/bacon", it first attempts to do an rmdir on spam/egg/bacon. If that fails, the function raises an exception. Otherwise, it proceeds to rmdir spam/egg and spam. Errors during the latter stage are ignored. If you want to remove directories whether they're empty or not, use shutil.rmtree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 From noreply at sourceforge.net Sun Nov 13 22:30:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 13:30:16 -0800 Subject: [ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES Message-ID: Bugs item #1223976, was opened at 2005-06-20 11:40 Message generated for change (Comment added) made by nkour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 Please note that this 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: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-11-13 23:30 Message: Logged In: YES user_id=865368 this bug is REAL and major IMO any app that uses localization cannot be runned by a basque python is not aware of eu_ES at all! I don't know if this solves it (I'm not basque) --- /usr/lib/python2.4/locale.py 2005-11-12 11:59:16.000000000 +0200 +++ /tmp/locale.py 2005-11-13 23:27:27.000000000 +0200 @@ -481,6 +481,7 @@ 'ar_aa': 'ar_AA.ISO8859-6', 'ar_sa': 'ar_SA.ISO8859-6', 'arabic': 'ar_AA.ISO8859-6', + 'basque': 'eu_ES.ISO8859-1', 'bg': 'bg_BG.ISO8859-5', 'bg_bg': 'bg_BG.ISO8859-5', 'bulgarian': 'bg_BG.ISO8859-5', @@ -540,6 +541,7 @@ 'es_ve': 'es_VE.ISO8859-1', 'et': 'et_EE.ISO8859-4', 'et_ee': 'et_EE.ISO8859-4', + 'eu_ES': 'eu_ES.ISO8859-1', 'fi': 'fi_FI.ISO8859-1', 'fi_fi': 'fi_FI.ISO8859-1', 'finnish': 'fi_FI.ISO8859-1', btw for this not to happen again (sad to see py242 not fixing this) http://www.mpi-sb.mpg.de/~pesca/locales.html Zunbeltz Izaola is a courageous man, and please loweis think a bit more before replying why do you need that and this ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 08:28 Message: Logged In: YES user_id=21627 What do you need locale.getlocale() for? If it is to determine the encoding, I recommend to use locale.getpreferredencoding() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 From noreply at sourceforge.net Sun Nov 13 23:36:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 14:36:06 -0800 Subject: [ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES Message-ID: Bugs item #1223976, was opened at 2005-06-20 10:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 Please note that this 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: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 23:36 Message: Logged In: YES user_id=21627 It was a candid question: why do you need getlocale()? This function is inherently broken, not just for basque, and there is no way to fix it for good. So it would be best to remove the function entirely. Before such a step can be taken, I need to know why people use it in the first place. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-11-13 22:30 Message: Logged In: YES user_id=865368 this bug is REAL and major IMO any app that uses localization cannot be runned by a basque python is not aware of eu_ES at all! I don't know if this solves it (I'm not basque) --- /usr/lib/python2.4/locale.py 2005-11-12 11:59:16.000000000 +0200 +++ /tmp/locale.py 2005-11-13 23:27:27.000000000 +0200 @@ -481,6 +481,7 @@ 'ar_aa': 'ar_AA.ISO8859-6', 'ar_sa': 'ar_SA.ISO8859-6', 'arabic': 'ar_AA.ISO8859-6', + 'basque': 'eu_ES.ISO8859-1', 'bg': 'bg_BG.ISO8859-5', 'bg_bg': 'bg_BG.ISO8859-5', 'bulgarian': 'bg_BG.ISO8859-5', @@ -540,6 +541,7 @@ 'es_ve': 'es_VE.ISO8859-1', 'et': 'et_EE.ISO8859-4', 'et_ee': 'et_EE.ISO8859-4', + 'eu_ES': 'eu_ES.ISO8859-1', 'fi': 'fi_FI.ISO8859-1', 'fi_fi': 'fi_FI.ISO8859-1', 'finnish': 'fi_FI.ISO8859-1', btw for this not to happen again (sad to see py242 not fixing this) http://www.mpi-sb.mpg.de/~pesca/locales.html Zunbeltz Izaola is a courageous man, and please loweis think a bit more before replying why do you need that and this ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:28 Message: Logged In: YES user_id=21627 What do you need locale.getlocale() for? If it is to determine the encoding, I recommend to use locale.getpreferredencoding() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 From noreply at sourceforge.net Sun Nov 13 23:41:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 14:41:05 -0800 Subject: [ python-Feature Requests-1353344 ] python.desktop Message-ID: Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 23:41 Message: Logged In: YES user_id=21627 Would you be willing to provide one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 From noreply at sourceforge.net Sun Nov 13 23:43:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 14:43:32 -0800 Subject: [ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES Message-ID: Bugs item #1223976, was opened at 2005-06-20 11:40 Message generated for change (Comment added) made by nkour You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 Please note that this 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: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-11-14 00:43 Message: Logged In: YES user_id=865368 python itself uses this func, I don't even ask getlocale()! I just do: time.strptime(tim, '%Y%m%dT%H:%M:%S') somewhere and enjoy: time.strptime(tim, '%Y%m%dT%H:%M:%S') File "/usr/lib/python2.4/_strptime.py", line 269, in ? _TimeRE_cache = TimeRE() File "/usr/lib/python2.4/_strptime.py", line 188, in __init__ self.locale_time = LocaleTime() File "/usr/lib/python2.4/_strptime.py", line 73, in __init__ self.lang = _getlang() File "/usr/lib/python2.4/_strptime.py", line 32, in _getlang return locale.getlocale(locale.LC_TIME) File "/usr/lib/python2.4/locale.py", line 363, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES so basque feels like he's ATIA here ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-14 00:36 Message: Logged In: YES user_id=21627 It was a candid question: why do you need getlocale()? This function is inherently broken, not just for basque, and there is no way to fix it for good. So it would be best to remove the function entirely. Before such a step can be taken, I need to know why people use it in the first place. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-11-13 23:30 Message: Logged In: YES user_id=865368 this bug is REAL and major IMO any app that uses localization cannot be runned by a basque python is not aware of eu_ES at all! I don't know if this solves it (I'm not basque) --- /usr/lib/python2.4/locale.py 2005-11-12 11:59:16.000000000 +0200 +++ /tmp/locale.py 2005-11-13 23:27:27.000000000 +0200 @@ -481,6 +481,7 @@ 'ar_aa': 'ar_AA.ISO8859-6', 'ar_sa': 'ar_SA.ISO8859-6', 'arabic': 'ar_AA.ISO8859-6', + 'basque': 'eu_ES.ISO8859-1', 'bg': 'bg_BG.ISO8859-5', 'bg_bg': 'bg_BG.ISO8859-5', 'bulgarian': 'bg_BG.ISO8859-5', @@ -540,6 +541,7 @@ 'es_ve': 'es_VE.ISO8859-1', 'et': 'et_EE.ISO8859-4', 'et_ee': 'et_EE.ISO8859-4', + 'eu_ES': 'eu_ES.ISO8859-1', 'fi': 'fi_FI.ISO8859-1', 'fi_fi': 'fi_FI.ISO8859-1', 'finnish': 'fi_FI.ISO8859-1', btw for this not to happen again (sad to see py242 not fixing this) http://www.mpi-sb.mpg.de/~pesca/locales.html Zunbeltz Izaola is a courageous man, and please loweis think a bit more before replying why do you need that and this ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 08:28 Message: Logged In: YES user_id=21627 What do you need locale.getlocale() for? If it is to determine the encoding, I recommend to use locale.getpreferredencoding() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 From noreply at sourceforge.net Mon Nov 14 00:23:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 15:23:58 -0800 Subject: [ python-Bugs-1223976 ] error locale.getlocale() with LANGUAGE=eu_ES Message-ID: Bugs item #1223976, was opened at 2005-06-20 10:40 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 Please note that this 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: Zunbeltz Izaola (zunbeltz) Assigned to: Nobody/Anonymous (nobody) Summary: error locale.getlocale() with LANGUAGE=eu_ES Initial Comment: I had sumited this bug (id 1177674) and it has been closed becouse my bad explanation. My locale is set to LANGUAGE=eu_ES This is what i get in the interpreter Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import locale >>> locale.getlocale() (None, None) >>> locale.setlocale(locale.LC_ALL, '') 'eu_ES' >>> >>> locale.getlocale() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/locale.py", line 365, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES >>> ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-11-14 00:23 Message: Logged In: YES user_id=38388 Not so fast, Martin. I know that you don't like the function, but there's no reason to remove it. Note that this bug is fixed in CVS: I updated the locale database with the most recent X.org data last December. It does include the eu_es mapping, but doesn't have the basque mapping. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-11-13 23:43 Message: Logged In: YES user_id=865368 python itself uses this func, I don't even ask getlocale()! I just do: time.strptime(tim, '%Y%m%dT%H:%M:%S') somewhere and enjoy: time.strptime(tim, '%Y%m%dT%H:%M:%S') File "/usr/lib/python2.4/_strptime.py", line 269, in ? _TimeRE_cache = TimeRE() File "/usr/lib/python2.4/_strptime.py", line 188, in __init__ self.locale_time = LocaleTime() File "/usr/lib/python2.4/_strptime.py", line 73, in __init__ self.lang = _getlang() File "/usr/lib/python2.4/_strptime.py", line 32, in _getlang return locale.getlocale(locale.LC_TIME) File "/usr/lib/python2.4/locale.py", line 363, in getlocale return _parse_localename(localename) File "/usr/lib/python2.4/locale.py", line 278, in _parse_localename raise ValueError, 'unknown locale: %s' % localename ValueError: unknown locale: eu_ES so basque feels like he's ATIA here ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 23:36 Message: Logged In: YES user_id=21627 It was a candid question: why do you need getlocale()? This function is inherently broken, not just for basque, and there is no way to fix it for good. So it would be best to remove the function entirely. Before such a step can be taken, I need to know why people use it in the first place. ---------------------------------------------------------------------- Comment By: Nikos Kouremenos (nkour) Date: 2005-11-13 22:30 Message: Logged In: YES user_id=865368 this bug is REAL and major IMO any app that uses localization cannot be runned by a basque python is not aware of eu_ES at all! I don't know if this solves it (I'm not basque) --- /usr/lib/python2.4/locale.py 2005-11-12 11:59:16.000000000 +0200 +++ /tmp/locale.py 2005-11-13 23:27:27.000000000 +0200 @@ -481,6 +481,7 @@ 'ar_aa': 'ar_AA.ISO8859-6', 'ar_sa': 'ar_SA.ISO8859-6', 'arabic': 'ar_AA.ISO8859-6', + 'basque': 'eu_ES.ISO8859-1', 'bg': 'bg_BG.ISO8859-5', 'bg_bg': 'bg_BG.ISO8859-5', 'bulgarian': 'bg_BG.ISO8859-5', @@ -540,6 +541,7 @@ 'es_ve': 'es_VE.ISO8859-1', 'et': 'et_EE.ISO8859-4', 'et_ee': 'et_EE.ISO8859-4', + 'eu_ES': 'eu_ES.ISO8859-1', 'fi': 'fi_FI.ISO8859-1', 'fi_fi': 'fi_FI.ISO8859-1', 'finnish': 'fi_FI.ISO8859-1', btw for this not to happen again (sad to see py242 not fixing this) http://www.mpi-sb.mpg.de/~pesca/locales.html Zunbeltz Izaola is a courageous man, and please loweis think a bit more before replying why do you need that and this ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-07-06 07:28 Message: Logged In: YES user_id=21627 What do you need locale.getlocale() for? If it is to determine the encoding, I recommend to use locale.getpreferredencoding() instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223976&group_id=5470 From noreply at sourceforge.net Mon Nov 14 05:43:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 20:43:21 -0800 Subject: [ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *= Message-ID: Bugs item #1355842, was opened at 2005-11-13 03:17 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Connelly (connelly) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect Decimal-float behavior for += and *= Initial Comment: The += and *= operators have strange behavior when the LHS is a Decimal and the RHS is a float (as of 2005-11-13 CVS decimal.py). Example: >>> d = Decimal('1.02') >>> d += 2.1 >>> d NotImplemented A blatant violation of "Errors should never pass silently." Also, a bad error description is produced for the *= operator: >>> d = Decimal('1.02') >>> d *= 2.9 Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence by non-int ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-13 20:43 Message: Logged In: YES user_id=33168 Hmmm. __add__ returns NotImplemented which works with classic classes, but not new-style classes. I wonder if NotImplementedError is supposed to be raised for new-style classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470 From noreply at sourceforge.net Mon Nov 14 10:54:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 01:54:22 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Nobody/Anonymous (nobody) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 10:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 21:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 20:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Mon Nov 14 12:19:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 03:19:32 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 16:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 06:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 04:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 15:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 14:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 12:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 17:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 16:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Mon Nov 14 13:19:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 04:19:52 -0800 Subject: [ python-Feature Requests-1322308 ] itemgetter built-in? Message-ID: Feature Requests item #1322308, was opened at 2005-10-10 04:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470 Please note that this 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: capnSTABN (capnstabn) Assigned to: Nobody/Anonymous (nobody) Summary: itemgetter built-in? Initial Comment: uhm... operator.itemgetter() is useful and all, but fairly retarded looking for how simple it is basically what i am wrestling with at the moment is doing some regular expressions without completely ganking the crap out of the code to make it work, since every freakin thing in re returns None all over the bloody place like regular expressions were hitting a ragging pinata with a chainsaw after a LOT of muckymuck, basically six hours straight, the simplest non-conditional form i could come up with was this: http://42.vg/81691 http://42.vg/81691 any comments would be leet! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 07:19 Message: Logged In: YES user_id=80475 The use case is common enough to warrant further exploration. Essentially what is being requested is a straight-forward way to get a group dictionary that only includes matching groups. Two approaches come to mind. 1. Add a module constant, EXCLUDE, that when used as the default value causes non-matching groups to be excluded from the group dictionary: d=mo.groupdict(re.EXCLUDE) 2. Create a new flag, N or NODEFAULT or (?N), indicating that match objects should only include matching groups and not create default entries for non-matches: d=match('(?\w+)|(?\d+)', s, NODEFAULT).groupdict() FWIW, am not sympathetic to the OP's code fragment not being explicit. That is what happens when trying too hard to avoid using an if-statement. The fragment is much clearer without filtering: for type, string_ in mo.groupdict().iteritems(): if string_ is not None: . . . ---------------------------------------------------------------------- Comment By: capnSTABN (capnstabn) Date: 2005-10-11 04:33 Message: Logged In: YES user_id=1126596 ok to be more specific, as maybe that will help, line 17 in the code: for type, string_ in (filter(itemgetter(1), match.groupdict ().iteritems())): is about as implicit as pulling a tooth to remove a strand of celery the problem is that when using a single expansive recursive regular expression (which can translate an entire page of HTML like in any WikiWiki system in microseconds) that the amount of recursive calls because of all of the Nones flying around gets ludicrous a bit of a glimpse of a considerably more complex example: http://generic-host.us/~kevin/display_renderer.png please bear in mind that example is from 1999 or so ---------------------------------------------------------------------- Comment By: capnSTABN (capnstabn) Date: 2005-10-11 04:17 Message: Logged In: YES user_id=1126596 my request for enhancement is either a built-in version of operation.itemgetter() or an alteration of the behavior of re matches, i'm assuming the matter is up for debate so i wasn't being specific. this issue has nothing to do with showing code and i find your followup to be completely off topic! ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-10 11:57 Message: Logged In: YES user_id=1188172 Please tell us what your request for enhancement is or I'm going to close this as Invalid. Sorry I'm not showing more respect for your writing abilities :-), but if you want to show code around, do it on comp.lang.python please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1322308&group_id=5470 From noreply at sourceforge.net Mon Nov 14 18:04:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 09:04:29 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Mark Hirota (markhirota) Date: 2005-11-14 09:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 03:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 01:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 12:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 11:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 09:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 14:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Mon Nov 14 18:20:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 09:20:20 -0800 Subject: [ python-Bugs-1356720 ] Ctrl+C for copy does not work when caps-lock is on Message-ID: Bugs item #1356720, was opened at 2005-11-14 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+C for copy does not work when caps-lock is on Initial Comment: I only tested this on Windows/Python 2.4/Idle 1.1.2. Other shortcuts (Ctrl+V, Ctrl+X, etc.) work just fine, but Ctrl+C requires a lower case letter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 From noreply at sourceforge.net Mon Nov 14 19:33:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 10:33:29 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Mark Hirota (markhirota) Date: 2005-11-14 10:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 09:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 03:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 01:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 12:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 11:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 09:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 14:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Mon Nov 14 21:28:36 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 12:28:36 -0800 Subject: [ python-Bugs-1356720 ] Ctrl+C for copy does not work when caps-lock is on Message-ID: Bugs item #1356720, was opened at 2005-11-14 19:20 Message generated for change (Comment added) made by noamr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+C for copy does not work when caps-lock is on Initial Comment: I only tested this on Windows/Python 2.4/Idle 1.1.2. Other shortcuts (Ctrl+V, Ctrl+X, etc.) work just fine, but Ctrl+C requires a lower case letter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-14 22:28 Message: Logged In: YES user_id=679426 I didn't reproduce it, but it must be because the key binding for interrupt-execution is set to " " only in the "IDLE Classic - Windows" keybinding set, and not in the Mac and Unix variants, where it's only "". I don't find the place to attach a file (new sourceforge style), so here it is: Index: config-keys.def =================================================================== --- config-keys.def (revision 41443) +++ config-keys.def (working copy) @@ -70,7 +70,7 @@ end-of-file= history-next= history-previous= -interrupt-execution= +interrupt-execution= view-restart= restart-shell= open-class-browser= @@ -123,7 +123,7 @@ python-context-help= history-next= history-previous= -interrupt-execution= +interrupt-execution= view-restart= restart-shell= open-class-browser= Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 From noreply at sourceforge.net Mon Nov 14 23:01:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 14:01:57 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 16:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 16:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 07:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-11 01:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Mon Nov 14 23:08:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 14:08:11 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 14:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 14:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 05:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 23:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Mon Nov 14 23:50:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 14:50:47 -0800 Subject: [ python-Feature Requests-1080727 ] Add encoding to DocFileSuite Message-ID: Feature Requests item #1080727, was opened at 2004-12-07 16:47 Message generated for change (Comment added) made by dcjim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bjorn Tillenius (bjoti) >Assigned to: Jim Fulton (dcjim) Summary: Add encoding to DocFileSuite Initial Comment: If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. But if one wants to combine the documentation and testing, by writing a text file, and thus use DocFileSuite, it's not possible to use non-ASCII characters in the tests. This is because there's no way of specifying which encoding the text file uses. Instead one has to \-quote all non-ASCII characters, and that makes the tests harder to read IMHO. ---------------------------------------------------------------------- >Comment By: Jim Fulton (dcjim) Date: 2005-11-14 22:50 Message: Logged In: YES user_id=73023 The patch looks good to me. I haven't looked at the tests, but I assume that they are good too. I will look at them. :) I'm also going to add PEP 263-style encoding specification. Thanks! ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2005-09-13 20:12 Message: Logged In: YES user_id=1032069 Attaching new version of the patch that will apply cleanly against latest CVS ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-09-13 18:59 Message: Logged In: YES user_id=31435 Ed, can you make time to review this patch? If not, please unassign it again. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 18:05 Message: Logged In: YES user_id=1032069 Uploaded new patch, which adds the possibility to specify an encoding to testfile as well, since I assume this is desirable. ---------------------------------------------------------------------- Comment By: Bjorn Tillenius (bjoti) Date: 2004-12-18 14:08 Message: Logged In: YES user_id=1032069 Added patch for Tim to review. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-12-15 03:09 Message: Logged In: YES user_id=31435 Unassigned myself -- can't make time to work on it. I'll be happy to review a patch (code/tests/docs) if one appears. I approve of the idea . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1080727&group_id=5470 From noreply at sourceforge.net Tue Nov 15 00:57:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 15:57:53 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 16:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 17:57 Message: Logged In: YES user_id=44345 No, we're still discussing stdin. My only point is that what you do might be predicated on whether or not you think you can communicate with the user on stderr. My thought was that if stderr is valid you can raise an exception that prints a traceback. If not, Py_FatalError is your only recourse. Your code checks for the directori-ness of stdin as the first thing, then bails if it is. If it checked to see if stderr was valid first, it could decide to raise SystemError instead of calling Py_FatalError. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 16:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 16:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 07:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-11 01:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Tue Nov 15 01:16:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 16:16:24 -0800 Subject: [ python-Bugs-1353504 ] Python drops core when stdin is bogus Message-ID: Bugs item #1353504, was opened at 2005-11-10 14:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Neal Norwitz (nnorwitz) Summary: Python drops core when stdin is bogus Initial Comment: Someone here at work had the bright idea to execute a Python script from a Solaris 10 ~/.dtprofile file. Apparently, at the time that script is run stdin is bogus. Python core dumps with this gdb backtrace: #0 0x0807d290 in PyDict_SetItem (op=0x815b79c, key=0x8163f20, value=0x0) at ../Objects/dictobject.c:549 #1 0x0807e0f7 in PyDict_SetItemString (v=0x815b79c, key=0x8118df2 "stdin", item=0x0) at ../Objects/dictobject.c:1988 #2 0x080e0d03 in _PySys_Init () at ../Python/sysmodule.c:977 #3 0x080ddfdb in Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:190 #4 0x080dfa89 in Py_Initialize () at ../Python/pythonrun.c:283 #5 0x0805cd55 in Py_Main (argc=3, argv=0x8047c08) at ../Modules/main.c:418 #6 0x0805ca13 in main (argc=3, argv=0x8047c08) at ../Modules/python.c:23 (This is from 2.4.2, but it also happens in 2.3.4.) Looking at the code in _PySys_Init it calls sysin = PyFile_FromFile(stdin, "", "r", NULL); which returns NULL. In PyFile_FromFile it creates a new PyFileObject, then initializes it by calling a static function, fill_file_fields. This apparently fails, causing a NULL pointer return. Back in _PySys_Init it checks PyErr_Occurred, but fill_file_fields never raised an except. The NULL pointer is passed to PyDict_SetItemString and havoc ensues. I haven't checked CVS, but 2.4 (and probably 2.3) should be fixed. I suggest raising an IOError in fill_file_fields instead of just setting f to NULL and returning it. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 16:16 Message: Logged In: YES user_id=33168 Ok, I understand that part. But if you can't accept input from the user, what can you do? If all you are suggesting is to change Py_FatalError() to raising a SystemError and still exiting, I'm fine with that if it can work. I agree this would probably be nicer too. Or am I still missing your point? Do you want to work on a patch? I'm fine with any improvement, I'm just not sure how much can be done. If you want to improve the error message, that would be good too. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 15:57 Message: Logged In: YES user_id=44345 No, we're still discussing stdin. My only point is that what you do might be predicated on whether or not you think you can communicate with the user on stderr. My thought was that if stderr is valid you can raise an exception that prints a traceback. If not, Py_FatalError is your only recourse. Your code checks for the directori-ness of stdin as the first thing, then bails if it is. If it checked to see if stderr was valid first, it could decide to raise SystemError instead of calling Py_FatalError. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 14:08 Message: Logged In: YES user_id=33168 Did you mistype and still mean stdin or are we talking about stderr? IIRC, calling Py_FatalError() was what I intended if stdin is bogus. I don't know what else to do. If you can think of scenarios where we could improve the behaviour, I think that's fine to do. I suppose you could set stdin to None, but I'm not sure what that would do or if it would improve anything. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 14:01 Message: Logged In: YES user_id=44345 Well, I built from CVS^H^H^HSubversion HEAD at work and tried again. Still got a core dump, but that was a side-effect of calling Py_FatalError. Is that the intended behavior? I guess with a bogus stderr that makes sense, but if stderr happened to be valid at this point, I'd rather have it raise something more meaningful for the user, like SystemError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-12 05:18 Message: Logged In: YES user_id=44345 Thanks Neal. I'll check it out at work next week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-10 23:24 Message: Logged In: YES user_id=33168 This should be fixed in 2.4.3 and CVS (2.3.5 is probably affected too). I remember dealing with directories specifically. Checkout the current sysmodule.c. Here's the checkin: r39652 | nnorwitz | 2005-10-02 18:03:46 -0700 (Sun, 02 Oct 2005) | 5 lines SF bug #887946. Let me know if this bug is different and the patch doesn't solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1353504&group_id=5470 From noreply at sourceforge.net Tue Nov 15 01:26:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 16:26:28 -0800 Subject: [ python-Bugs-1356969 ] Tix.py class HList missing info_bbox Message-ID: Bugs item #1356969, was opened at 2005-11-14 19:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356969&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ron Provost (ronpro at cox.net) Assigned to: Martin v. L?wis (loewis) Summary: Tix.py class HList missing info_bbox Initial Comment: class HList in Tix.py is missing the method info_bbox(); though according to the Tix website, it exists and should return a list of coordinates for the bounding box of the list entry whose path is passed into the function as an argument. I added the following bit of code to my python 2.4.2 final release build (Tix.py, line 961) and find that it seems to work just fine. def info_bbox( self, entry ): coords = self.tk.call( self._w, 'info', 'bbox', entry ).split( ' ') return map( int, coords ) I've attached the modified file for examination. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356969&group_id=5470 From noreply at sourceforge.net Tue Nov 15 05:08:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 20:08:14 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 18:08 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2005-11-14 22:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 15:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-31 16:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 07:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 13:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 06:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 12:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 10:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Tue Nov 15 06:54:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 21:54:57 -0800 Subject: [ python-Bugs-1337987 ] IDLE, F5 – wrong external file content. (on error!) Message-ID: Bugs item #1337987, was opened at 2005-10-25 22:12 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: MvGulik (tyrell_rr) >Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE, F5 – wrong external file content. (on error!) Initial Comment: IDLE, F5 ? wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-15 00:54 Message: Logged In: YES user_id=149084 Duplicate of RFE 1175686. Please read the comments on that Tracker item. IDLE is intended to edit its own code. Apparently you are using an external editor. It's not a high priority for me to support that, since IDLE has one-keystroke save, load and run. The guy who submitted the RFE never came back with a use case; what's your use for this feature? IDLE would have to detect that the file had changed on disk. Not difficult, just not done right now. ---------------------------------------------------------------------- Comment By: MvGulik (tyrell_rr) Date: 2005-10-28 05:46 Message: Logged In: YES user_id=779309 > Save with Control-S before pressing F5. Don't think that a good idee. This will save the initially loaded old file content inside IDLE over the new file content (external edited -> not using IDLE for editing) Effectingly undoing all the changes done with the external editor. M.v.Gulik. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-25 22:45 Message: Logged In: YES user_id=80475 Save with Control-S before pressing F5. ---------------------------------------------------------------------- Comment By: MvGulik (tyrell_rr) Date: 2005-10-25 22:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 From noreply at sourceforge.net Tue Nov 15 07:55:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 22:55:18 -0800 Subject: [ python-Bugs-1063937 ] Random core dumps Message-ID: Bugs item #1063937, was opened at 2004-11-10 08:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.2.3 >Status: Closed >Resolution: Works For Me >Priority: 5 Submitted By: munder12 (munder12) >Assigned to: Neal Norwitz (nnorwitz) Summary: Random core dumps Initial Comment: I have narrowed it down as far as I can by continuing to make the problem simpler and simpler but where it still core dumps. The way this is set up is the following: pytest2.py and pytest.py are in the same directory. pytest3.py is in PYTHONPATH where PYTHONPATH is /BASE:/SUP (pytest3.py is in BASE). Run ./pytest2.py several times. This current problem core dumps on average about 2 times every 5 runs. I have attached a file that has the Python listings as well as the gdb traceback. This is running under Fedora Core 1 with: Python 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Thank you, Mark PS Strangely enough the comments in pytest.py seem to actually increase the frequency of core dumps. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-14 22:55 Message: Logged In: YES user_id=33168 munder12, if you are still having problems let us know. I'm closing this as not reproducible. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 02:15 Message: Logged In: YES user_id=1188172 I'd say that it can be closed. As mwh says: "If Python 2.4b2 cored 25% of the time it was launched, someone else would have noticed by now :)" ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 23:42 Message: Logged In: YES user_id=33168 I can't reproduce on current CVS (2.5). Can anyone reproduce this now? Should this be closed? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-23 01:15 Message: Logged In: YES user_id=1038590 I'm not sure it's relevant, but I once had a similar problem with Python flakiness that turned out to be due to some old .pyc files lying around (this was Fedora Core 3-test 1, and the offending files were in my Python CVS build directory). For whatever reason, Python wasn't picking up the version mismatch and was trying to use the old .pyc files. Seg faults abounded as a result. One thought: could root ownership of pre-generated .pyc's have that effect? (I don't know how Python reacts if it can't delete the .pyc's) ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-17 09:00 Message: Logged In: YES user_id=1156202 I have written a program in C that just opens and closes a file repeatedly. It appears to work fine. But, there appears to be much more that Python is doing behind the scenes than what my script is explicitly directing (open and close the file). Since I'm not sure what all OS related calls Python is making when opening, say, "site.py," I'm not quite sure how I can write a C code that mimics what Python is doing. It may well be that the OS is the culprit. However, it also could be that, in the Python code itself, some error checking is not being performed on all OS calls as they should be since they so rarely fail on a mjority of OS's. Or, extra try...catch blocks maybe could be added to retry the OS call(s) that is "incorrectly" failing on Fedora Core 1 so that Python maintains its portability with (hopefully) minimal speed impact. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-16 16:54 Message: Logged In: YES user_id=31435 At this point, it would be prudent to write the same kind of program in straight C, and test that. The more you find out, the less it appears that Python has something to do with what you're seeing. Note that it's not unusual to discover OS, compiler, and platform C library bugs by running Python programs, simply because Python builds on all of them. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-16 16:47 Message: Logged In: YES user_id=1156202 It is 2 times out of 8 runs of the main script. Actually, that is 2 cores out of 1600 runs of the script that really cores. It does seem to be localized to Fedora Core 1. Fedora Core 2, Win 2000, Win XP, and Mandrake 9 on similar hardware do not have the problem with these scripts. The Python 2.4b2 is straight out of the tarball (compiled and installed cleanly). The core dumps occur randomly with posixpath.py, site.py, etc. and at different stages (robject() and within fstat() (from /usr/include/sys/stat.h)). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 00:38 Message: Logged In: YES user_id=6656 Hmm. The traceback shows that it's dumping core while loading the site.pyc file from the disk. This happens before Python begins executing whatever code you've asked it to. You could try deleting the site.pyc file and see if that makes any difference, or running python -S. I still think there must be something odd about your setup. If Python 2.4b2 cored 25% of the time it was launched, someone else would have noticed by now :) ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-11 08:05 Message: Logged In: YES user_id=1156202 I have checked out and built Python 2.4b2. It still core dumps on these same files but it now takes on average about 8 runs to get 2 cores. I will attach the 2.4b2 core traceback. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-11 07:34 Message: Logged In: YES user_id=6656 Uh, if that tiny thing cores, I'm very much inclined to believe there's something flaky in your setup. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-11 07:25 Message: Logged In: YES user_id=1156202 I have played some more with the setup. Now only pytest2.py and pytest.py need to be present in same directory. Running pytest2.py will randomly cause core dumps coming from pytest.py. If you run pytest.py enough times directly it also will randomly core. I have attached pytest.py and pytest2.py. I have not tried with any other version of Python yet. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-11 06:47 Message: Logged In: YES user_id=6656 Have you tried a more recent Python? I'm finding decoding your report (attempting to reproduce) a little challenging. Could you upload a tarball containing a shell script driver or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470 From noreply at sourceforge.net Tue Nov 15 11:35:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 02:35:34 -0800 Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable. Message-ID: Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 From noreply at sourceforge.net Tue Nov 15 12:37:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 03:37:58 -0800 Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable. Message-ID: Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by mozbugbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. ---------------------------------------------------------------------- >Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 From noreply at sourceforge.net Tue Nov 15 14:34:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 05:34:13 -0800 Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable. Message-ID: Bugs item #1357260, was opened at 2005-11-15 20:35 Message generated for change (Comment added) made by krumms You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 23:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? ---------------------------------------------------------------------- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 21:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 From noreply at sourceforge.net Tue Nov 15 21:40:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 12:40:56 -0800 Subject: [ python-Bugs-1357604 ] os.path.makedirs DOES handle UNC paths Message-ID: Bugs item #1357604, was opened at 2005-11-15 20:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.makedirs DOES handle UNC paths Initial Comment: File: http://www.python.org/doc/current/lib/os-file-dir.html Paragraph: """ makedirs( path[, mode]) Recursive directory creation function. Like mkdir(), but makes all intermediate-level directories needed to contain the leaf directory. Throws an error exception if the leaf directory already exists or cannot be created. The default mode is 0777 (octal). This function does not properly handle UNC paths (only relevant on Windows systems; Universal Naming Convention paths are those that use the `\host\path' syntax). New in version 1.5.2. """ I just os.path.makedirs(...) with a UNC path and it DID create the desired folder on the specified host. The "in development" documentation is the same as the above documentation. I did not see any reference to this in the existing documentation bug reports. My particulars ... Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Windows XP-pro (all latest patches) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 From noreply at sourceforge.net Wed Nov 16 01:09:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 16:09:49 -0800 Subject: [ python-Bugs-1063937 ] Random core dumps Message-ID: Bugs item #1063937, was opened at 2004-11-10 10:50 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: munder12 (munder12) Assigned to: Neal Norwitz (nnorwitz) Summary: Random core dumps Initial Comment: I have narrowed it down as far as I can by continuing to make the problem simpler and simpler but where it still core dumps. The way this is set up is the following: pytest2.py and pytest.py are in the same directory. pytest3.py is in PYTHONPATH where PYTHONPATH is /BASE:/SUP (pytest3.py is in BASE). Run ./pytest2.py several times. This current problem core dumps on average about 2 times every 5 runs. I have attached a file that has the Python listings as well as the gdb traceback. This is running under Fedora Core 1 with: Python 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Thank you, Mark PS Strangely enough the comments in pytest.py seem to actually increase the frequency of core dumps. ---------------------------------------------------------------------- >Comment By: munder12 (munder12) Date: 2005-11-15 18:09 Message: Logged In: YES user_id=1156202 I'm no longer on Fedora Core 1 and cannot tell if this has been fixed on that system or not. I do not have the problem on Fedora Core 3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-11-15 00:55 Message: Logged In: YES user_id=33168 munder12, if you are still having problems let us know. I'm closing this as not reproducible. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-03 04:15 Message: Logged In: YES user_id=1188172 I'd say that it can be closed. As mwh says: "If Python 2.4b2 cored 25% of the time it was launched, someone else would have noticed by now :)" ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 01:42 Message: Logged In: YES user_id=33168 I can't reproduce on current CVS (2.5). Can anyone reproduce this now? Should this be closed? ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-23 03:15 Message: Logged In: YES user_id=1038590 I'm not sure it's relevant, but I once had a similar problem with Python flakiness that turned out to be due to some old .pyc files lying around (this was Fedora Core 3-test 1, and the offending files were in my Python CVS build directory). For whatever reason, Python wasn't picking up the version mismatch and was trying to use the old .pyc files. Seg faults abounded as a result. One thought: could root ownership of pre-generated .pyc's have that effect? (I don't know how Python reacts if it can't delete the .pyc's) ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-17 11:00 Message: Logged In: YES user_id=1156202 I have written a program in C that just opens and closes a file repeatedly. It appears to work fine. But, there appears to be much more that Python is doing behind the scenes than what my script is explicitly directing (open and close the file). Since I'm not sure what all OS related calls Python is making when opening, say, "site.py," I'm not quite sure how I can write a C code that mimics what Python is doing. It may well be that the OS is the culprit. However, it also could be that, in the Python code itself, some error checking is not being performed on all OS calls as they should be since they so rarely fail on a mjority of OS's. Or, extra try...catch blocks maybe could be added to retry the OS call(s) that is "incorrectly" failing on Fedora Core 1 so that Python maintains its portability with (hopefully) minimal speed impact. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-16 18:54 Message: Logged In: YES user_id=31435 At this point, it would be prudent to write the same kind of program in straight C, and test that. The more you find out, the less it appears that Python has something to do with what you're seeing. Note that it's not unusual to discover OS, compiler, and platform C library bugs by running Python programs, simply because Python builds on all of them. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-16 18:47 Message: Logged In: YES user_id=1156202 It is 2 times out of 8 runs of the main script. Actually, that is 2 cores out of 1600 runs of the script that really cores. It does seem to be localized to Fedora Core 1. Fedora Core 2, Win 2000, Win XP, and Mandrake 9 on similar hardware do not have the problem with these scripts. The Python 2.4b2 is straight out of the tarball (compiled and installed cleanly). The core dumps occur randomly with posixpath.py, site.py, etc. and at different stages (robject() and within fstat() (from /usr/include/sys/stat.h)). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-16 02:38 Message: Logged In: YES user_id=6656 Hmm. The traceback shows that it's dumping core while loading the site.pyc file from the disk. This happens before Python begins executing whatever code you've asked it to. You could try deleting the site.pyc file and see if that makes any difference, or running python -S. I still think there must be something odd about your setup. If Python 2.4b2 cored 25% of the time it was launched, someone else would have noticed by now :) ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-11 10:05 Message: Logged In: YES user_id=1156202 I have checked out and built Python 2.4b2. It still core dumps on these same files but it now takes on average about 8 runs to get 2 cores. I will attach the 2.4b2 core traceback. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-11 09:34 Message: Logged In: YES user_id=6656 Uh, if that tiny thing cores, I'm very much inclined to believe there's something flaky in your setup. ---------------------------------------------------------------------- Comment By: munder12 (munder12) Date: 2004-11-11 09:25 Message: Logged In: YES user_id=1156202 I have played some more with the setup. Now only pytest2.py and pytest.py need to be present in same directory. Running pytest2.py will randomly cause core dumps coming from pytest.py. If you run pytest.py enough times directly it also will randomly core. I have attached pytest.py and pytest2.py. I have not tried with any other version of Python yet. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-11-11 08:47 Message: Logged In: YES user_id=6656 Have you tried a more recent Python? I'm finding decoding your report (attempting to reproduce) a little challenging. Could you upload a tarball containing a shell script driver or something? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470 From noreply at sourceforge.net Wed Nov 16 09:23:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 00:23:48 -0800 Subject: [ python-Bugs-1357915 ] suprocess cannot handle shell arguments Message-ID: Bugs item #1357915, was opened at 2005-11-16 09:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357915&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pierre Ossman (dr7eus) Assigned to: Nobody/Anonymous (nobody) Summary: suprocess cannot handle shell arguments Initial Comment: If you try and include arguments to the shell in subprocess you get a traceback: Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/subprocess.py", line 558, in __init__ errread, errwrite) File "/usr/lib/python2.4/subprocess.py", line 907, in _execute_child args = ["/bin/sh", "-c"] + args TypeError: can only concatenate list (not "tuple") to list A simple list() should solve the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357915&group_id=5470 From noreply at sourceforge.net Wed Nov 16 16:28:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 07:28:20 -0800 Subject: [ python-Bugs-1358186 ] Incorrect handling of unicode "strings" in asynchat.py Message-ID: Bugs item #1358186, was opened at 2005-11-16 16:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Holger Lehmann (holle) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect handling of unicode "strings" in asynchat.py Initial Comment: While debugging my Zope installation using the DeadLockDebugger along with the threadframe module under Python 2.3 and 2.4 I stumbled upon a weird behaviour of the method refill_buffer ind the class async_chat in the file asynchat.py (Around line 198). There is a special handling for strings: [...] elif isinstance(p, str): self.producer_fifo.pop() self.ac_out_buffer = self.ac_out_buffer + p return data = p.more() [...] Now, if p is an instance of string, it gets a special handling and the function returns. But if p is an instance of unicode, it does not get the special handling, but dies in the line data = p.more() with the error, that unicode does not have a function named more. I was able to program a workaround by testing for str or unicode. Please see the attached diff-file for details. The code now works as expected. I guess a better way would be to import types and change the if into a "type(p) in types.StringTypes", but I did not dare to do this. I have not checked the code to see if there are more conditionals broken the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 From noreply at sourceforge.net Wed Nov 16 16:34:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 07:34:58 -0800 Subject: [ python-Bugs-1358186 ] Incorrect handling of unicode "strings" in asynchat.py Message-ID: Bugs item #1358186, was opened at 2005-11-16 16:28 Message generated for change (Comment added) made by holle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Holger Lehmann (holle) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect handling of unicode "strings" in asynchat.py Initial Comment: While debugging my Zope installation using the DeadLockDebugger along with the threadframe module under Python 2.3 and 2.4 I stumbled upon a weird behaviour of the method refill_buffer ind the class async_chat in the file asynchat.py (Around line 198). There is a special handling for strings: [...] elif isinstance(p, str): self.producer_fifo.pop() self.ac_out_buffer = self.ac_out_buffer + p return data = p.more() [...] Now, if p is an instance of string, it gets a special handling and the function returns. But if p is an instance of unicode, it does not get the special handling, but dies in the line data = p.more() with the error, that unicode does not have a function named more. I was able to program a workaround by testing for str or unicode. Please see the attached diff-file for details. The code now works as expected. I guess a better way would be to import types and change the if into a "type(p) in types.StringTypes", but I did not dare to do this. I have not checked the code to see if there are more conditionals broken the same way. ---------------------------------------------------------------------- >Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:34 Message: Logged In: YES user_id=332779 Just for the record: I am using Linux 2.6.11 and Python 2.4 (SuSE 9.3) as well as Linux 2.6.5 and Python 2.3.3 (SLES 9 Beta 4). Both Python installations contain a sitecustomize.py with the following content: import sys sys.setdefaultencoding('iso-8859-1') The environment contains a variable LC_CTYPE set to: de_DE.UTF-8 The Zope is a 2.7.3 compiled on both of the above machines by myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 From noreply at sourceforge.net Wed Nov 16 16:38:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 07:38:08 -0800 Subject: [ python-Bugs-1358186 ] Incorrect handling of unicode "strings" in asynchat.py Message-ID: Bugs item #1358186, was opened at 2005-11-16 16:28 Message generated for change (Comment added) made by holle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Holger Lehmann (holle) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect handling of unicode "strings" in asynchat.py Initial Comment: While debugging my Zope installation using the DeadLockDebugger along with the threadframe module under Python 2.3 and 2.4 I stumbled upon a weird behaviour of the method refill_buffer ind the class async_chat in the file asynchat.py (Around line 198). There is a special handling for strings: [...] elif isinstance(p, str): self.producer_fifo.pop() self.ac_out_buffer = self.ac_out_buffer + p return data = p.more() [...] Now, if p is an instance of string, it gets a special handling and the function returns. But if p is an instance of unicode, it does not get the special handling, but dies in the line data = p.more() with the error, that unicode does not have a function named more. I was able to program a workaround by testing for str or unicode. Please see the attached diff-file for details. The code now works as expected. I guess a better way would be to import types and change the if into a "type(p) in types.StringTypes", but I did not dare to do this. I have not checked the code to see if there are more conditionals broken the same way. ---------------------------------------------------------------------- >Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:38 Message: Logged In: YES user_id=332779 I checked the current svn repository to see if the "bug" still remains, yes it does: http://svn.python.org/view/python/trunk/Lib/asynchat.py?rev=38980&view=markup ---------------------------------------------------------------------- Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:34 Message: Logged In: YES user_id=332779 Just for the record: I am using Linux 2.6.11 and Python 2.4 (SuSE 9.3) as well as Linux 2.6.5 and Python 2.3.3 (SLES 9 Beta 4). Both Python installations contain a sitecustomize.py with the following content: import sys sys.setdefaultencoding('iso-8859-1') The environment contains a variable LC_CTYPE set to: de_DE.UTF-8 The Zope is a 2.7.3 compiled on both of the above machines by myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 From noreply at sourceforge.net Wed Nov 16 16:41:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 07:41:39 -0800 Subject: [ python-Bugs-1358186 ] Incorrect handling of unicode "strings" in asynchat.py Message-ID: Bugs item #1358186, was opened at 2005-11-16 16:28 Message generated for change (Comment added) made by holle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Holger Lehmann (holle) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect handling of unicode "strings" in asynchat.py Initial Comment: While debugging my Zope installation using the DeadLockDebugger along with the threadframe module under Python 2.3 and 2.4 I stumbled upon a weird behaviour of the method refill_buffer ind the class async_chat in the file asynchat.py (Around line 198). There is a special handling for strings: [...] elif isinstance(p, str): self.producer_fifo.pop() self.ac_out_buffer = self.ac_out_buffer + p return data = p.more() [...] Now, if p is an instance of string, it gets a special handling and the function returns. But if p is an instance of unicode, it does not get the special handling, but dies in the line data = p.more() with the error, that unicode does not have a function named more. I was able to program a workaround by testing for str or unicode. Please see the attached diff-file for details. The code now works as expected. I guess a better way would be to import types and change the if into a "type(p) in types.StringTypes", but I did not dare to do this. I have not checked the code to see if there are more conditionals broken the same way. ---------------------------------------------------------------------- >Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:41 Message: Logged In: YES user_id=332779 And here is the exception (sorry for the weird format of the traceback, I did not do it ;-) ): ZServer uncaptured python exception, closing channel (exceptions.AttributeError:'unicode' object has no attribute 'more' [/usr/lib/python2.3/asyncore.py|read|69] [/usr/lib/python2.3/asyncore.py|handle_read_event|390] [/usr/lib/python2.3/asynchat.py|handle_read|136] [/srv/zope_infotip_rts_skel/lib/python/ZServer/medusa/http_server.py| found_terminator|510] [/srv/zope_infotip_rts_render2/Products/DeadlockDebugger/dumper.py| match|88] [/srv/zope_infotip_rts_skel/lib/python/ZServer/HTTPServer.py| push|305] [/usr/lib/python2.3/asynchat.py|initiate_send|213] [/usr/lib/python2.3/asynchat.py|refill_buffer|200]) ---------------------------------------------------------------------- Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:38 Message: Logged In: YES user_id=332779 I checked the current svn repository to see if the "bug" still remains, yes it does: http://svn.python.org/view/python/trunk/Lib/asynchat.py?rev=38980&view=markup ---------------------------------------------------------------------- Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:34 Message: Logged In: YES user_id=332779 Just for the record: I am using Linux 2.6.11 and Python 2.4 (SuSE 9.3) as well as Linux 2.6.5 and Python 2.3.3 (SLES 9 Beta 4). Both Python installations contain a sitecustomize.py with the following content: import sys sys.setdefaultencoding('iso-8859-1') The environment contains a variable LC_CTYPE set to: de_DE.UTF-8 The Zope is a 2.7.3 compiled on both of the above machines by myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 From noreply at sourceforge.net Wed Nov 16 19:16:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 10:16:44 -0800 Subject: [ python-Feature Requests-1353344 ] python.desktop Message-ID: Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. ---------------------------------------------------------------------- >Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-11-16 19:16 Message: Logged In: YES user_id=51702 I have attached a .desktop file and an icon. python.desktop goes into /usr/share/applications and pycon.png into /usr/share/pixmaps. It's only translated to Swedish because I don't know other languages to well. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 23:41 Message: Logged In: YES user_id=21627 Would you be willing to provide one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 From noreply at sourceforge.net Wed Nov 16 19:29:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 10:29:22 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 19:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 19:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 18:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 12:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 10:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 21:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 20:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Wed Nov 16 19:51:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 10:51:39 -0800 Subject: [ python-Bugs-1357915 ] suprocess cannot handle shell arguments Message-ID: Bugs item #1357915, was opened at 2005-11-16 09:23 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357915&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pierre Ossman (dr7eus) >Assigned to: Peter ?strand (astrand) Summary: suprocess cannot handle shell arguments Initial Comment: If you try and include arguments to the shell in subprocess you get a traceback: Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/subprocess.py", line 558, in __init__ errread, errwrite) File "/usr/lib/python2.4/subprocess.py", line 907, in _execute_child args = ["/bin/sh", "-c"] + args TypeError: can only concatenate list (not "tuple") to list A simple list() should solve the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357915&group_id=5470 From noreply at sourceforge.net Wed Nov 16 23:59:08 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 14:59:08 -0800 Subject: [ python-Bugs-1358527 ] subprocess.py fails on Windows when there is no console Message-ID: Bugs item #1358527, was opened at 2005-11-16 22:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py fails on Windows when there is no console Initial Comment: Under Windows XP, using Python 2.4.2, calling a subprocess from "subprocess.py" from a script that does not have a console, with stdin=None (the default) fails. Since there is a check for stdin=stdout=stderr=None that just returns, to exhibit this problem you need to at least set stdout=PIPE (just to get it to run past the check for that special case). The problem is that in _get_handles(), l581-582: if stdin == None: p2cread = GetStdHandle(STD_INPUT_HANDLE) GetStdHandle returns None if there is no console. This is rather nasty bugger of a bug, since I suppose it breaks most GUI applications that start without the console (i.e. most) and that eventually invoke subprocesses and capture their output. I'm surprised to find this. To reproduce the problem, do this: 1. save the attached script to C:/temp/bug.py and C:/temp/bug.pyw 2. create two shortcuts on your desktop to invoke those scripts 3. open a shell and tail C:/temp/out.log For bug.py, the log file should display: 2005-11-16 17:38:11,661 INFO 0 For bug.pyw (no console), the log file should show the following exception: 2005-11-16 17:38:13,084 ERROR Traceback (most recent call last): File "C:\Temp\bug.pyw", line 20, in ? out = call(['C:/Cygwin/bin/ls.exe'], stdout=PIPE) #, stderr=PIPE) File "C:\Python24\lib\subprocess.py", line 412, in call return Popen(*args, **kwargs).wait() File "C:\Python24\lib\subprocess.py", line 533, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 593, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 634, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required This is the bug. Note: in this test program, I'm invoking Cygwin's ls.exe. Feel free to change it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 From noreply at sourceforge.net Thu Nov 17 00:27:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 15:27:10 -0800 Subject: [ python-Bugs-1358186 ] Incorrect handling of unicode "strings" in asynchat.py Message-ID: Bugs item #1358186, was opened at 2005-11-16 16:28 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Holger Lehmann (holle) >Assigned to: Fredrik Lundh (effbot) Summary: Incorrect handling of unicode "strings" in asynchat.py Initial Comment: While debugging my Zope installation using the DeadLockDebugger along with the threadframe module under Python 2.3 and 2.4 I stumbled upon a weird behaviour of the method refill_buffer ind the class async_chat in the file asynchat.py (Around line 198). There is a special handling for strings: [...] elif isinstance(p, str): self.producer_fifo.pop() self.ac_out_buffer = self.ac_out_buffer + p return data = p.more() [...] Now, if p is an instance of string, it gets a special handling and the function returns. But if p is an instance of unicode, it does not get the special handling, but dies in the line data = p.more() with the error, that unicode does not have a function named more. I was able to program a workaround by testing for str or unicode. Please see the attached diff-file for details. The code now works as expected. I guess a better way would be to import types and change the if into a "type(p) in types.StringTypes", but I did not dare to do this. I have not checked the code to see if there are more conditionals broken the same way. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-17 00:27 Message: Logged In: YES user_id=38376 You seem to be missing both what a network layer does, and what a Unicode string is. The network layer is designed to deal with streams of bytes, not arbitrary objects. Unicode strings contain Unicode characters, not bytes. If you want to pass something that isn't a stream of bytes over a network connection, it's up to you to convert that something to a byte stream *before* you pass them to the network layer. For a Unicode string, this means that you have to encode the string, using a suitable encoding for your application (e.g. ISO-8859-1 or UTF-8 or whatever your application prefers). The same applies if you want to pass in floating point values, integers, lists, images, or any other data type: it's up to you to decide how to convert the objects to a stream of bytes. Please fix your application. ---------------------------------------------------------------------- Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:41 Message: Logged In: YES user_id=332779 And here is the exception (sorry for the weird format of the traceback, I did not do it ;-) ): ZServer uncaptured python exception, closing channel (exceptions.AttributeError:'unicode' object has no attribute 'more' [/usr/lib/python2.3/asyncore.py|read|69] [/usr/lib/python2.3/asyncore.py|handle_read_event|390] [/usr/lib/python2.3/asynchat.py|handle_read|136] [/srv/zope_infotip_rts_skel/lib/python/ZServer/medusa/http_server.py| found_terminator|510] [/srv/zope_infotip_rts_render2/Products/DeadlockDebugger/dumper.py| match|88] [/srv/zope_infotip_rts_skel/lib/python/ZServer/HTTPServer.py| push|305] [/usr/lib/python2.3/asynchat.py|initiate_send|213] [/usr/lib/python2.3/asynchat.py|refill_buffer|200]) ---------------------------------------------------------------------- Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:38 Message: Logged In: YES user_id=332779 I checked the current svn repository to see if the "bug" still remains, yes it does: http://svn.python.org/view/python/trunk/Lib/asynchat.py?rev=38980&view=markup ---------------------------------------------------------------------- Comment By: Holger Lehmann (holle) Date: 2005-11-16 16:34 Message: Logged In: YES user_id=332779 Just for the record: I am using Linux 2.6.11 and Python 2.4 (SuSE 9.3) as well as Linux 2.6.5 and Python 2.3.3 (SLES 9 Beta 4). Both Python installations contain a sitecustomize.py with the following content: import sys sys.setdefaultencoding('iso-8859-1') The environment contains a variable LC_CTYPE set to: de_DE.UTF-8 The Zope is a 2.7.3 compiled on both of the above machines by myself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358186&group_id=5470 From noreply at sourceforge.net Thu Nov 17 02:04:38 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 17:04:38 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 13:29 Message generated for change (Comment added) made by markhirota You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Mark Hirota (markhirota) Date: 2005-11-16 17:04 Message: Logged In: YES user_id=1375527 Walter, I agree that there still seems to be an issue with _format() calling _repr() multiple times, however this patch seems to enable my feature request using sub- classing. Can the other issue (which exists presently also) be ignored for now? Could you submit the patch, or is that something I should do? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 10:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 10:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 09:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 03:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 01:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 12:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 11:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 09:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 14:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 13:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Thu Nov 17 06:38:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Nov 2005 21:38:32 -0800 Subject: [ python-Bugs-1357260 ] urllib/urllib2 cannot ftp files which are not listable. Message-ID: Bugs item #1357260, was opened at 2005-11-15 10:35 Message generated for change (Comment added) made by mozbugbox You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bugs Fly (mozbugbox) Assigned to: Nobody/Anonymous (nobody) Summary: urllib/urllib2 cannot ftp files which are not listable. Initial Comment: For whatever reason (security, privacy), there are ftp sites which will not allow ftp list command while normal downloading can be performed "blindly". This mostly happens on direct linked ftp urls. In urllib.py, the ftp wrapper first check with "self.ftp.nlst(file)" before downloading, thus prevent the above sites from being useful. From the codes around, I saw no reason this extra step/check was performed at all. If the file really did not exist, RETR would return a suitable error anyway as checked by the code below. ---------------------------------------------------------------------- >Comment By: Bugs Fly (mozbugbox) Date: 2005-11-17 05:38 Message: Logged In: YES user_id=1033842 File "/usr/lib/python2.4/ftplib.py", line 241, in sendcmd return self.getresp() File "/usr/lib/python2.4/ftplib.py", line 216, in getresp raise error_perm, resp IOError: [Errno ftp error] [Errno ftp error] 550 tompda_685692_Professional.Palm.OS.Programming.part12.rar: No such file or directory. ---------------------------------------------------------------------- Comment By: Thomas Lee (krumms) Date: 2005-11-15 13:34 Message: Logged In: YES user_id=315535 what's the expected response/error code from the FTP server if the NLST fails? ---------------------------------------------------------------------- Comment By: Bugs Fly (mozbugbox) Date: 2005-11-15 11:37 Message: Logged In: YES user_id=1033842 This might be related to bug #635453 but this is a bigger bug than a directory list is returned. If an existing file cannot be retrieved, then functionally is totally broken, there are no work around in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357260&group_id=5470 From noreply at sourceforge.net Thu Nov 17 14:41:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 05:41:41 -0800 Subject: [ python-Bugs-1358527 ] subprocess.py fails on Windows when there is no console Message-ID: Bugs item #1358527, was opened at 2005-11-16 22:59 Message generated for change (Comment added) made by blais You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py fails on Windows when there is no console Initial Comment: Under Windows XP, using Python 2.4.2, calling a subprocess from "subprocess.py" from a script that does not have a console, with stdin=None (the default) fails. Since there is a check for stdin=stdout=stderr=None that just returns, to exhibit this problem you need to at least set stdout=PIPE (just to get it to run past the check for that special case). The problem is that in _get_handles(), l581-582: if stdin == None: p2cread = GetStdHandle(STD_INPUT_HANDLE) GetStdHandle returns None if there is no console. This is rather nasty bugger of a bug, since I suppose it breaks most GUI applications that start without the console (i.e. most) and that eventually invoke subprocesses and capture their output. I'm surprised to find this. To reproduce the problem, do this: 1. save the attached script to C:/temp/bug.py and C:/temp/bug.pyw 2. create two shortcuts on your desktop to invoke those scripts 3. open a shell and tail C:/temp/out.log For bug.py, the log file should display: 2005-11-16 17:38:11,661 INFO 0 For bug.pyw (no console), the log file should show the following exception: 2005-11-16 17:38:13,084 ERROR Traceback (most recent call last): File "C:\Temp\bug.pyw", line 20, in ? out = call(['C:/Cygwin/bin/ls.exe'], stdout=PIPE) #, stderr=PIPE) File "C:\Python24\lib\subprocess.py", line 412, in call return Popen(*args, **kwargs).wait() File "C:\Python24\lib\subprocess.py", line 533, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 593, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 634, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required This is the bug. Note: in this test program, I'm invoking Cygwin's ls.exe. Feel free to change it ---------------------------------------------------------------------- >Comment By: Martin Blais (blais) Date: 2005-11-17 13:41 Message: Logged In: YES user_id=10996 Here is an example of a workaround: p = Popen(ps2pdf, stdin=PIPE, stdout=PIPE, stderr=PIPE, cwd=tempfile.gettempdir()) p.stdin.close() # FIXME: we need to specify and close stdin explicitly # because of a bug I found and reported in subprocess.py # when the program is launched without a console, see SF bug # tracker for the Python project for details. When the bug # gets fixed we should be able to remove this. Basically I just specify stdin=PIPE and close it by hand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 From noreply at sourceforge.net Thu Nov 17 14:43:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 05:43:32 -0800 Subject: [ python-Feature Requests-1353344 ] python.desktop Message-ID: Feature Requests item #1353344, was opened at 2005-11-10 19:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: python.desktop Initial Comment: I would very much like a /usr/share/applications/python.desktop file so that Python can be started from the Program-menu in Linux, just like you can from the Start-menu in Windows. I think it would be very neat and good for beginners. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-17 14:43 Message: Logged In: YES user_id=1188172 I added German translation. Regarding the icon: I do not like that very much. Isn't there another Python icon available in the standard sizes? ---------------------------------------------------------------------- Comment By: Bj?rn Lindqvist (sonderblade) Date: 2005-11-16 19:16 Message: Logged In: YES user_id=51702 I have attached a .desktop file and an icon. python.desktop goes into /usr/share/applications and pycon.png into /usr/share/pixmaps. It's only translated to Swedish because I don't know other languages to well. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 23:41 Message: Logged In: YES user_id=21627 Would you be willing to provide one? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1353344&group_id=5470 From noreply at sourceforge.net Thu Nov 17 16:53:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 07:53:06 -0800 Subject: [ python-Bugs-1359053 ] Incorrect documentation of raw unidaq string literals Message-ID: Bugs item #1359053, was opened at 2005-11-17 16:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359053&group_id=5470 Please note that this 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: Michael Haggerty (mhagger) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation of raw unidaq string literals Initial Comment: In the Python Reference Manual, section 2.4.1 (String literals), the last paragraph contains the sentence: > When an "r" or "R" prefix is used in conjunction with > a "u" or "U" prefix, then the \uXXXX escape sequence > is processed while all other backslashes are left in > the string. I believe this is incorrect; \UXXXXXXXX sequences also seem to be processed (at least in Python 2.3.5 and 2.4.1), and it is also logical that they should be processed. The required change to the text is obvious: When an "r" or "R" prefix is used in conjunction with a "u" or "U" prefix, then the \uXXXX and \UXXXXXXXX escape sequences are processed while all other backslashes are left in the string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359053&group_id=5470 From noreply at sourceforge.net Thu Nov 17 18:47:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 09:47:09 -0800 Subject: [ python-Bugs-1359150 ] Prefer configured browser over Mozilla and friends Message-ID: Bugs item #1359150, was opened at 2005-11-17 19:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Ville Skytt? (scop) Assigned to: Nobody/Anonymous (nobody) Summary: Prefer configured browser over Mozilla and friends Initial Comment: webbrowser.py in svn trunk seems to take user's GNOME configuration into account when selecting which browser to launch. That's good. What isn't good IMO is that it appears to try the Mozilla variants before that, thus ignoring the user's configured browser if a known Mozilla variant is installed. I'd suggest rearranging the first two blocks of register_X_browsers() so that the gconftool-2 block comes before the Mozilla/Netscape one. (Note that this is just from skimming the code; I don't have a svn trunk Python available, but was checking whether https://bugzilla.redhat.com/173275 would have been addressed upstream already.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359150&group_id=5470 From noreply at sourceforge.net Thu Nov 17 19:28:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 10:28:01 -0800 Subject: [ python-Bugs-1358527 ] subprocess.py fails on Windows when there is no console Message-ID: Bugs item #1358527, was opened at 2005-11-16 23:59 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Martin Blais (blais) >Assigned to: Peter ?strand (astrand) Summary: subprocess.py fails on Windows when there is no console Initial Comment: Under Windows XP, using Python 2.4.2, calling a subprocess from "subprocess.py" from a script that does not have a console, with stdin=None (the default) fails. Since there is a check for stdin=stdout=stderr=None that just returns, to exhibit this problem you need to at least set stdout=PIPE (just to get it to run past the check for that special case). The problem is that in _get_handles(), l581-582: if stdin == None: p2cread = GetStdHandle(STD_INPUT_HANDLE) GetStdHandle returns None if there is no console. This is rather nasty bugger of a bug, since I suppose it breaks most GUI applications that start without the console (i.e. most) and that eventually invoke subprocesses and capture their output. I'm surprised to find this. To reproduce the problem, do this: 1. save the attached script to C:/temp/bug.py and C:/temp/bug.pyw 2. create two shortcuts on your desktop to invoke those scripts 3. open a shell and tail C:/temp/out.log For bug.py, the log file should display: 2005-11-16 17:38:11,661 INFO 0 For bug.pyw (no console), the log file should show the following exception: 2005-11-16 17:38:13,084 ERROR Traceback (most recent call last): File "C:\Temp\bug.pyw", line 20, in ? out = call(['C:/Cygwin/bin/ls.exe'], stdout=PIPE) #, stderr=PIPE) File "C:\Python24\lib\subprocess.py", line 412, in call return Popen(*args, **kwargs).wait() File "C:\Python24\lib\subprocess.py", line 533, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 593, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 634, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required This is the bug. Note: in this test program, I'm invoking Cygwin's ls.exe. Feel free to change it ---------------------------------------------------------------------- Comment By: Martin Blais (blais) Date: 2005-11-17 14:41 Message: Logged In: YES user_id=10996 Here is an example of a workaround: p = Popen(ps2pdf, stdin=PIPE, stdout=PIPE, stderr=PIPE, cwd=tempfile.gettempdir()) p.stdin.close() # FIXME: we need to specify and close stdin explicitly # because of a bug I found and reported in subprocess.py # when the program is launched without a console, see SF bug # tracker for the Python project for details. When the bug # gets fixed we should be able to remove this. Basically I just specify stdin=PIPE and close it by hand. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 From noreply at sourceforge.net Fri Nov 18 12:41:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 03:41:21 -0800 Subject: [ python-Bugs-1357604 ] os.path.makedirs DOES handle UNC paths Message-ID: Bugs item #1357604, was opened at 2005-11-15 21:40 Message generated for change (Comment added) made by pterk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 Please note that this 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: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.makedirs DOES handle UNC paths Initial Comment: File: http://www.python.org/doc/current/lib/os-file-dir.html Paragraph: """ makedirs( path[, mode]) Recursive directory creation function. Like mkdir(), but makes all intermediate-level directories needed to contain the leaf directory. Throws an error exception if the leaf directory already exists or cannot be created. The default mode is 0777 (octal). This function does not properly handle UNC paths (only relevant on Windows systems; Universal Naming Convention paths are those that use the `\host\path' syntax). New in version 1.5.2. """ I just os.path.makedirs(...) with a UNC path and it DID create the desired folder on the specified host. The "in development" documentation is the same as the above documentation. I did not see any reference to this in the existing documentation bug reports. My particulars ... Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Windows XP-pro (all latest patches) ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-11-18 12:41 Message: Logged In: YES user_id=174455 I looks like the os.path (see ntpath.py) module has been updated to deal with UNC-paths somewhere between the 2.2.3 and 2.3.5 releases. Confirmed to work with python 2.3.5 and 2.4.1. It does NOT work in python 2.2.3. I have submitted a patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1359879&group_id=5470&atid=305470) that removes the comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 From noreply at sourceforge.net Fri Nov 18 16:41:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 07:41:43 -0800 Subject: [ python-Bugs-1360200 ] bdist_rpm still can't handle dashes in versions Message-ID: Bugs item #1360200, was opened at 2005-11-18 10:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1360200&group_id=5470 Please note that this 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 Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: jared jennings (sarynx) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm still can't handle dashes in versions Initial Comment: I tried to use Python 2.4.2 to create a bdist_rpm of setuptools, whose version string was 0.6a9dev-r41475. The distutils/command/bdist_rpm module's _make_spec_file method mangled the version to 0.6a9dev_r41475 (line 370). Then when the spec file was being built by rpmbuild, it looked for the sdist named setuptools-0.6a9dev_r41475.tar.gz, which didn't exist: it was called setuptools-0.6a9dev-r41475.tar.gz (note dash). So you have to mangle the version to make rpm happy - but you can't expect the sdist to have the mangled version as part of its name. I looked at the nightly Python source as of 17 Nov 2005 and saw that this bug still exists in the development version of Python. A patch is attached which fixed this bug for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1360200&group_id=5470 From noreply at sourceforge.net Fri Nov 18 16:58:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 07:58:28 -0800 Subject: [ python-Bugs-1360221 ] telnetlib expect() and read_until() do not time out properly Message-ID: Bugs item #1360221, was opened at 2005-11-18 15:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1360221&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Duncan Grisby (dgrisby) Assigned to: Nobody/Anonymous (nobody) Summary: telnetlib expect() and read_until() do not time out properly Initial Comment: In telnetlib, expect() and read_until() take a timeout argument. Unfortunately, the timeout is applied to each individual socket read(), rather than applying a deadline to the entire expect / read_until operation. The result of this is that if a server trickles non-matching data to the client, the expect() or read_until() never times out. In the case of expect(), it keeps building a larger and larger string of data to match with the regular expressions, leading to the eventual death of the process due to memory exhaustion. I have attached a patch that means the timeouts occur properly, and also adds a timeout to the initial open()'s connect() call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1360221&group_id=5470 From noreply at sourceforge.net Fri Nov 18 17:10:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 08:10:35 -0800 Subject: [ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0 Message-ID: Bugs item #1167262, was opened at 2005-03-21 03:25 Message generated for change (Comment added) made by varmaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Timothy Fitz (timothyfitz) Assigned to: Nobody/Anonymous (nobody) Summary: Fails assertion in winsig.c under VC 8.0 Initial Comment: In 2.4 and current cvs initsignal in signalmodule.c calls PyOS_getsig which calls signal with an invalid signal number. Under VC 7.1 (and 7.0, and probably before) this would return SIG_ERR however under VC 8.0 (beta) this causes an assertion failure. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2005-11-18 16:10 Message: Logged In: YES user_id=863202 Just wanted to mention that the Visual Studio 2005 products were officially launched on November 7th, 2005, and this same problem occurs when compiling the Python 2.4 source using Visual C++ 2005 Express Edition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 07:54 Message: Logged In: YES user_id=21627 See #1311784 for more discussion of this problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-01 22:02 Message: Logged In: YES user_id=21627 C99 7.14.1.1/p8 specifies # If the request can be honored, the signal function # returns the value of func for the most recent successful # call to signal for the specified signal sig. Otherwise, a # value of SIG_ERR is returned and a positive value is stored # in errno. So it seems to me that VC8 is in error: the request cannot be "honored", so it should return SIG_ERR. Until/if VC8 is released with that bug, I would like to take no action here. When it is released, we still might consider to ignore it until say, 8.1 comes along and fixes the bug. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-27 20:59 Message: Logged In: YES user_id=6656 Ew. My first thought is, is that allowed by ANSI C? I'd guess it's undefined behaviour. It still seems excessively unfriendly -- have you reported this to MS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 From noreply at sourceforge.net Fri Nov 18 21:36:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 12:36:16 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 03:08 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-11-18 23:36 Message: Logged In: YES user_id=4799 So it seems the new webbrowser.py is too new. May I suggest to rename the new module and doc to webbrowser2.py, and restore the old version of the module and the doc? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2005-11-15 07:08 Message: Logged In: YES user_id=44345 (Reopening. The webbrowser module still appears broken to me.) I'm new to this thread, but webbrowser.open() in current SVN (revision 41445) seems broken to me. This simple statement: webbrowser.open("somefile.html") returns True but fails to open the page in my currently running instance of Safari. Dropping back to Python 2.4.1, it works fine. I know webbrowser was a huge hack, but at least it appeared to do basic stuff fine. It would appear that's no longer the case. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-10 00:43 Message: Logged In: YES user_id=1188172 Fixed in Revision 41419. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-11-01 01:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 16:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 22:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 15:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 21:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 19:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Sat Nov 19 20:02:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Nov 2005 11:02:09 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this 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: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Sat Nov 19 21:18:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Nov 2005 12:18:46 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 14:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this 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: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 15:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Sat Nov 19 21:19:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Nov 2005 12:19:26 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 14:02 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this 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: Steven Bethard (bediviere) >Assigned to: Greg Ward (gward) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 15:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Sun Nov 20 05:52:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Nov 2005 20:52:00 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 14:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this 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: Steven Bethard (bediviere) Assigned to: Greg Ward (gward) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 23:52 Message: Logged In: YES user_id=80475 After more thought, I think the expandtabs() is a bug since it expands content tabs as well as margin tabs: >>> textwrap.dedent('\tABC\t\tDEF') 'ABC DEF' This is especially problematic given that dedent() has to guess at the tab size. If this gets fixed, I recommend using regular expressions as a way to indentify common margin prefixes on non-empty lines. This will also mixes of spaces and tabs without altering content with embedded tabs and without making assumptions about the tab size. Also, it ought to run somewhat faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 15:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Sun Nov 20 07:04:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Nov 2005 22:04:48 -0800 Subject: [ python-Bugs-1361643 ] textwrap.dedent() expands tabs Message-ID: Bugs item #1361643, was opened at 2005-11-19 14:02 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 Please note that this 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: Steven Bethard (bediviere) Assigned to: Greg Ward (gward) Summary: textwrap.dedent() expands tabs Initial Comment: I'm not sure whether this is a documentation bug or a code bug, but textwrap.dedent() expands tabs (and AFAICT doesn't give the user any way of stopping this): py> def test(): ... x = ('abcd efgh\n' ... 'ijkl mnop\n') ... y = textwrap.dedent('''... abcd efgh ... ijkl mnop ... ''') ... return x, y ... py> test() ('abcd\tefgh\nijkl\tmnop\n', 'abcd efgh\nijkl mnop\n') Looking at the code, I can see the culprit is the first line: lines = text.expandtabs().split('\n') If this is the intended behavior, I think the first sentence in the documentation[1] should be replaced with: """ Replace all tabs in string with spaces as per str.expandtabs() and then remove any whitespace that can be uniformly removed from the left of every line in text. """ and (I guess this part is an RFE) textwrap.dedent() should gain an optional expandtabs= keyword argument to disable this behavior. If it's not the intended behavior, I'd love to see that .expandtabs() call removed. [1]http://docs.python.org/lib/module-textwrap.html ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-20 01:04 Message: Logged In: YES user_id=80475 Suggested code: import re as _re _emptylines_with_spaces = _re.compile('(?m)^[ \t]+$') _prefixes_on_nonempty_lines = _re.compile('(?m)(^[ \t]*)(?:[^ \t\n]+)') def dedent(text): text = _emptylines_with_spaces.sub('', text) prefixes = _prefixes_on_nonempty_lines.findall(text) margin = min(prefixes or ['']) if margin: text = _re.sub('(?m)^' + margin, '', text) return text ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 23:52 Message: Logged In: YES user_id=80475 After more thought, I think the expandtabs() is a bug since it expands content tabs as well as margin tabs: >>> textwrap.dedent('\tABC\t\tDEF') 'ABC DEF' This is especially problematic given that dedent() has to guess at the tab size. If this gets fixed, I recommend using regular expressions as a way to indentify common margin prefixes on non-empty lines. This will also mixes of spaces and tabs without altering content with embedded tabs and without making assumptions about the tab size. Also, it ought to run somewhat faster. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-19 15:18 Message: Logged In: YES user_id=80475 FWIW, the tab expansion would be more useful if the default tabsize could be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1361643&group_id=5470 From noreply at sourceforge.net Mon Nov 21 03:14:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Nov 2005 18:14:06 -0800 Subject: [ python-Bugs-1356720 ] Ctrl+C for copy does not work when caps-lock is on Message-ID: Bugs item #1356720, was opened at 2005-11-14 09:20 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Lenny Domnitser (ldrhcp) >Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+C for copy does not work when caps-lock is on Initial Comment: I only tested this on Windows/Python 2.4/Idle 1.1.2. Other shortcuts (Ctrl+V, Ctrl+X, etc.) work just fine, but Ctrl+C requires a lower case letter. ---------------------------------------------------------------------- Comment By: Noam Raphael (noamr) Date: 2005-11-14 12:28 Message: Logged In: YES user_id=679426 I didn't reproduce it, but it must be because the key binding for interrupt-execution is set to " " only in the "IDLE Classic - Windows" keybinding set, and not in the Mac and Unix variants, where it's only "". I don't find the place to attach a file (new sourceforge style), so here it is: Index: config-keys.def =================================================================== --- config-keys.def (revision 41443) +++ config-keys.def (working copy) @@ -70,7 +70,7 @@ end-of-file= history-next= history-previous= -interrupt-execution= +interrupt-execution= view-restart= restart-shell= open-class-browser= @@ -123,7 +123,7 @@ python-context-help= history-next= history-previous= -interrupt-execution= +interrupt-execution= view-restart= restart-shell= open-class-browser= Noam ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1356720&group_id=5470 From noreply at sourceforge.net Mon Nov 21 04:14:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Nov 2005 19:14:00 -0800 Subject: [ python-Bugs-1362475 ] Text.edit_modified() doesn't work Message-ID: Bugs item #1362475, was opened at 2005-11-20 22:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362475&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Submitted By: Ron Provost (ronpro at cox.net) Assigned to: Martin v. L?wis (loewis) Summary: Text.edit_modified() doesn't work Initial Comment: Tkinter's Text widget has a method edit_modified() which should return True if the modified flag of the widget has been set, False otherwise. It should also be possible to pass True or False into the method to set the flag to a desired state. The implementation retrieves the correct value, but then calls self._getints( result ). This causes an exception to be thrown. In my build, I found that changing the implementation to the following appears to fix the function. return self.tk.call( self._w, 'edit', 'modified', arg ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362475&group_id=5470 From noreply at sourceforge.net Mon Nov 21 08:44:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Nov 2005 23:44:06 -0800 Subject: [ python-Bugs-1362587 ] Problem with tapedevices and the tarfile module Message-ID: Bugs item #1362587, was opened at 2005-11-21 08:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Henrik (esshenrik) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with tapedevices and the tarfile module Initial Comment: Problem to read a archive from tape that was created with the tarfile module in python. Error: >>> tar = tarfile.open("/dev/st0", "r") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/tarfile.py", line 916, in open return func(name, "r", fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 933, in taropen return cls(name, mode, fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 811, in __init__ fileobj = file(self.name, self.mode) IOError: [Errno 16] Device or resource busy: '/dev/st0' I was creating the archive with succes: >>> tar.close() >>> tar = tarfile.open("/dev/st0", "w") >>> tar.add("/tmp/bin1.tar") >>> tar.add("/tmp/bin2.tar") >>> tar.close() >>> When I try to read the tape without pyton the folowing error: [root at localhost tmp]# tar tvbf 20 /dev/st0 tar: Record size = 8 blocks -rw-r--r-- root/root 128614400 2005-11-20 19:53:11 tmp/bin1.tar tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory ...... Can anyone help me with this problem or have another module for tarfile that works with tapedevices? /Henrik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 From noreply at sourceforge.net Mon Nov 21 08:47:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Nov 2005 23:47:45 -0800 Subject: [ python-Bugs-1362587 ] Problem with tapedevices and the tarfile module Message-ID: Bugs item #1362587, was opened at 2005-11-21 08:44 Message generated for change (Settings changed) made by esshenrik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None >Priority: 7 Submitted By: Henrik (esshenrik) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with tapedevices and the tarfile module Initial Comment: Problem to read a archive from tape that was created with the tarfile module in python. Error: >>> tar = tarfile.open("/dev/st0", "r") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/tarfile.py", line 916, in open return func(name, "r", fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 933, in taropen return cls(name, mode, fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 811, in __init__ fileobj = file(self.name, self.mode) IOError: [Errno 16] Device or resource busy: '/dev/st0' I was creating the archive with succes: >>> tar.close() >>> tar = tarfile.open("/dev/st0", "w") >>> tar.add("/tmp/bin1.tar") >>> tar.add("/tmp/bin2.tar") >>> tar.close() >>> When I try to read the tape without pyton the folowing error: [root at localhost tmp]# tar tvbf 20 /dev/st0 tar: Record size = 8 blocks -rw-r--r-- root/root 128614400 2005-11-20 19:53:11 tmp/bin1.tar tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory ...... Can anyone help me with this problem or have another module for tarfile that works with tapedevices? /Henrik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 From noreply at sourceforge.net Mon Nov 21 09:40:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Nov 2005 00:40:05 -0800 Subject: [ python-Bugs-1362587 ] Problem with tapedevices and the tarfile module Message-ID: Bugs item #1362587, was opened at 2005-11-21 08:44 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 7 Submitted By: Henrik (esshenrik) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with tapedevices and the tarfile module Initial Comment: Problem to read a archive from tape that was created with the tarfile module in python. Error: >>> tar = tarfile.open("/dev/st0", "r") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/tarfile.py", line 916, in open return func(name, "r", fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 933, in taropen return cls(name, mode, fileobj) File "/usr/local/lib/python2.4/tarfile.py", line 811, in __init__ fileobj = file(self.name, self.mode) IOError: [Errno 16] Device or resource busy: '/dev/st0' I was creating the archive with succes: >>> tar.close() >>> tar = tarfile.open("/dev/st0", "w") >>> tar.add("/tmp/bin1.tar") >>> tar.add("/tmp/bin2.tar") >>> tar.close() >>> When I try to read the tape without pyton the folowing error: [root at localhost tmp]# tar tvbf 20 /dev/st0 tar: Record size = 8 blocks -rw-r--r-- root/root 128614400 2005-11-20 19:53:11 tmp/bin1.tar tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory tar: /dev/st0: Cannot read: Cannot allocate memory ...... Can anyone help me with this problem or have another module for tarfile that works with tapedevices? /Henrik ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-11-21 09:40 Message: Logged In: YES user_id=642936 Could try and use tarfile's stream interface for writing and reading and see if that works? Just append a pipe symbol to the mode, e.g.: tar = tarfile.open("/dev/st0", "w|") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1362587&group_id=5470 From noreply at sourceforge.net Mon Nov 21 22:16:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Nov 2005 13:16:50 -0800 Subject: [ python-Bugs-1363104 ] spawnlp is missing Message-ID: Bugs item #1363104, was opened at 2005-11-21 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363104&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg MacDonald (gtm256) Assigned to: Nobody/Anonymous (nobody) Summary: spawnlp is missing Initial Comment: spawnlp is missing from my os module. I am running 2.4.2 on windows 2000. >>> dir(os) ['F_OK', 'O_APPEND', 'O_BINARY', 'O_CREAT', 'O_EXCL', ' O_NOINHERIT', 'O_RANDOM', 'O_RDONLY', 'O_RDWR', 'O_SEQU ENTIAL', 'O_SHORT_LIVED', 'O_TEMPORARY', 'O_TEXT', 'O_T RUNC', 'O_WRONLY', 'P_DETACH', 'P_NOWAIT', 'P_NOWAITO', 'P_OVERLAY', 'P_WAIT', 'R_OK', 'TMP_MAX', 'UserDict', 'W_OK', 'X_OK', '_Environ', '__all__', '__builtins__', '__doc__', '__file__', '__name__', '_copy_reg', '_execv pe', '_exists', '_exit', '_get_exports_list', '_make_st at_result', '_make_statvfs_result', '_pickle_stat_resul t', '_pickle_statvfs_result', 'abort', 'access', 'altse p', 'chdir', 'chmod', 'close', 'curdir', 'defpath', 'de vnull', 'dup', 'dup2', 'environ', 'error', 'execl', 'ex ecle', 'execlp', 'execlpe', 'execv', 'execve', 'execvp' , 'execvpe', 'extsep', 'fdopen', 'fstat', 'fsync', 'get cwd', 'getcwdu', 'getenv', 'getpid', 'isatty', 'linesep ', 'listdir', 'lseek', 'lstat', 'makedirs', 'mkdir', 'n ame', 'open', 'pardir', 'path', 'pathsep', 'pipe', 'pop en', 'popen2', 'popen3', 'popen4', 'putenv', 'read', 'r emove', 'removedirs', 'rename', 'renames', 'rmdir', 'se p', 'spawnl', 'spawnle', 'spawnv', 'spawnve', 'startfil e', 'stat', 'stat_float_times', 'stat_result', 'statvfs _result', 'strerror', 'sys', 'system', 'tempnam', 'time s', 'tmpfile', 'tmpnam', 'umask', 'unlink', 'unsetenv', 'urandom', 'utime', 'waitpid', 'walk', 'write'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363104&group_id=5470 From noreply at sourceforge.net Tue Nov 22 13:32:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 04:32:17 -0800 Subject: [ python-Bugs-1363712 ] A possible thinko in the description of os/chmod Message-ID: Bugs item #1363712, was opened at 2005-11-22 04:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Evgeny Roubinchtein (zhenya1007) Assigned to: Nobody/Anonymous (nobody) Summary: A possible thinko in the description of os/chmod Initial Comment: As of November 21, 2005, the description of os.chmod() function at the following URL: http://docs.python.org/lib/os-file-dir.html read: "chmod( path, mode) Change the mode of path to the numeric mode. mode may take *one of the following values* (as defined in the stat module):"[asterisks mine] Shouldn't "one of the following values" be "a bitwise OR of one or more of the following values", or similar verbage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363712&group_id=5470 From noreply at sourceforge.net Tue Nov 22 13:32:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 04:32:56 -0800 Subject: [ python-Bugs-1363712 ] A possible thinko in the description of os.chmod Message-ID: Bugs item #1363712, was opened at 2005-11-22 04:32 Message generated for change (Settings changed) made by zhenya1007 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Evgeny Roubinchtein (zhenya1007) Assigned to: Nobody/Anonymous (nobody) >Summary: A possible thinko in the description of os.chmod Initial Comment: As of November 21, 2005, the description of os.chmod() function at the following URL: http://docs.python.org/lib/os-file-dir.html read: "chmod( path, mode) Change the mode of path to the numeric mode. mode may take *one of the following values* (as defined in the stat module):"[asterisks mine] Shouldn't "one of the following values" be "a bitwise OR of one or more of the following values", or similar verbage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363712&group_id=5470 From noreply at sourceforge.net Tue Nov 22 15:33:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 06:33:53 -0800 Subject: [ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8 Message-ID: Bugs item #1324799, was opened at 2005-10-12 08:21 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) >Assigned to: A.M. Kuchling (akuchling) Summary: Curses module doesn't install on Solaris 2.8 Initial Comment: During installation, the following happens: building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8- sun4u-2.4/_cursesmodule.o /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c: In function 'PyCursesWindow_GetStr': /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c:822: warning: implicit declaration of function 'mvwgetnstr' gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses - ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8- sun4u-2.4/_curses_panel.o gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel - lcurses -ltermcap -o build/lib.solaris-2.8-sun4u- 2.4/_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses ---------------------------------------------------------------------- Comment By: Nelson Arzola (narzola) Date: 2005-10-29 04:01 Message: Logged In: YES user_id=39023 I would like to add that this problem also exists under Solaris 2.10. For some reason, mvwgetnstr is not defined under Solaris 10. When I use nm to get the symbols out of /usr/lib/libcurses.so.1, I do not find it. When I replace the two references in /dsk/data0/build/Python-2.4.2/Modules/_cursesmodule.c from mvwgetnstr to mvwgetnwstr, I was able to compile the module and pass the appropriate tests. Since I don't use curses, I really don't have a good way to test this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 From noreply at sourceforge.net Tue Nov 22 15:45:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 06:45:35 -0800 Subject: [ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8 Message-ID: Bugs item #1324799, was opened at 2005-10-12 08:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: A.M. Kuchling (akuchling) Summary: Curses module doesn't install on Solaris 2.8 Initial Comment: During installation, the following happens: building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8- sun4u-2.4/_cursesmodule.o /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c: In function 'PyCursesWindow_GetStr': /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c:822: warning: implicit declaration of function 'mvwgetnstr' gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses - ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8- sun4u-2.4/_curses_panel.o gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel - lcurses -ltermcap -o build/lib.solaris-2.8-sun4u- 2.4/_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 09:45 Message: Logged In: YES user_id=11375 One use of mvwgetnwstr in the module is replaced by a manual emulation of the function, if STRICT_SYSV_CURSES is true, but another use isn't replaced; I suspect this is the problem. I've attached a patch that ensures that mvwgetnstr() is only used when STRICT_SYSV_CURSES is undefined. Please let me know if this fixes the compilation problem. ---------------------------------------------------------------------- Comment By: Nelson Arzola (narzola) Date: 2005-10-29 04:01 Message: Logged In: YES user_id=39023 I would like to add that this problem also exists under Solaris 2.10. For some reason, mvwgetnstr is not defined under Solaris 10. When I use nm to get the symbols out of /usr/lib/libcurses.so.1, I do not find it. When I replace the two references in /dsk/data0/build/Python-2.4.2/Modules/_cursesmodule.c from mvwgetnstr to mvwgetnwstr, I was able to compile the module and pass the appropriate tests. Since I don't use curses, I really don't have a good way to test this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 From noreply at sourceforge.net Tue Nov 22 15:47:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 06:47:24 -0800 Subject: [ python-Bugs-1309567 ] linecache module returns wrong results Message-ID: Bugs item #1309567, was opened at 2005-09-30 10:57 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 Please note that this 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: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) >Summary: linecache module returns wrong results Initial Comment: On several occasions I have seen tracebacks in my code pointing to PIL's __init__.py file. That is strange, because I have installed PIL but it is used nowhere. Finally I traced it down to a problem in the linecache code, which tries to be smart in up updatecache function. When os.stat() on the filename fails with os.error, it walks along sys.path and returns the first file with a matching basename. This *may* make sense for toplevel modules, but never for modules in packages. So, if the traceback's stack contains an entry for a non-existing file (for example because the .py file for a .pyc file is no longer present), linecache returns absolute garbage. Example, on my system (the \a\b\c\__init__.py file doesn't exist): C:\>python -c "import linecache; print linecache.getlines(r'\a\b\c\__init__.py')" ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'] C:\> The bug is present in 2.3, 2.4, and current CVS. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-09-30 13:12 Message: Logged In: YES user_id=11105 > But what about the use case of modules compiled on one system > and moved to a different system? Is that use case important > enough? Maybe. Couldn't the code be made more robust, so that it works as intended with packages? Unfortunately the code objects don't have a reference to the module where they live (probably because they are created before the module is created). BTW: The bug sometimes also is responsible for tracebacks in pydoc, because it cannot locate the sourceline in the file. So, wrong sourec in tracebacks aren't the only problem. It seems it would work better with relative pathnames, but it's too late for that. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-09-30 12:24 Message: Logged In: YES user_id=6380 Radical indeed. But what about the use case of modules compiled on one system and moved to a different system? Is that use case important enough? There used to be a different use case, because bytecode files used to contain relative path names. I believe that's been fixed, if only by code in site.py that absolutizes sys.path. (Except the initial '' -- is that important?) ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2005-09-30 11:08 Message: Logged In: YES user_id=11105 The attached patch is a radical way to fix this problem - it refuses to guess if the file is not found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309567&group_id=5470 From noreply at sourceforge.net Tue Nov 22 16:03:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 07:03:53 -0800 Subject: [ python-Bugs-449093 ] docs need to discuss // and __future__.division Message-ID: Bugs item #449093, was opened at 2001-08-08 08:39 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: docs need to discuss // and __future__.division Initial Comment: The operator needs to get new interfaces added in support of truediv and floordiv. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 10:03 Message: Logged In: YES user_id=11375 I've applied the suggested change to asttable.tex on both HEAD and release24-maint. Thanks for reporting this! ---------------------------------------------------------------------- Comment By: Matthew Leather (mleather) Date: 2004-11-28 01:10 Message: Logged In: YES user_id=959425 Problem persists in both versions. I am no expert but think this is fixed by inserting the following: \lineiii{FloorDiv}{\member{left}}{} \lineiii{}{\member{right}}{} \hline ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-25 19:11 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as "Won't fix". Thank you! . Facundo ---------------------------------------------------------------------- Comment By: Matthew Leather (mleather) Date: 2004-01-24 21:37 Message: Logged In: YES user_id=959425 FloorDiv node is not in Doc/lib/asttable.tex ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-07 13:06 Message: Logged In: YES user_id=80475 Can this be closed? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-10 11:58 Message: Logged In: YES user_id=3066 Added documentation for the operator.floordiv() and operator.truediv() in Doc/lib/liboperator.tex revision 1.20. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-09 16:22 Message: Logged In: YES user_id=3066 Added floordiv() and truediv() in Modules/operator.c revision 2.18. There's still plenty of documentation to be written regarding the changes in division, so I'm re-classifying this as a documentation request. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-08 08:40 Message: Logged In: YES user_id=6380 Also a reminder for Fred to add more docs for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:16:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:16:46 -0800 Subject: [ python-Bugs-1363712 ] A possible thinko in the description of os.chmod Message-ID: Bugs item #1363712, was opened at 2005-11-22 13:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363712&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Evgeny Roubinchtein (zhenya1007) Assigned to: Nobody/Anonymous (nobody) Summary: A possible thinko in the description of os.chmod Initial Comment: As of November 21, 2005, the description of os.chmod() function at the following URL: http://docs.python.org/lib/os-file-dir.html read: "chmod( path, mode) Change the mode of path to the numeric mode. mode may take *one of the following values* (as defined in the stat module):"[asterisks mine] Shouldn't "one of the following values" be "a bitwise OR of one or more of the following values", or similar verbage? ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:16 Message: Logged In: YES user_id=1188172 Corrected in revision 41509 and 41510 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1363712&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:18:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:18:25 -0800 Subject: [ python-Bugs-1359150 ] Prefer configured browser over Mozilla and friends Message-ID: Bugs item #1359150, was opened at 2005-11-17 18:47 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359150&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Ville Skytt?? (scop) Assigned to: Nobody/Anonymous (nobody) Summary: Prefer configured browser over Mozilla and friends Initial Comment: webbrowser.py in svn trunk seems to take user's GNOME configuration into account when selecting which browser to launch. That's good. What isn't good IMO is that it appears to try the Mozilla variants before that, thus ignoring the user's configured browser if a known Mozilla variant is installed. I'd suggest rearranging the first two blocks of register_X_browsers() so that the gconftool-2 block comes before the Mozilla/Netscape one. (Note that this is just from skimming the code; I don't have a svn trunk Python available, but was checking whether https://bugzilla.redhat.com/173275 would have been addressed upstream already.) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:18 Message: Logged In: YES user_id=1188172 Thanks, changed in rev 41511. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359150&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:25:21 -0800 Subject: [ python-Bugs-1359053 ] Incorrect documentation of raw unidaq string literals Message-ID: Bugs item #1359053, was opened at 2005-11-17 16:53 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359053&group_id=5470 Please note that this 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: Michael Haggerty (mhagger) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect documentation of raw unidaq string literals Initial Comment: In the Python Reference Manual, section 2.4.1 (String literals), the last paragraph contains the sentence: > When an "r" or "R" prefix is used in conjunction with > a "u" or "U" prefix, then the \uXXXX escape sequence > is processed while all other backslashes are left in > the string. I believe this is incorrect; \UXXXXXXXX sequences also seem to be processed (at least in Python 2.3.5 and 2.4.1), and it is also logical that they should be processed. The required change to the text is obvious: When an "r" or "R" prefix is used in conjunction with a "u" or "U" prefix, then the \uXXXX and \UXXXXXXXX escape sequences are processed while all other backslashes are left in the string. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:25 Message: Logged In: YES user_id=1188172 Thanks! Corrected in revisions 41512 and 41513 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1359053&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:31:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:31:42 -0800 Subject: [ python-Bugs-869197 ] setgroups rejects long integer arguments Message-ID: Bugs item #869197, was opened at 2004-01-02 10:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Closed Resolution: Accepted Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: setgroups rejects long integer arguments Initial Comment: os.setgroups ought to accept long integer arguments, just as os.setgid does. I think this worked in an earlier version of Python - or maybe it was that string.atol used to return a non-long integer if the number was small enough, so I didn't encounter long integers at all. >>> import os >>> os.setgid(1L) >>> os.setgroups((1L,)) Traceback (most recent call last): File "", line 1, in ? TypeError: groups must be integers >>> import sys >>> print sys.version 2.3.3 (#1, Dec 30 2003, 22:52:56) [GCC 3.2.3] ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:31 Message: Logged In: YES user_id=1188172 Committed in revs 41514 and 41515 (2.4). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:16 Message: Logged In: YES user_id=21627 The patch looks fine, please apply. Please remove the unused variable check, though. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:44 Message: Logged In: YES user_id=1188172 Adding enhanced patch. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 10:52 Message: Logged In: YES user_id=21627 Would that be the time to check that the value fits into a gid_t? I think the strategy would be this: - assign the value to grouplist[i] - read it back again - check if this is still the same value ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-29 22:36 Message: Logged In: YES user_id=1188172 Attaching patch against CVS head. Please review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=869197&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:44:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:44:11 -0800 Subject: [ python-Bugs-1255218 ] "appropriately decorated" is undefined in MultiFile.push doc Message-ID: Bugs item #1255218, was opened at 2005-08-09 21:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: "appropriately decorated" is undefined in MultiFile.push doc Initial Comment: At http://docs.python.org/lib/MultiFile-objects.html we read: push( str) Push a boundary string. When an appropriately decorated version of this boundary is found as an input line, it will be interpreted as a section-divider or end-marker. ... But this presumes that "appropriately decorated" is understood, which it won't be until multifile is understood. How about following that sentence with something like: (Appropriate decoration is determined by the section_divider and end_marker methods.) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:44 Message: Logged In: YES user_id=1188172 Thanks! Committed in rev 41517, 41518 (2.4). ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-10-17 12:06 Message: Logged In: YES user_id=174455 I commited a patch so the sentence reads: Push a boundary string. When the boundary is found as an input line, it will be interpreted as a section-divider or end-marker (depending on the boundary decoration. See \rfc{2045}). See patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1328526&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Alan (aisaac0) Date: 2005-08-11 22:58 Message: Logged In: YES user_id=1025672 IMO that works only if the term "appropriate decoration" occurs (appropriately) in those sections. And if it does, the relative location is probably irrelevant. This is really a problem of undefined terminology. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-08-11 19:11 Message: Logged In: YES user_id=593130 I agree that the sentence is confusing in its appropriate context. An alternative to the forward reference to the section_divider and end_marker methods is to move the entries for those methods just above the entry for the push method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1255218&group_id=5470 From noreply at sourceforge.net Tue Nov 22 20:51:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 11:51:18 -0800 Subject: [ python-Bugs-1261659 ] Tutorial doesn't cover * and ** function calls Message-ID: Bugs item #1261659, was opened at 2005-08-17 07:10 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 6 Submitted By: Brett Cannon (bcannon) Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial doesn't cover * and ** function calls Initial Comment: While the tutorial, in the section discussing function definitions, covers * and ** arguments, there is no aparent coverage of using them in a function call (e.g., ``open(*["file", "r"])``). ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 20:51 Message: Logged In: YES user_id=1188172 Committed patch by pterk. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-10-17 13:07 Message: Logged In: YES user_id=174455 I believe f(*seq) is covered in section 4.7.4 of the tutorial? (http://docs.python.org/tut/node6.html#SECTION006740000000000000000) I've commited a patch to also include an example for f(**dict). See: http://sourceforge.net/tracker/index.php?func=detail&aid=1328566&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-08-26 10:51 Message: Logged In: YES user_id=80475 That should be fixed. Do you have a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1261659&group_id=5470 From noreply at sourceforge.net Tue Nov 22 21:15:24 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 12:15:24 -0800 Subject: [ python-Bugs-1357604 ] os.path.makedirs DOES handle UNC paths Message-ID: Bugs item #1357604, was opened at 2005-11-15 21:40 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 Please note that this 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: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.makedirs DOES handle UNC paths Initial Comment: File: http://www.python.org/doc/current/lib/os-file-dir.html Paragraph: """ makedirs( path[, mode]) Recursive directory creation function. Like mkdir(), but makes all intermediate-level directories needed to contain the leaf directory. Throws an error exception if the leaf directory already exists or cannot be created. The default mode is 0777 (octal). This function does not properly handle UNC paths (only relevant on Windows systems; Universal Naming Convention paths are those that use the `\host\path' syntax). New in version 1.5.2. """ I just os.path.makedirs(...) with a UNC path and it DID create the desired folder on the specified host. The "in development" documentation is the same as the above documentation. I did not see any reference to this in the existing documentation bug reports. My particulars ... Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32 Windows XP-pro (all latest patches) ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 21:15 Message: Logged In: YES user_id=1188172 Committed patch by pterk. ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-11-18 12:41 Message: Logged In: YES user_id=174455 I looks like the os.path (see ntpath.py) module has been updated to deal with UNC-paths somewhere between the 2.2.3 and 2.3.5 releases. Confirmed to work with python 2.3.5 and 2.4.1. It does NOT work in python 2.2.3. I have submitted a patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1359879&group_id=5470&atid=305470) that removes the comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1357604&group_id=5470 From noreply at sourceforge.net Tue Nov 22 21:28:18 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 12:28:18 -0800 Subject: [ python-Bugs-1177811 ] Exec Inside A Function Message-ID: Bugs item #1177811, was opened at 2005-04-06 16:30 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andrew Wilkinson (andrew_j_w) Assigned to: Nobody/Anonymous (nobody) Summary: Exec Inside A Function Initial Comment: When 'exec'ing code that creates a function inside a function the defined function (fact in the example below) is created with the module level namespace as it's parent scope. The following should return 2 however it raises a NameError as fact is not defined. def f(): ? ? exec """ def fact(x): ? ? if x==1: ? ? ? ? return 1 ? ? else: ? ? ? ? return x*fact(x-1) """ ? ? return fact f()(2) If you run following code... def f(): ? ? exec """ def fact(x): ? ? if x==1: ? ? ? ? return 1 ? ? else: ? ? ? ? return x*fact(x-1) """ in locals() ? ? return fact ... it works as expected. The documentation states that "In all cases, if the optional parts are omitted, the code is executed in the current scope." That is clearly not the case here as the 'fact' function is set with the module level scope as it's parent scope. It would appear to me that either this a documentation bug or a flaw in exec. I sincerely hope this a bug in exec and not the desired behaviour as it doesn't make any sense to me... ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-22 21:28 Message: Logged In: YES user_id=1188172 I'd say this is too esoteric a use case that it can be considered a bug. Besides, as the OP demonstrates, there is a workaround, so I'm closing this. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 17:59 Message: Logged In: YES user_id=38376 As described in the language reference, scope analysis is done statically, during compilation. If the compiler cannot see your innermost function (because you've hidden it inside a string literal), it obviously cannot take any variables in there into account when generating code for the outer scopes. (I sincerely hope that this is a contrived example, and that you're not trying to use exec in this way in real code. Python might be a highly dynamic language, but it's not this dynamic.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1177811&group_id=5470 From noreply at sourceforge.net Tue Nov 22 21:56:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 12:56:12 -0800 Subject: [ python-Feature Requests-1351692 ] Switch to make pprint.pprint display ints and longs in hex Message-ID: Feature Requests item #1351692, was opened at 2005-11-08 22:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hirota (markhirota) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Switch to make pprint.pprint display ints and longs in hex Initial Comment: It would be nice to have some sort of switch or hook to allow 'pretty-printing' of integers and long integers in hexidecimal. So, for example: >>> import pprint >>> pprint.pprint(range(10)) # instead of this: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> pprint.hexint = True >>> pprint.pprint(range(10)) # you would get this: [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> pprint.pprint(range(0x100000000,0x100000010)) # and this: [0x100000000L, 0x100000001L, 0x100000002L, 0x100000003L, 0x100000004L, 0x100000005L, 0x100000006L, 0x100000007L, 0x100000008L, 0x100000009L, 0x10000000AL, 0x10000000BL, 0x10000000CL, 0x10000000DL, 0x10000000EL, 0x10000000FL] >>> Thanks, --MH ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2005-11-22 21:56 Message: Logged In: YES user_id=89016 I think this patch can go in. Any objections from Raymond or Fred against this? ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-17 02:04 Message: Logged In: YES user_id=1375527 Walter, I agree that there still seems to be an issue with _format() calling _repr() multiple times, however this patch seems to enable my feature request using sub- classing. Can the other issue (which exists presently also) be ignored for now? Could you submit the patch, or is that something I should do? Thanks. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-16 19:29 Message: Logged In: YES user_id=89016 Here's your modified version as a patch against svn HEAD. (Most of the patch is indentation changes. "svn diff --diff-cmd diff -x -b Lib/pprint.py" gives this diff: 134d133 < if sepLines: 154a154 > if sepLines: 155a156,157 > else: > write(', %s: ' % rep) 180a183 > if sepLines: 181a185,186 > else: > write(', ') 190d194 < 192a197 > The patch looks good, but it still has a problem that the original pprint has: For each call to format() the object is formatted twice, once to determine if it fits on one line and once for the final output. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 19:33 Message: Logged In: YES user_id=1375527 Did some digging into the code and found that the "if sepLines:" condition in the PrettyPrinter._format() method was the source of the limitation. I've attached a modified version of pprint.py where the "if sepLines" is more embedded. It gives the following results: >>> import pprintmod >>> class MyPrettyPrinter(pprintmod.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprintmod.PrettyPrinter.format( self, object, context, maxlevels, level) >>> mpp = MyPrettyPrinter() >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] >>> mpp.pprint(range(0x10000000,0x10000010)) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] >>> Would this be an acceptable change? Thanks, ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-14 18:04 Message: Logged In: YES user_id=1375527 Sorry, but maybe I could just interject here. Walter's sub- classing example works fine, except for the fact that if the string is short enough, it gets handled slightly differently and the format() override gets bypassed. I worked around this by shortening the width, but I've found that this screws with a lot of the nice formatting of other structures, and so basically creates a new set of problems. If the "format() bypass" limitation can be removed, I think it would allow for more reliable extensibility by subclassing PrettyPrinter. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-14 12:19 Message: Logged In: YES user_id=80475 Fred, any thoughts on the vision for your module? IMHO, pprinting containers with ints represented in hex is not an especially compelling motivation for a total rewrite. OTOH, it would be nice if the module were easily extensible.. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-14 10:54 Message: Logged In: YES user_id=89016 I find pprint.py hard to understand as it is. I've been staring at the code for several days now and the difference between PrettyPrinter._format(), PrettyPrinter.format(), PrettyPrinter._repr() and _safe_repr() is still not entirely clear to me. Using a subclass of int only makes sense, if it's your own data structure that you're outputting. If you get it from somewhere else, traversing it and replacing every int with an Int just for output really isn't an option. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-12 21:02 Message: Logged In: YES user_id=80475 IMO, such a rewrite would expose too many of pprint's internals and make the module harder to use/understand/maintain. Wouldn't it be better to stick with the usual idiom for controlling the repr() formatting of specific types by using a class wrapper: >>> from pprint import pprint >>> class Int(int): def __repr__(self): return hex(self) >>> pprint([Int(x) for x in range(0x10000000,0x10000010)]) [0x10000000, 0x10000001, 0x10000002, 0x10000003, 0x10000004, 0x10000005, 0x10000006, 0x10000007, 0x10000008, 0x10000009, 0x1000000a, 0x1000000b, 0x1000000c, 0x1000000d, 0x1000000e, 0x1000000f] ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-12 20:29 Message: Logged In: YES user_id=89016 I think it's more of a limitation. I seems to me the main focus in implementing pprint was speed not extensibility. The code uses every trick in the book (e.g. turning globals and builtins into locals, using bound methods etc.). I think it was never ment to do anything other than what repr() does, but with better formatting. However IMHO making pprint extensible would be a worthwile project. ---------------------------------------------------------------------- Comment By: Mark Hirota (markhirota) Date: 2005-11-11 18:47 Message: Logged In: YES user_id=1375527 Is this bypassing considered a limitation or a bug? I am, however, able to workaround the issue by setting the width=1: "mpp = MyPrettyPrinter(1,1)" -- it just means that instead of: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] I get instead: >>> mpp.pprint(range(10)) [0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9] ...which is OK for my uses. Thanks! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-11-10 23:56 Message: Logged In: YES user_id=89016 In theory this should be possible by subclassing pprint.PrettyPrinter and overwritting the format method: import pprint class MyPrettyPrinter(pprint.PrettyPrinter): def format(self, object, context, maxlevels, level): if isinstance(object, int): return hex(object), True, False else: return pprint.PrettyPrinter.format(self, object, context, maxlevels, level) mpp = MyPrettyPrinter() mpp.pprint(range(50)) This doesn't work reliable though: When the string is short enough, format() seems to be bypassed and repr() is called directly. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-09 22:45 Message: Logged In: YES user_id=1188172 Moving to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1351692&group_id=5470 From noreply at sourceforge.net Tue Nov 22 22:21:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 13:21:41 -0800 Subject: [ python-Bugs-777884 ] minidom.py -- TypeError: object doesn't support slice assig Message-ID: Bugs item #777884, was opened at 2003-07-25 20:22 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Lesh (leshmark) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: minidom.py -- TypeError: object doesn't support slice assig Initial Comment: Got the following traceback after upgrading to 2.3c1 Traceback (most recent call last): File "/root/alchemy/scripts/cvs/alchemy/alchemy_menu.py", line 178, in menu_system a=alchemy.Alchemy(name=name,step='alchemy') File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 89, in __init__ self.traverseNodes([self.start_node],exclude_tags=["evaporate","info"]) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 766, in traverseNodes node.normalize() File "/usr/lib/python2.3/xml/dom/minidom.py", line 208, in normalize self.childNodes[:] = L TypeError: object doesn't support slice assignment ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2005-11-22 16:21 Message: Logged In: YES user_id=11375 I can trigger this exception by calling the normalize() method on a childless DOM node such as Text. A little script is attached. The question is: what should normalize() do for a class such as Text? Looking at the DOM Level 1 specification, .normalize() is actually part of the Element interface, not Node, so things like Text.normalize() wouldn't work at all. One solution: move normalize() onto the Element class. Possibly backwards-incompatible. Another solution: add a normalize() method to the Childless mix-in that raises an exception. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 03:00 Message: Logged In: YES user_id=21627 It would definitely help if you could provide more detail on the nature of the failure. E.g. where did the DOM tree come from that Alchemy tries to invoke .normalize on, and what is self.childnodes in the place of the error. If you could instead submit a small example that allows reproduction of the error, that would help as well. ---------------------------------------------------------------------- Comment By: Mark Lesh (leshmark) Date: 2003-08-01 02:20 Message: Logged In: YES user_id=76540 The code worked again after I downgraded to Python 2.2.3. If you like I can replicate in a shorter and includable code snippet (I'd need to pop 2.3 back on my box first though) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-27 07:10 Message: Logged In: YES user_id=21627 Are you sure this is a bug in Python, and not in Alchemy? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 From noreply at sourceforge.net Wed Nov 23 13:51:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 04:51:42 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 17:07 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Rune Holm (titanstar) Assigned to: Michael Hudson (mwh) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2005-11-23 12:51 Message: Logged In: YES user_id=6656 Well, this isn't soon, but here's a patch to try. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-03 10:33 Message: Logged In: YES user_id=6656 Uh, yeah, completely my fault -- don't know what I was thinking. Should be easy to fix, I'll have a patch for you soon. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-02 17:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Wed Nov 23 19:51:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 10:51:44 -0800 Subject: [ python-Bugs-1257728 ] error message incorrectly claims Visual C++ is required Message-ID: Bugs item #1257728, was opened at 2005-08-12 15:28 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470 Please note that this 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 Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: error message incorrectly claims Visual C++ is required Initial Comment: Thank you for the excellent distutils tool! Two problems: First, this error message is emitted on win32, but it appears to be incorrect, inasmuch as the Microsoft compiler is not actually required: """ error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. Error: Subprocess exited with result 1 for project core """ Second, the usage of distutils is somewhat confusing, as the following line emits that error message: ./setup.py build -c mingw32; ./setup.py install but the following line, which I intuitively believed to be equivalent at first, works to compile and install the package: ./setup.py build -c mingw32 install ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2005-11-23 18:51 Message: Logged In: YES user_id=52562 Whoo! Progress! Now it no longer spuriously claims that Visual C++ is required for building extensions for Python, and instead it spuriously claims that the .NET SDK is required for building extensions for Python! """ error: The .NET Framework SDK needs to be installed before building extensions for Python. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257728&group_id=5470 From noreply at sourceforge.net Thu Nov 24 16:39:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 07:39:15 -0800 Subject: [ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values Message-ID: Bugs item #1281408, was opened at 2005-09-04 00:12 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Adal Chiriliuc (adalx) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Py_BuildValue k format units don't work with big values Initial Comment: Python 2.4 on Windows XP SP2 Consider this code: unsigned long x = 0xaabbccdd; PyObject* v = Py_BuildValue("k", x); unsigned long y = PyLong_AsUnsignedLong(v); y will be equal with -1 because PyLong_AsUnsignedLong will raise an OverflowError since Py_BuildValue doesn't create a long for the "k" format unit, but an int which will be interpreted as a negative number. The K format seems to have the same error, PyLong_FromLongLong is used instead of PyLong_FromUnsignedLongLong. The do_mkvalue function from mod_support.c must be fixed to use PyLong_FromUnsignedLong instead of PyInt_FromLong for "k". Also, the BHLkK format units for Py_BuildValue should be documented. In my Python 2.4 manual they do not appear. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-24 16:39 Message: Logged In: YES user_id=1188172 Corrected patch committed in rev. 41527 and 41528 (2.4). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:31 Message: Logged In: YES user_id=21627 The patch looks wrong: for 'I' (capital i), you va_arg unsigned long; I think 'I' should do unsigned int instead. A minor nit: why does it move the 'l' case (lower L)? Apart from that, the patch looks fine. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-11 09:45 Message: Logged In: YES user_id=1188172 Ping! ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-18 12:07 Message: Logged In: YES user_id=1188172 Attaching patch (including doc changes). For I and k, it creates an int if it fits, else a long. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-09-18 10:59 Message: Logged In: YES user_id=21627 I'm not sure what it should do: the other option would be to create an int if it fits, else a long. For 2.4.x atleast, this would give better backwards compatibility given the status quo. I certainly agree that the documentation should be updated. Patches are welcome. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-14 22:02 Message: Logged In: YES user_id=1188172 I think you're right. Do you too, Martin? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470 From noreply at sourceforge.net Fri Nov 25 02:20:52 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 17:20:52 -0800 Subject: [ python-Bugs-1365984 ] urllib cannot open data: urls Message-ID: Bugs item #1365984, was opened at 2005-11-25 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1365984&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Warren Butler (grumpymole) Assigned to: Nobody/Anonymous (nobody) Summary: urllib cannot open data: urls Initial Comment: Python 2.4.2 cannot open data: urls using open_data(). Appears to be because of importing cStringIO and not being able to reference fileno. ============================================== Example fail output: Traceback (most recent call last): File "test_open_data.py", line 6, in ? response = opener.open("data:,A%20brief%20note") File "/usr/lib/python2.4/urllib.py", line 185, in open return getattr(self, name)(url) File "/usr/lib/python2.4/urllib.py", line 559, in open_data f.fileno = None # needed for addinfourl AttributeError: 'cStringIO.StringI' object has no attribute 'fileno' ============================================== Example code to generate failure: import urllib # data:,A%20brief%20note opener = urllib.URLopener() response = opener.open("data:,A%20brief%20note") ============================================== Note: works in 2.2 version of library. Problem appears to be here in 2.4: import mimetools try: from cStringIO import StringIO except ImportError: from StringIO import StringIO whereas 2.2 reads: import StringIO, mimetools, time ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1365984&group_id=5470 From noreply at sourceforge.net Fri Nov 25 03:14:41 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 18:14:41 -0800 Subject: [ python-Bugs-1366000 ] Bug bz2.BZ2File(...).seek(0,2) Message-ID: Bugs item #1366000, was opened at 2005-11-25 03:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366000&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: Bug bz2.BZ2File(...).seek(0,2) Initial Comment: Hi, Look at the following code: import bz2 bz2.BZ2File("test.bz2","r") bz2.seek(0,2) assert bz2.tell() != 0 seek() method is buggy (when 0<=offset and where=2). I wrote a patch. Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366000&group_id=5470 From noreply at sourceforge.net Fri Nov 25 03:21:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Nov 2005 18:21:07 -0800 Subject: [ python-Bugs-1366000 ] Bug bz2.BZ2File(...).seek(0,2) Message-ID: Bugs item #1366000, was opened at 2005-11-25 03:14 Message generated for change (Comment added) made by haypo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366000&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: Bug bz2.BZ2File(...).seek(0,2) Initial Comment: Hi, Look at the following code: import bz2 bz2.BZ2File("test.bz2","r") bz2.seek(0,2) assert bz2.tell() != 0 seek() method is buggy (when 0<=offset and where=2). I wrote a patch. Haypo ---------------------------------------------------------------------- >Comment By: STINNER Victor (haypo) Date: 2005-11-25 03:21 Message: Logged In: YES user_id=365388 Please check it :-) I'm not sure that it works well because I'm new in CPython code. Oooooops ... I just tried my code, and seek(x,2) with 0 Bugs item #1366250, was opened at 2005-11-25 13:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 Please note that this 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: Michael Dunn (popuptoaster) Assigned to: Nobody/Anonymous (nobody) Summary: inoorrect documentation for optparse Initial Comment: The page http://www.python.org/doc/current/lib/optparse-parsing-arguments.html in the current documentation has text with an incorrect example: """ 6.21.3.7 Parsing arguments The whole point of creating and populating an OptionParser is to call its parse_args() method: (options, args) = parser.parse_args(args=None, options=None) where the input parameters are args the list of arguments to process (sys.argv[1:] by default) options object to store option arguments in (a new instance of optparse.Values by default) """ The example should be changed to: (options, args) = parser.parse_args(args=None, values=None) ^^^^^^ And then there should be a correstponding substition below in the explanation of the keyword arguments: values ^^^^^^ object to store option arguments in (a new instance of optparse.Values by default) Cheers, Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 From noreply at sourceforge.net Fri Nov 25 13:22:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 04:22:57 -0800 Subject: [ python-Bugs-1366250 ] incorrect documentation for optparse Message-ID: Bugs item #1366250, was opened at 2005-11-25 13:22 Message generated for change (Settings changed) made by popuptoaster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 Please note that this 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: Michael Dunn (popuptoaster) Assigned to: Nobody/Anonymous (nobody) >Summary: incorrect documentation for optparse Initial Comment: The page http://www.python.org/doc/current/lib/optparse-parsing-arguments.html in the current documentation has text with an incorrect example: """ 6.21.3.7 Parsing arguments The whole point of creating and populating an OptionParser is to call its parse_args() method: (options, args) = parser.parse_args(args=None, options=None) where the input parameters are args the list of arguments to process (sys.argv[1:] by default) options object to store option arguments in (a new instance of optparse.Values by default) """ The example should be changed to: (options, args) = parser.parse_args(args=None, values=None) ^^^^^^ And then there should be a correstponding substition below in the explanation of the keyword arguments: values ^^^^^^ object to store option arguments in (a new instance of optparse.Values by default) Cheers, Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 From noreply at sourceforge.net Fri Nov 25 14:57:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 05:57:15 -0800 Subject: [ python-Bugs-1366311 ] SRE engine do not release the GIL Message-ID: Bugs item #1366311, was opened at 2005-11-25 13:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 Please note that this 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: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 From noreply at sourceforge.net Fri Nov 25 15:02:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 06:02:48 -0800 Subject: [ python-Bugs-1366311 ] SRE engine do not release the GIL Message-ID: Bugs item #1366311, was opened at 2005-11-25 13:57 Message generated for change (Comment added) made by eric_noyau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 Please note that this 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: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- >Comment By: Eric Noyau (eric_noyau) Date: 2005-11-25 14:02 Message: Logged In: YES user_id=1388768 I'm attaching a diff to this bug that remove this limitation if it sane to do so. If a search is done on a string or a unicode object (which by definition are immutable) the GIL is released and reacquired everytime a search is done. I've tested this patch in both a simple tests (start a thread with a greedy regex on a monstruous string and verify that the othe python threads are still active) and by running our internal application verifying that nothing is blocking anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 From noreply at sourceforge.net Fri Nov 25 22:38:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 13:38:57 -0800 Subject: [ python-Bugs-1366311 ] SRE engine do not release the GIL Message-ID: Bugs item #1366311, was opened at 2005-11-25 13:57 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 Please note that this 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: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2005-11-25 21:38 Message: Logged In: YES user_id=4771 The patch looks good, but I wonder if it is safe. The SRE_STATE structure that SRE_SEARCH_INNER uses is potentially visible to the application-level Python code, via the (undocumented) scanner objects: >>> r = re.compile(r"hello") >>> s = r.scanner("big string in which to search") >>> s.search() <_sre.SRE_Match object at 0x12345678> Each call to s.search() continues the previous search with the same SRE_STATE. The problem with releasing the GIL as you do is that several threads could call s.search() concurrently, which would most probably crash CPython. This probably means that you need to add a lock in SRE_STATE and acquire it while searching, to serialize its usage. Of course, we should then be careful about what overhead this gives to applications that use regexps on a lot of small strings... Another note: for consistency, match() should also release the GIL if search() does. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-25 14:02 Message: Logged In: YES user_id=1388768 I'm attaching a diff to this bug that remove this limitation if it sane to do so. If a search is done on a string or a unicode object (which by definition are immutable) the GIL is released and reacquired everytime a search is done. I've tested this patch in both a simple tests (start a thread with a greedy regex on a monstruous string and verify that the othe python threads are still active) and by running our internal application verifying that nothing is blocking anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 From noreply at sourceforge.net Sat Nov 26 17:33:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 08:33:00 -0800 Subject: [ python-Bugs-698706 ] imaplib: parsing INTERNALDATE Message-ID: Bugs item #698706, was opened at 2003-03-06 14:45 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Konrad Hinsen (hinsen) Assigned to: Piers Lauder (pierslauder) Summary: imaplib: parsing INTERNALDATE Initial Comment: The regular expression InternalDate in imaplib does not match dates in which the day number is two-digit with a leading zero. >From a cursory glance at the IMAP definition, this is a legal format, and there is at least one IMAP server that uses it (courier-imap). The attached patch is for Python 2.2.2, but the problem still exists in 2.3a2. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-26 17:32 Message: Logged In: YES user_id=1188172 Already corrected in the 2.5 branch. Corrected in the 2.4 branch in revision 41547. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-01-15 13:41 Message: Logged In: YES user_id=752496 This patch is not yet applied in CVS. Piers, I assign this to you because you know the module, but the patch is pretty simple, it's just adding a 0 to a part of the InternalDate's re: From: (?P[ 123] To: (?P[ 0123] ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2004-04-23 03:43 Message: Logged In: YES user_id=552329 This is correct, RFC 2060 allows for the date to be "2digit", where digit includes 0. There is no attached patch, but I can't attach to this tracker, so I'm putting it here in the comment (it's a one character change). This still exists in 2004-04-23 anon cvs. *** imaplib.py Fri Apr 23 13:40:32 2004 --- imaplib-fixed.py Fri Apr 23 13:42:31 2004 *************** *** 79,85 **** Continuation = re.compile(r'\+( (?P.*))?') Flags = re.compile(r'.*FLAGS \((?P[^\)]*)\)') InternalDate = re.compile(r'.*INTERNALDATE "' ! r'(?P[ 123][0-9])-(?P[A-Z][a-z][a-z])-(?P[0-9][0-9][0- 9][0-9])' r' (?P[0-9][0-9]):(?P[0-9][0-9]):(?P[0-9][0-9])' r' (?P[-+])(?P[0-9][0-9])(?P[0-9][0-9])' r'"') --- 79,85 ---- Continuation = re.compile(r'\+( (?P.*))?') Flags = re.compile(r'.*FLAGS \((?P[^\)]*)\)') InternalDate = re.compile(r'.*INTERNALDATE "' ! r'(?P[ 0123][0-9])-(?P[A-Z][a-z][a-z])-(?P[0-9][0-9][0 -9][0-9])' r' (?P[0-9][0-9]):(?P[0-9][0-9]):(?P[0-9][0-9])' r' (?P[-+])(?P[0-9][0-9])(?P[0-9][0-9])' r'"') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=698706&group_id=5470 From noreply at sourceforge.net Sat Nov 26 17:37:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 08:37:01 -0800 Subject: [ python-Bugs-1366250 ] incorrect documentation for optparse Message-ID: Bugs item #1366250, was opened at 2005-11-25 13:22 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 Please note that this 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: Michael Dunn (popuptoaster) >Assigned to: Greg Ward (gward) Summary: incorrect documentation for optparse Initial Comment: The page http://www.python.org/doc/current/lib/optparse-parsing-arguments.html in the current documentation has text with an incorrect example: """ 6.21.3.7 Parsing arguments The whole point of creating and populating an OptionParser is to call its parse_args() method: (options, args) = parser.parse_args(args=None, options=None) where the input parameters are args the list of arguments to process (sys.argv[1:] by default) options object to store option arguments in (a new instance of optparse.Values by default) """ The example should be changed to: (options, args) = parser.parse_args(args=None, values=None) ^^^^^^ And then there should be a correstponding substition below in the explanation of the keyword arguments: values ^^^^^^ object to store option arguments in (a new instance of optparse.Values by default) Cheers, Michael ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-26 17:37 Message: Logged In: YES user_id=1188172 Assigning to Greg as he maintains the upstream Optik distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366250&group_id=5470 From noreply at sourceforge.net Sat Nov 26 17:52:01 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 08:52:01 -0800 Subject: [ python-Bugs-1365984 ] urllib cannot open data: urls Message-ID: Bugs item #1365984, was opened at 2005-11-25 02:20 Message generated for change (Settings changed) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1365984&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Warren Butler (grumpymole) Assigned to: Nobody/Anonymous (nobody) Summary: urllib cannot open data: urls Initial Comment: Python 2.4.2 cannot open data: urls using open_data(). Appears to be because of importing cStringIO and not being able to reference fileno. ============================================== Example fail output: Traceback (most recent call last): File "test_open_data.py", line 6, in ? response = opener.open("data:,A%20brief%20note") File "/usr/lib/python2.4/urllib.py", line 185, in open return getattr(self, name)(url) File "/usr/lib/python2.4/urllib.py", line 559, in open_data f.fileno = None # needed for addinfourl AttributeError: 'cStringIO.StringI' object has no attribute 'fileno' ============================================== Example code to generate failure: import urllib # data:,A%20brief%20note opener = urllib.URLopener() response = opener.open("data:,A%20brief%20note") ============================================== Note: works in 2.2 version of library. Problem appears to be here in 2.4: import mimetools try: from cStringIO import StringIO except ImportError: from StringIO import StringIO whereas 2.2 reads: import StringIO, mimetools, time ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-11-26 17:52 Message: Logged In: YES user_id=1188172 Fixed in revision 41548 and 41549 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1365984&group_id=5470 From noreply at sourceforge.net Sat Nov 26 19:00:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 10:00:51 -0800 Subject: [ python-Bugs-1346144 ] Segfaults from unaligned loads in floatobject.c Message-ID: Bugs item #1346144, was opened at 2005-11-02 18:07 Message generated for change (Comment added) made by titanstar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Rune Holm (titanstar) Assigned to: Michael Hudson (mwh) Summary: Segfaults from unaligned loads in floatobject.c Initial Comment: Object/floatobject.c:_PyFloat_Unpack8 from svn head performs an unaligned load of a double, causing the cPickle unit test to fail on linux/mips and openbsd/sparc64. http://pxr.openlook.org/pxr/ diff/Objects/floatobject.c?v=release24- maint;diffval=head;diffvar=v reveals that somebody has added a fast path in _PyFloat_Unpack8 since 2.4 that fails to check for unaligned accesses, and therefore performs an illegal operation on architectures that don't support unaligned accesses. Here is the relevant traceback from linux/mips: (gdb) run Lib/test/test_cpickle.py Starting program: /ping/wirth/home0/runehol/projects/python-mips/ python Lib/test/test_cpickle.py [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4379)] test_callapi (__main__.cPickleTests) ... ok test_dict_chunking (__main__.cPickleTests) ... ok test_dump_closed_file (__main__.cPickleTests) ... ok test_garyp (__main__.cPickleTests) ... ok test_getinitargs (__main__.cPickleTests) ... ok test_global_ext1 (__main__.cPickleTests) ... ok test_global_ext2 (__main__.cPickleTests) ... ok test_global_ext4 (__main__.cPickleTests) ... ok test_highest_protocol (__main__.cPickleTests) ... ok test_insecure_strings (__main__.cPickleTests) ... ok test_ints (__main__.cPickleTests) ... ok test_list_chunking (__main__.cPickleTests) ... ok test_load_closed_file (__main__.cPickleTests) ... ok Program received signal SIGBUS, Bus error. [Switching to Thread 16384 (LWP 4379)] 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 1737 return *(double*)p; (gdb) bt #0 0x004414e0 in _PyFloat_Unpack8 (p=0x2b05282f "@", le=0) at Objects/floatobject.c:1737 #1 0x2b10a750 in load_binfloat (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:3361 #2 0x2b113674 in load (self=0x2b0dc308) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:4480 #3 0x2b1186ac in cpm_loads (self=0x0, args=0x2b2c2c78) at /ping/wirth/home0/runehol/projects/python-mips/Modules/ cPickle.c:5476 #4 0x005c45f4 in PyCFunction_Call (func=0x2b0d92b8, arg=0x2b2c2c78, kw=0x0) at Objects/methodobject.c:73 #5 0x0050f8f0 in call_function (pp_stack=0x7fff1e68, oparg=1) at Python/ceval.c:3565 #6 0x0050710c in PyEval_EvalFrameEx (f=0x10080868, throw=0) at Python/ceval.c:2181 #7 0x00510078 in fast_function (func=0x2b222da0, pp_stack=0x7fff2428, n=1, na=1, nk=0) at Python/ceval.c:3647 #8 0x0050fc14 in call_function (pp_stack=0x7fff2428, oparg=0) at Python/ceval.c:3586 #9 0x0050710c in PyEval_EvalFrameEx (f=0x10034eb0, throw=0) at Python/ceval.c:2181 #10 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d38, globals=0x2b0cd4d0, locals=0x0, args=0x2b22820c, argcount=2, kws=0x2b2c5048, kwcount=0, defs=0x2b0e7b3c, defcount=1, closure=0x0) at Python/ceval.c: 2739 #11 0x005c3260 in function_call (func=0x2b0ee248, arg=0x2b2281f8, ---Type to continue, or q to quit--- kw=0x2b2c4578) at Objects/funcobject.c:550 #12 0x0041e8dc in PyObject_Call (func=0x2b0ee248, arg=0x2b2281f8, kw=0x2b2c4578) at Objects/abstract.c:1777 #13 0x005112b8 in ext_do_call (func=0x2b0ee248, pp_stack=0x7fff2aa8, flags=3, na=1, nk=0) at Python/ceval.c:3842 #14 0x00507534 in PyEval_EvalFrameEx (f=0x100347c8, throw=0) at Python/ceval.c:2221 #15 0x0050b0d4 in PyEval_EvalCodeEx (co=0x2b0d5d90, globals=0x2b0cd4d0, locals=0x0, args=0x2b22824c, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2739 #16 0x005c3260 in function_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/funcobject.c:550 #17 0x0041e8dc in PyObject_Call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/abstract.c:1777 #18 0x00430b7c in instancemethod_call (func=0x2b0ee2a0, arg=0x2b228238, kw=0x0) at Objects/classobject.c:2447 #19 0x0041e8dc in PyObject_Call (func=0x2b0aaf38, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #20 0x004b5c80 in slot_tp_call (self=0x2b1f5118, args=0x2b2c2b60, kwds=0x0) at Objects/typeobject.c:4530 #21 0x0041e8dc in PyObject_Call (func=0x2b1f5118, arg=0x2b2c2b60, kw=0x0) at Objects/abstract.c:1777 #22 0x00510d08 in do_call (func=0x2b1f5118, pp_stack=0x7fff3460, na=1, nk=0) at Python/ceval.c:3773 ---Type to continue, or q to quit--- ---------------------------------------------------------------------- >Comment By: Rune Holm (titanstar) Date: 2005-11-26 19:00 Message: Logged In: YES user_id=858364 Your patch to _PyFloat_Unpack4 loaded a float into the first half of a double, but after I fixed it to load into a float, the test suite passed on x86, sparc64 and mips. The revised patch should be attached. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-23 13:51 Message: Logged In: YES user_id=6656 Well, this isn't soon, but here's a patch to try. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-11-03 11:33 Message: Logged In: YES user_id=6656 Uh, yeah, completely my fault -- don't know what I was thinking. Should be easy to fix, I'll have a patch for you soon. ---------------------------------------------------------------------- Comment By: Rune Holm (titanstar) Date: 2005-11-02 18:38 Message: Logged In: YES user_id=858364 Some more digging reveals that the problem is caused by the patches from https://sourceforge.net/tracker/index.php? func=detail&aid=1181301&group_id=5470&atid=305470 and there is a similar problem in _PyFloat_Unpack4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1346144&group_id=5470 From noreply at sourceforge.net Sat Nov 26 22:42:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 13:42:32 -0800 Subject: [ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__ Message-ID: Bugs item #1367183, was opened at 2005-11-26 12:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getdoc fails on objs that use property for __doc__ Initial Comment: inspect.getdoc has these lines: if not isinstance(doc, types.StringTypes): return None which interfere with the case where __doc__ is some other thing that has a good __str__. I wanted to make a lazy __doc__ that did an expensive lookup of some external documentation only when it was str()'d, but since doc displayers often (correctly) use inspect.getdoc, they were getting None. I think the intention of the test in getdoc() is to avoid trying string operations on a __doc__ that is None. I think that a more lenient version would allow me to do my fancy docstrings but still solve the '__doc__ is None' problem. Please consider the following patch: if doc is None: return None doc = str(doc) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 From noreply at sourceforge.net Sun Nov 27 02:50:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 17:50:54 -0800 Subject: [ python-Bugs-1337987 ] IDLE, F5 – wrong external file content. (on error!) Message-ID: Bugs item #1337987, was opened at 2005-10-26 04:12 Message generated for change (Comment added) made by tyrell_rr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE, F5 – wrong external file content. (on error!) Initial Comment: IDLE, F5 ? wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik ---------------------------------------------------------------------- >Comment By: MvGulik (tyrell_rr) Date: 2005-11-27 02:50 Message: Logged In: YES user_id=779309 wow ... nevermind ... Bye bye. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2005-11-15 06:54 Message: Logged In: YES user_id=149084 Duplicate of RFE 1175686. Please read the comments on that Tracker item. IDLE is intended to edit its own code. Apparently you are using an external editor. It's not a high priority for me to support that, since IDLE has one-keystroke save, load and run. The guy who submitted the RFE never came back with a use case; what's your use for this feature? IDLE would have to detect that the file had changed on disk. Not difficult, just not done right now. ---------------------------------------------------------------------- Comment By: MvGulik (tyrell_rr) Date: 2005-10-28 11:46 Message: Logged In: YES user_id=779309 > Save with Control-S before pressing F5. Don't think that a good idee. This will save the initially loaded old file content inside IDLE over the new file content (external edited -> not using IDLE for editing) Effectingly undoing all the changes done with the external editor. M.v.Gulik. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-26 04:45 Message: Logged In: YES user_id=80475 Save with Control-S before pressing F5. ---------------------------------------------------------------------- Comment By: MvGulik (tyrell_rr) Date: 2005-10-26 04:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 From noreply at sourceforge.net Sun Nov 27 18:47:58 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:47:58 -0800 Subject: [ python-Bugs-1367631 ] maximum length not enforce in cgi.parse() Message-ID: Bugs item #1367631, was opened at 2005-11-27 17:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367631&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Rogers (adr26) Assigned to: Nobody/Anonymous (nobody) Summary: maximum length not enforce in cgi.parse() Initial Comment: I have a simple form in HTML to upload a file:

Please specify a file:

I use this to post to a CGI python script that looks like this: import cgi import cgitb; cgitb.enable() cgi.maxlen = 50 print "Content-type: text/plain" print q = cgi.parse() print q I was expecting that cgi.pm would then throw an exception if I send a file > 50 bytes long to it. If I construct a FieldStorage object, it certainly does: form = cgi.FieldStorage() print form The issue is that in parse_multipart() in cgi.pm, if a part of a multi-part message does not have the Content-Length header, you read lines until you get to the next boundary "--...", but don't honour maxlen whilst doing so. I'd consider this to be a bug and would even be happy to have a go at fixing it as my first contribution to Python, should others concur with me... :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367631&group_id=5470 From noreply at sourceforge.net Sun Nov 27 18:48:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:48:44 -0800 Subject: [ python-Bugs-1367631 ] maximum length not enforced in cgi.parse() Message-ID: Bugs item #1367631, was opened at 2005-11-27 17:47 Message generated for change (Settings changed) made by adr26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367631&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Rogers (adr26) Assigned to: Nobody/Anonymous (nobody) >Summary: maximum length not enforced in cgi.parse() Initial Comment: I have a simple form in HTML to upload a file:

Please specify a file:

I use this to post to a CGI python script that looks like this: import cgi import cgitb; cgitb.enable() cgi.maxlen = 50 print "Content-type: text/plain" print q = cgi.parse() print q I was expecting that cgi.pm would then throw an exception if I send a file > 50 bytes long to it. If I construct a FieldStorage object, it certainly does: form = cgi.FieldStorage() print form The issue is that in parse_multipart() in cgi.pm, if a part of a multi-part message does not have the Content-Length header, you read lines until you get to the next boundary "--...", but don't honour maxlen whilst doing so. I'd consider this to be a bug and would even be happy to have a go at fixing it as my first contribution to Python, should others concur with me... :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367631&group_id=5470 From noreply at sourceforge.net Mon Nov 28 00:31:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 15:31:17 -0800 Subject: [ python-Bugs-1367814 ] loogger module locks Message-ID: Bugs item #1367814, was opened at 2005-11-27 17:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367814&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Chris Fuller (cfuller) Assigned to: Nobody/Anonymous (nobody) Summary: loogger module locks Initial Comment: I have an application that uses the logger functionality, and the RotatingFileHandler class. If my application is running, and another instance is launched, it fails at the rollover step. I don't want multiple instances running at once, so this is fine, and even general, since the rollover must occur if an instance is already running. Rather than checking for a generic I/O error, however, I'd like to use some sort of locking mechanism that is less opaque. The locking provided won't work, since it is blocking only: the application deadlocks if one ias runnning already. Why doesn't it work like a normal Lock() instance and take a blocking parameter? I could use locking via the portalocker module from the python cookbook (hmm, portable file locking would be a nice thing to have in the standard library, the logger module already does it anyway!) but I can't find anyway to access the file descriptor! Sure, I could workaround that. I could create a RotatingFileHandler instance, roll over, close it, open the file, pass it to StreamHandler, but python is way more elegant than that. For now, I'll just trap the rollover. Still very cool stuff! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367814&group_id=5470 From noreply at sourceforge.net Mon Nov 28 06:13:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 21:13:00 -0800 Subject: [ python-Feature Requests-1367936 ] split() string method has two splitting algorithms Message-ID: Feature Requests item #1367936, was opened at 2005-11-28 06:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 Please note that this 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: crackwitz (crackwitz) Assigned to: Nobody/Anonymous (nobody) Summary: split() string method has two splitting algorithms Initial Comment: The docs of Python 2.4.2 for .split([sep [,maxsplit]]) say: "If sep is not specified or is None, a different splitting algorithm is applied." I would like to see that behavior exposed and consistent, i.e. stripping (new key strip=...?) independent of whether sep is None or not. Making it consistent could break existing code because people already built on split()'s special behavior. You could say strip=None by default and only keep switching if strip==None. I don't like this magic behavior though because there's no reason for it to exist. # this is now (Python v2.4.2) ' foo bar '.split() # => ['foo', 'bar'] ' foo bar '.split(' ') # => ['', 'foo', '', 'bar', ''] # this is how I would like it to be ' foo bar '.split(strip=True) # => ['foo', 'bar'] ' foo bar '.split(strip=False) # => ['', 'foo', '', 'bar', ''] # compatibility preserved (strip=None by default): ' foo bar '.split(strip=None) # => ['foo', 'bar'] ' foo bar '.split(' ', strip=None) # => ['', 'foo', '', 'bar', ''] what do you think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 From noreply at sourceforge.net Mon Nov 28 11:21:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 02:21:45 -0800 Subject: [ python-Feature Requests-1368091 ] shutils cannot copy owner Message-ID: Feature Requests item #1368091, was opened at 2005-11-28 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1368091&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pierre Ossman (dr7eus) Assigned to: Nobody/Anonymous (nobody) Summary: shutils cannot copy owner Initial Comment: shutils is a nice wrapper for handling copying of files. But it currently falls short of being able to make an exact copy of a file. What is missing is the possibility to copy ownership of a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1368091&group_id=5470 From noreply at sourceforge.net Mon Nov 28 15:11:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 06:11:10 -0800 Subject: [ python-Bugs-1366311 ] SRE engine do not release the GIL Message-ID: Bugs item #1366311, was opened at 2005-11-25 13:57 Message generated for change (Comment added) made by eric_noyau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 Please note that this 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: Eric Noyau (eric_noyau) Assigned to: Nobody/Anonymous (nobody) Summary: SRE engine do not release the GIL Initial Comment: In a multi-threaded program that does lots of regular expression searching, some of them on very long strings with complex regex we've noticed that everything stops when a regular expression is searching. One of the issue is that the re engine does not release the interpreter lock while it is running. All the other threads are therefore blocked for the entire time it takes to do the regular expression search. See the thread in python-dev about it: http://mail.python.org/pipermail/python-dev/2005-November/058316.html ---------------------------------------------------------------------- >Comment By: Eric Noyau (eric_noyau) Date: 2005-11-28 14:11 Message: Logged In: YES user_id=1388768 Thanks for your comments. I've updated the patch to fix your issues, but without introducing a per-state object lock. What I did instead is to mark a state as not supporting concurrency when a scanner object creates it. So the GIL will not be released for scanners objects at all. For consistency match also release the GIL now, if possible. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-11-25 21:38 Message: Logged In: YES user_id=4771 The patch looks good, but I wonder if it is safe. The SRE_STATE structure that SRE_SEARCH_INNER uses is potentially visible to the application-level Python code, via the (undocumented) scanner objects: >>> r = re.compile(r"hello") >>> s = r.scanner("big string in which to search") >>> s.search() <_sre.SRE_Match object at 0x12345678> Each call to s.search() continues the previous search with the same SRE_STATE. The problem with releasing the GIL as you do is that several threads could call s.search() concurrently, which would most probably crash CPython. This probably means that you need to add a lock in SRE_STATE and acquire it while searching, to serialize its usage. Of course, we should then be careful about what overhead this gives to applications that use regexps on a lot of small strings... Another note: for consistency, match() should also release the GIL if search() does. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2005-11-25 14:02 Message: Logged In: YES user_id=1388768 I'm attaching a diff to this bug that remove this limitation if it sane to do so. If a search is done on a string or a unicode object (which by definition are immutable) the GIL is released and reacquired everytime a search is done. I've tested this patch in both a simple tests (start a thread with a greedy regex on a monstruous string and verify that the othe python threads are still active) and by running our internal application verifying that nothing is blocking anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1366311&group_id=5470 From noreply at sourceforge.net Mon Nov 28 16:37:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 07:37:40 -0800 Subject: [ python-Bugs-1368312 ] fix for scheme identification in urllib2? Message-ID: Bugs item #1368312, was opened at 2005-11-28 10:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368312&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ben Boals (bboals) Assigned to: Nobody/Anonymous (nobody) Summary: fix for scheme identification in urllib2? Initial Comment: I was looking at the following piece of code in urllib2 def http_error_auth_reqed(self, auth_header, host, req, headers): authreq = headers.get(auth_header, None) if self.retried > 5: # Don't fail endlessly - if we failed once, we'll probably # fail a second time. Hm. Unless the Password Manager is # prompting for the information. Crap. This isn't great # but it's better than the current 'repeat until recursion # depth exceeded' approach raise HTTPError(req.get_full_url(), 401, "digest auth failed", headers, None) else: self.retried += 1 if authreq: scheme = authreq.split()[0] if scheme.lower() == 'digest': return self.retry_http_digest_auth(req, authreq) else: raise ValueError("AbstractDigestAuthHandler doesn't know " "about %s"%(scheme)) The particular thing that concerns me is scheme = scheme = authreq.split()[0] if scheme.lower() == 'digest': Quite frequently, when there are multiple auth schemes allowed, digest is NOT the first one in the list. I would suggest substituting schemes = authreq.lower().split(',')##a list of schemes allowed, all lowercase if('digest' in schemes): and if needed, fixing the call to retry_http_digest_auth so that the authreq passed is valid (assuming for some reason it assumes the digest is first) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368312&group_id=5470 From noreply at sourceforge.net Mon Nov 28 17:39:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 08:39:06 -0800 Subject: [ python-Bugs-1368368 ] prompt_user_passwd() in FancyURLopener Message-ID: Bugs item #1368368, was opened at 2005-11-28 17:39 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368368&group_id=5470 Please note that this 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: Bj?rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: prompt_user_passwd() in FancyURLopener Initial Comment: Currently, urllib.urlopen() "kind of" handles HTTP authentication. You simply write something like this: urllib.urlopen("http://foo:bar at www.moo.com") And it works like a charm. EXCEPT when the username/password is wrong. Then you get the FancyURLopener.prompt_user_passwd()-prompt asking you for your username and password. I think that behaviour is extremely illogical and annoying because it forces you to add more code just to circumvent the odd default behaviour. I would be MUCH happer if, instead of the prompt, you get an exception or the 401 Unauthorized error page returned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368368&group_id=5470 From noreply at sourceforge.net Mon Nov 28 18:36:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 09:36:13 -0800 Subject: [ python-Bugs-1167262 ] Fails assertion in winsig.c under VC 8.0 Message-ID: Bugs item #1167262, was opened at 2005-03-21 04:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Timothy Fitz (timothyfitz) Assigned to: Nobody/Anonymous (nobody) Summary: Fails assertion in winsig.c under VC 8.0 Initial Comment: In 2.4 and current cvs initsignal in signalmodule.c calls PyOS_getsig which calls signal with an invalid signal number. Under VC 7.1 (and 7.0, and probably before) this would return SIG_ERR however under VC 8.0 (beta) this causes an assertion failure. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2005-11-28 18:36 Message: Logged In: YES user_id=21627 This is now fixed with patch #1350409. ---------------------------------------------------------------------- Comment By: Atul Varma (varmaa) Date: 2005-11-18 17:10 Message: Logged In: YES user_id=863202 Just wanted to mention that the Visual Studio 2005 products were officially launched on November 7th, 2005, and this same problem occurs when compiling the Python 2.4 source using Visual C++ 2005 Express Edition. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-12 09:54 Message: Logged In: YES user_id=21627 See #1311784 for more discussion of this problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-04-02 00:02 Message: Logged In: YES user_id=21627 C99 7.14.1.1/p8 specifies # If the request can be honored, the signal function # returns the value of func for the most recent successful # call to signal for the specified signal sig. Otherwise, a # value of SIG_ERR is returned and a positive value is stored # in errno. So it seems to me that VC8 is in error: the request cannot be "honored", so it should return SIG_ERR. Until/if VC8 is released with that bug, I would like to take no action here. When it is released, we still might consider to ignore it until say, 8.1 comes along and fixes the bug. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-03-27 22:59 Message: Logged In: YES user_id=6656 Ew. My first thought is, is that allowed by ANSI C? I'd guess it's undefined behaviour. It still seems excessively unfriendly -- have you reported this to MS? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167262&group_id=5470 From noreply at sourceforge.net Mon Nov 28 19:33:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 10:33:12 -0800 Subject: [ python-Bugs-1368481 ] python.dir still refers to python-whatsnew23 Message-ID: Bugs item #1368481, was opened at 2005-11-28 19:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Herzog (bernhard) Assigned to: Nobody/Anonymous (nobody) Summary: python.dir still refers to python-whatsnew23 Initial Comment: In the tarball with the GNU info version of the documentation, the file python.dir still refers to a node python-whatsnew23 which doesn't exist. It should be python-whatsnew24. This bug is also present in SVN in both release24-maint branch and trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368481&group_id=5470 From noreply at sourceforge.net Mon Nov 28 20:10:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 11:10:29 -0800 Subject: [ python-Bugs-1368515 ] threading.Timer: Constructor does not handle args correctly Message-ID: Bugs item #1368515, was opened at 2005-11-28 20:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: dominikush (dominikush) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer: Constructor does not handle args correctly Initial Comment: The constructor of threading.Timer does not correctly handle arguments passed to it, see example given. I noted the bug in Python 2.4.1 and checked it also for Python 2.4.2: >>> def test(*args,**kwds): print "test: args =",args,"and kwds =",kwds ... >>> import threading >>> t = threading.Timer(2,test,"hello") >>> t.start() >>> test: args = ('h', 'e', 'l', 'l', 'o') and kwds = {} Proposed bug fix in threading.Timer.__init__: def __init__(self, interval, function, args=[], kwargs={}): # bug def __init__(self, interval, function, *args, **kwargs): # correction After proposed correction, rerun of test results in: >>> t.start() >>> test: args = ('hallo',) and kwds = {} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470 From noreply at sourceforge.net Tue Nov 29 02:40:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 17:40:09 -0800 Subject: [ python-Bugs-1368768 ] clearing up dictionary keys/set member docs Message-ID: Bugs item #1368768, was opened at 2005-11-28 19:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: clearing up dictionary keys/set member docs Initial Comment: The documentation for dictionaries says "A dictionary's keys are almost arbitrary values. Only values containing lists, dictionaries or other mutable types (that are compared by value rather than by object identity) may not be used as keys." This is wrong. tuples are an immutable type, but not all tuples can be used as keys. The set documentation says "A set object is an unordered collection of immutable values.". This is also wrong - at least for common definitions of immutable. Immutability is a convenient way of dealing with builtin types, but is a red herring. It's whether or not the object has a hash value that matters, and it's the behavior of that hash value (coupled with comparison) that determine whether or not things behave as expected. The __hash__ documentation deals with these issues. I suggest replacing the current descriptions with one that references hashing, and a footnote pointing to the __hash__ docs for details: Any hashable object(1) can be used as a dictionary key/set element. Lists, sets and dicts are not hashable, and can not be used. Tuples can be used if all the things they contain are hashable. Instances of all other built-in types and most user-defined classes are hashable. (1) Objects for which the hash() function returns an appropriate value. See the __hash__ documentation for details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368768&group_id=5470 From noreply at sourceforge.net Tue Nov 29 05:38:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Nov 2005 20:38:37 -0800 Subject: [ python-Bugs-1368827 ] bad external link in xmlrpc lib page Message-ID: Bugs item #1368827, was opened at 2005-11-28 22:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 Please note that this 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: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: bad external link in xmlrpc lib page Initial Comment: This section of the current docs: 11.22 xmlrpclib -- XML-RPC client access http://docs.python.org/lib/module-xmlrpclib.html ... has the following bad link: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html We could still list this useful external link in our docs: http://xmlrpc-c.sourceforge.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 From noreply at sourceforge.net Tue Nov 29 12:11:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 03:11:13 -0800 Subject: [ python-Bugs-1368515 ] threading.Timer: Constructor does not handle args correctly Message-ID: Bugs item #1368515, was opened at 2005-11-28 20:10 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: dominikush (dominikush) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer: Constructor does not handle args correctly Initial Comment: The constructor of threading.Timer does not correctly handle arguments passed to it, see example given. I noted the bug in Python 2.4.1 and checked it also for Python 2.4.2: >>> def test(*args,**kwds): print "test: args =",args,"and kwds =",kwds ... >>> import threading >>> t = threading.Timer(2,test,"hello") >>> t.start() >>> test: args = ('h', 'e', 'l', 'l', 'o') and kwds = {} Proposed bug fix in threading.Timer.__init__: def __init__(self, interval, function, args=[], kwargs={}): # bug def __init__(self, interval, function, *args, **kwargs): # correction After proposed correction, rerun of test results in: >>> t.start() >>> test: args = ('hallo',) and kwds = {} ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:11 Message: Logged In: YES user_id=38376 The implemented behaviour is the documented behaviour (it's the same for both Thread and Timer). You're not supposed to "call" the Thread constructor; you're supposed to pass in the arguments using keyword arguments. See the library reference for details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470 From noreply at sourceforge.net Tue Nov 29 12:11:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 03:11:42 -0800 Subject: [ python-Bugs-1368515 ] threading.Timer: Constructor does not handle args correctly Message-ID: Bugs item #1368515, was opened at 2005-11-28 20:10 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: dominikush (dominikush) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer: Constructor does not handle args correctly Initial Comment: The constructor of threading.Timer does not correctly handle arguments passed to it, see example given. I noted the bug in Python 2.4.1 and checked it also for Python 2.4.2: >>> def test(*args,**kwds): print "test: args =",args,"and kwds =",kwds ... >>> import threading >>> t = threading.Timer(2,test,"hello") >>> t.start() >>> test: args = ('h', 'e', 'l', 'l', 'o') and kwds = {} Proposed bug fix in threading.Timer.__init__: def __init__(self, interval, function, args=[], kwargs={}): # bug def __init__(self, interval, function, *args, **kwargs): # correction After proposed correction, rerun of test results in: >>> t.start() >>> test: args = ('hallo',) and kwds = {} ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:11 Message: Logged In: YES user_id=38376 The implemented behaviour is the documented behaviour (it's the same for both Thread and Timer). You're not supposed to "call" the Thread constructor; you're supposed to pass in the arguments using keyword arguments. See the library reference for details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368515&group_id=5470 From noreply at sourceforge.net Tue Nov 29 12:14:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 03:14:23 -0800 Subject: [ python-Bugs-1368827 ] bad external link in xmlrpc lib page Message-ID: Bugs item #1368827, was opened at 2005-11-29 05:38 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 Please note that this 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: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: bad external link in xmlrpc lib page Initial Comment: This section of the current docs: 11.22 xmlrpclib -- XML-RPC client access http://docs.python.org/lib/module-xmlrpclib.html ... has the following bad link: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html We could still list this useful external link in our docs: http://xmlrpc-c.sourceforge.net ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:14 Message: Logged In: YES user_id=38376 The new permalink for the XML-RPC HOWTO seems to be: http://www.tldp.org/HOWTO/XML-RPC-HOWTO/index.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 From noreply at sourceforge.net Tue Nov 29 12:25:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 03:25:14 -0800 Subject: [ python-Bugs-1368827 ] bad external link in xmlrpc lib page Message-ID: Bugs item #1368827, was opened at 2005-11-29 05:38 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: bad external link in xmlrpc lib page Initial Comment: This section of the current docs: 11.22 xmlrpclib -- XML-RPC client access http://docs.python.org/lib/module-xmlrpclib.html ... has the following bad link: http://xmlrpc-c.sourceforge.net/xmlrpc-howto/xmlrpc-howto.html We could still list this useful external link in our docs: http://xmlrpc-c.sourceforge.net ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:25 Message: Logged In: YES user_id=38376 The HOWTO document includes links to the XMLRPC-C site, as well as to other useful (and working) links. Just fixing the broken URL should be good enough, for now. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-29 12:14 Message: Logged In: YES user_id=38376 The new permalink for the XML-RPC HOWTO seems to be: http://www.tldp.org/HOWTO/XML-RPC-HOWTO/index.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1368827&group_id=5470 From noreply at sourceforge.net Tue Nov 29 13:37:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 04:37:26 -0800 Subject: [ python-Bugs-1369116 ] freeze idle-python2.3 on my debia n sarge Message-ID: Bugs item #1369116, was opened at 2005-11-29 13:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 Please note that this 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.3 Status: Open Resolution: None Priority: 5 Submitted By: Gabriel Santonja (gsantonja) Assigned to: Nobody/Anonymous (nobody) Summary: freeze idle-python2.3 on my debia n sarge Initial Comment: When I press space bar continusly idle-python task have a random freeze 8/10 times before the caracter 300. I must kill the task and restart This arrive frequently during my development. Architecture : idle python 2.3 Debian sarge without modification XFCE 4.0 Nvidia driver hp nx9105 I have try to made again the bug on other architecture but i don't have success on windows XP and debion in virtual pc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1369116&group_id=5470 From noreply at sourceforge.net Wed Nov 30 05:10:44 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Nov 2005 20:10:44 -0800 Subject: [ python-Feature Requests-1367936 ] split() string method has two splitting algorithms Message-ID: Feature Requests item #1367936, was opened at 2005-11-28 00:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 Please note that this 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: crackwitz (crackwitz) Assigned to: Nobody/Anonymous (nobody) Summary: split() string method has two splitting algorithms Initial Comment: The docs of Python 2.4.2 for .split([sep [,maxsplit]]) say: "If sep is not specified or is None, a different splitting algorithm is applied." I would like to see that behavior exposed and consistent, i.e. stripping (new key strip=...?) independent of whether sep is None or not. Making it consistent could break existing code because people already built on split()'s special behavior. You could say strip=None by default and only keep switching if strip==None. I don't like this magic behavior though because there's no reason for it to exist. # this is now (Python v2.4.2) ' foo bar '.split() # => ['foo', 'bar'] ' foo bar '.split(' ') # => ['', 'foo', '', 'bar', ''] # this is how I would like it to be ' foo bar '.split(strip=True) # => ['foo', 'bar'] ' foo bar '.split(strip=False) # => ['', 'foo', '', 'bar', ''] # compatibility preserved (strip=None by default): ' foo bar '.split(strip=None) # => ['foo', 'bar'] ' foo bar '.split(' ', strip=None) # => ['', 'foo', '', 'bar', ''] what do you think? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-11-29 23:10 Message: Logged In: YES user_id=80475 While unfortunate, this function already suffers from excess complexity. Changing the behavior and adding backwards compatability features would make the situation worse. Also, the two different behaviors were not accidental. Someone put them in for a reason. There may be orthogonal use cases. Ideally, that need would have been been through two different functions/methods. But, if you change the behavior, you're likely breaking an entire class of use cases. So, I'm -1 on mucking with this prior to Py3.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470 From noreply at sourceforge.net Wed Nov 30 17:41:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Nov 2005 08:41:19 -0800 Subject: [ python-Bugs-1370197 ] memory leak - ast_error_finish Message-ID: Bugs item #1370197, was opened at 2005-11-30 11:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 Please note that this 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: AST Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak - ast_error_finish Initial Comment: http://svn.python.org/view/python/trunk/Python/ast.c? rev=41486&view=markup function ast_error_finish It first gets the errstr, for a possible early out. If there is an error string, it is increfed, but it is not decrefed on the other early outs. (lineno==-1 and failure to build a tmp. """ Py_INCREF(errstr); lineno = PyInt_AsLong(PyTuple_GetItem(value, 1)); if (lineno == -1) return; Py_DECREF(value); loc = PyErr_ProgramText(filename, lineno); if (!loc) { Py_INCREF(Py_None); loc = Py_None; } tmp = Py_BuildValue("(ziOO)", filename, lineno, Py_None, loc); Py_DECREF(loc); if (!tmp) return; value = Py_BuildValue("(OO)", errstr, tmp); Py_DECREF(errstr); """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470 From noreply at sourceforge.net Wed Nov 30 20:49:02 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Nov 2005 11:49:02 -0800 Subject: [ python-Bugs-1370322 ] Bytecode problems with test_colorsys Message-ID: Bugs item #1370322, was opened at 2005-11-30 20:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Bytecode problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 From noreply at sourceforge.net Wed Nov 30 22:18:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Nov 2005 13:18:48 -0800 Subject: [ python-Bugs-1370380 ] asynchat.async_chat.push() function doesnt say when failed Message-ID: Bugs item #1370380, was opened at 2005-11-30 22:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jan David Mol (jjdmol) Assigned to: Nobody/Anonymous (nobody) Summary: asynchat.async_chat.push() function doesnt say when failed Initial Comment: suppose you have a socket handled by your asynchat.async_chat class and want to send a message (call push()). push() calls initiate_send(), which can call handle_error() if an error occurs. however, once handle_error() returns, the control is passed back to push(), which has no return value thus cannot signal the success or failure to the code that did the push(). i.e. if we have code like foo() s.push(data) bar() the following is executed in case of an error: foo() s.push(data) s.handle_error() bar() this created an obscure bug, as the bar() assumed the send() always succeeds, and also cannot check directly by the result of push() if it did. this creates the false illusion push() can never fail. to avoid this, handle_error() can set a flag, which can be checked after the push(). however, this is an ugly hack of course. PS: send() can easily fail. suppose we're reading from 2 sockets: A and B, and send messages to both when data is read from either one. if B gets disconnected and A has data ready, both will be in the set of readible sockets returned by select(). if A's data is handled before B's, and A sends a message to B, this will cause the send to fail as B is disconnected. your app wont know B failed, because this is processed after the data from A is processed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370380&group_id=5470