From noreply@sourceforge.net Fri Aug 1 04:41:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 20:41:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-685465 ] python-mode loops on if/else Message-ID: Bugs item #685465, was opened at 2003-02-12 12:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685465&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode loops on if/else Initial Comment: Here's how to reproduce. Create a .py file in XEmacs containing this text: x = (if 1: 2 ____else: 3) (except that the ____ really means four spaces). Now position your cursor somewhere inside those 4 spaces, and hit TAB. XEmacs freezes until you hit ^G. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 22:41 Message: Logged In: YES user_id=44345 The code gets into an infloop in py-outdent-p. The loop looks odd to me: (while (or (looking-at py-blank-or-comment-re) (bobp)) (backward-to-indentation 1)) If you were at (bobp), why would you want to try to move back a line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685465&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:01:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:01:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-606254 ] py-electric-colon & delete-selection-mod Message-ID: Bugs item #606254, was opened at 2002-09-08 03:39 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Skip Montanaro (montanaro) Summary: py-electric-colon & delete-selection-mod Initial Comment: python-elisp: py-electric-colon doesn't honour delete-selection mode [forwarded from http://bugs.debian.org/158811] With emacs 21 in delete-selection mode, typing a character when the region is active is supposed to replace the contents of the region. In python-mode, this doesn't work if the colon character is typed. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:01 Message: Logged In: YES user_id=44345 fixed ini python-mode.el 4.37 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606254&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:04:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:04:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-606251 ] elisp: doesn't recognize comment-syntax Message-ID: Bugs item #606251, was opened at 2002-09-08 03:24 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: elisp: doesn't recognize comment-syntax Initial Comment: [forwarded from http://bugs.debian.org/159630] It would be awfully nice if python-mode.el knew about python comment syntax and told emacs about it, so that the M-q fill-paragraph command that formats comment blocks so nicely in C and Perl modes would do the right thing. As it stands, M-q in the middle of the comment block on something like this:.. def func(): blah = 2 # this is a comment # this is also a comment foo = 3 jams the entire function into one line, statements and comments and all. I'd really like it to identify the comments, set the region around them, do a normal paragraph-fill (with the fill-prefix set to the existing indentation), then restore the region. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:04 Message: Logged In: YES user_id=44345 This was fixed in a separate patch (pre-2.3) awhile ago. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-03-04 16:42 Message: Logged In: YES user_id=60903 Attached is a patch sent to the Debian BTS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606251&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:10:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:10:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-606250 ] python-mode kills arrow in gdb (gud.el) Message-ID: Bugs item #606250, was opened at 2002-09-08 03:21 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode kills arrow in gdb (gud.el) Initial Comment: [ forwarded from http://bugs.debian.org/159628 ] missing proper category ... Once python-mode.el has been loaded, all GDB buffers stop showing the little arrow that lives in the "fringe" on the left side of an emacs21 frame. To be specific, the arrow appears and then disappears right away, each time a 'step' or 'next' command is run. I traced the problem down to the unconditional hooking of 'comint-output-filter-functions, python-mode.el line 3472 to be exact: (add-hook 'comint-output-filter-functions 'py-pdbtrack-track-stack-file) I haven't tested it fully, but I've found that if I take this line out, GDB can show its arrow once more. There is code in python-mode.el to insert this hook in a buffer-local fashion only in the '*Python*' buffer.. maybe that should be reviewed and used instead of this global hook? (took forever to figure out it was python-mode causing the problem..) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:10 Message: Logged In: YES user_id=44345 Matthias, I'm closing this. It seems to work for me. I entered gdb on the python executable, set a break in main(), got there, visited a Python file and manually reloaded python-mode, then returned to the gdb buffer. The => marker was visible and didn't disappear with a series of next and step commands. The only differences are I'm using XEmacs 21.5.9 and python-mode 4.37. If you can verify that the problem still exists with 4.37 under Emacs 21 I'll dig further. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-01 20:51 Message: Logged In: YES user_id=33168 Barry, I thought you worked on this? Perhaps this is a duplicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=606250&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:27:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:27:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-605818 ] python-mode.el replaces function on f1 Message-ID: Bugs item #605818, was opened at 2002-09-06 15:45 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 Category: Demos and Tools Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter Toneby (toneby) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode.el replaces function on f1 Initial Comment: I've customized my global-keymap to save on F1, but python-mode overrides this and opens help. You should check if F1 is bound to something other than default, if it is you shouldn't touch it. The other keys are OK, since they start with C-c which is the keycombo modespecific keys are "supposed" to use. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:27 Message: Logged In: YES user_id=44345 Deleted the F1 key binding in 4.38 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=605818&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:36:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:36:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-594833 ] python-mode.el disables raw_input() Message-ID: Bugs item #594833, was opened at 2002-08-13 19:30 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594833&group_id=5470 Category: Demos and Tools Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Kow Kuroda (kowk) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode.el disables raw_input() Initial Comment: Hi, I'm not sure if this is a bug. I just wanted to report a problem with my emacs environment using python-mode. With the current version of python-mode.el with Python 2.1, 2.2, 2.2.1, I always get EOFError: EOF when reading a line at the line I call raw_input() function. How to get this work in emacs? By the way, the same code doesn't raise this error with vim. Thanks in advance. Kow ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 23:36 Message: Logged In: YES user_id=44345 I think this is something we can't do anything about. It's just a limitation of the underlying Emacs functions used to run external programs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=594833&group_id=5470 From noreply@sourceforge.net Fri Aug 1 05:37:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 21:37:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-781285 ] 2.3 web page link to 'New style classes' changes to 2.2.2 Message-ID: Bugs item #781285, was opened at 2003-08-01 04: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=781285&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 web page link to 'New style classes' changes to 2.2.2 Initial Comment: If you click the 'New style classes' link in the 2.3 web pages, you will be moved into the 2.2.2 web pages i.e. if you then click 'Index' you will go to the 2.2 home page rather than the 2.3 home page. Either this page should be duplicated for 2.3, or there should be an alias for it (not a redirection) in the 2.3 tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781285&group_id=5470 From noreply@sourceforge.net Fri Aug 1 07:20:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 23:20:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-777884 ] minidom.py -- TypeError: object doesn't support slice assig Message-ID: Bugs item #777884, was opened at 2003-07-25 19:22 Message generated for change (Comment added) made by leshmark You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Lesh (leshmark) Assigned to: Nobody/Anonymous (nobody) 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: Mark Lesh (leshmark) Date: 2003-08-01 01: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 06: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@sourceforge.net Fri Aug 1 08:00:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:00:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-777884 ] minidom.py -- TypeError: object doesn't support slice assig Message-ID: Bugs item #777884, was opened at 2003-07-26 02:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Lesh (leshmark) Assigned to: Nobody/Anonymous (nobody) 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: Martin v. Löwis (loewis) Date: 2003-08-01 09: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 08: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 13: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@sourceforge.net Fri Aug 1 08:03:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:03:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-781065 ] test_normalization fails Message-ID: Bugs item #781065, was opened at 2003-07-31 21:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: The LinuxDuck (thelinuxduck) >Assigned to: Martin v. Löwis (loewis) Summary: test_normalization fails Initial Comment: I d/l the NormalizationTest.txt from unicode.org, as suggested, then run the test as: ----------------------------------- /source/Python-build> ./python ../Python-2.3/Lib/test/regrtest.py -g test_normalization.py test_normalization test test_normalization failed -- 03F9;03F9;03F9;03A3;03A3; 1 test failed: test_normalization ----------------------------------- If I comment out that line in the file, it fails further down: ----------------------------------- test_normalization test test_normalization failed -- 1D2C;1D2C;1D2C;0041;0041; 1 test failed: test_normalization ----------------------------------- GNU C Library stable release version 2.1.3, by Roland McGrath et al. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.14 system on 2000-03-20. Available extensions: GNU libio by Per Bothner linuxthreads-0.8 by Xavier Leroy BIND-4.9.7-REL libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Linux www 2.2.16 #22 Fri Jun 16 16:51:24 PDT 2000 i586 unknown unknown GNU/Linux This is a slack 8.1 box, running gcc 3.0.2. Python version 2.3 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:03 Message: Logged In: YES user_id=21627 Can you tell what version of NormalizationTest.txt you use? Python's module is for Unicode 3.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:04:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:04:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:10:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:10:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-780300 ] pyexpat LexicalHandler swaps system_id and public_id Message-ID: Bugs item #780300, was opened at 2003-07-30 17:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780300&group_id=5470 Category: XML Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Holger Floerke (floerke) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat LexicalHandler swaps system_id and public_id Initial Comment: XML: test DTD: you can imagine ... ch = MyHandler() parser = make_parser() parser.setProperty(handler.property_lexical_handler, ch) ... class MyHandler(XMLGenerator): ... def startDTD(self, name, public_id, system_id): self._out.write(public_id) ... -> "a.dtd" (but a.dtd should be the system_id) and the system_id in method startDTD is None a glimpse into pyexpat.c from python 2.2.3 ... VOID_HANDLER(StartDoctypeDecl, ... STRING_CONV_FUNC,doctypeName, STRING_CONV_FUNC,sysid, STRING_CONV_FUNC,pubid, has_internal_subset)) ... maybe sysid and pubid is swapped. I'm not a python specialist and maybe this bug is fixed or is not a bug. Please let me know... HolgeR ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:10 Message: Logged In: YES user_id=21627 This is indeed a bug in Python 2.3, which has been fixed in PyXML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780300&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:10:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:10:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-780300 ] pyexpat LexicalHandler swaps system_id and public_id Message-ID: Bugs item #780300, was opened at 2003-07-30 17:35 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780300&group_id=5470 Category: XML Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Holger Floerke (floerke) >Assigned to: Martin v. Löwis (loewis) Summary: pyexpat LexicalHandler swaps system_id and public_id Initial Comment: XML: test DTD: you can imagine ... ch = MyHandler() parser = make_parser() parser.setProperty(handler.property_lexical_handler, ch) ... class MyHandler(XMLGenerator): ... def startDTD(self, name, public_id, system_id): self._out.write(public_id) ... -> "a.dtd" (but a.dtd should be the system_id) and the system_id in method startDTD is None a glimpse into pyexpat.c from python 2.2.3 ... VOID_HANDLER(StartDoctypeDecl, ... STRING_CONV_FUNC,doctypeName, STRING_CONV_FUNC,sysid, STRING_CONV_FUNC,pubid, has_internal_subset)) ... maybe sysid and pubid is swapped. I'm not a python specialist and maybe this bug is fixed or is not a bug. Please let me know... HolgeR ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:10 Message: Logged In: YES user_id=21627 This is indeed a bug in Python 2.3, which has been fixed in PyXML. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780300&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:14:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:14:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 19:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:34:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:34:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 00:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 11:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 06:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include #include . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Fri Aug 1 08:35:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 00:35:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 18:16 Message generated for change (Comment added) made by ishimoto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 16:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 16:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Fri Aug 1 09:22:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 01:22:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Fri Aug 1 10:40:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 02:40:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-780461 ] MacOS.Error for platform.mac_ver under OS X Message-ID: Bugs item #780461, was opened at 2003-07-30 22:20 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: M.-A. Lemburg (lemburg) Summary: MacOS.Error for platform.mac_ver under OS X Initial Comment: >>> platform.mac_ver() Traceback (most recent call last): File "", line 1, in ? File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 563, in mac_ver sysv,sysu,sysa = _mac_ver_lookup(('sysv','sysu','sysa')) File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 532, in _mac_ver_lookup append(gestalt(selector)) MacOS.Error: (-5551, 'undefined selector was passed to Gestalt') This is on an OS X 10.2.6 system. Any chance this is because I compiled with --enable- unicode=ucs4 ? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:40 Message: Logged In: YES user_id=45365 The problem is not with your ucs4 build, this call always fails under MacOSX. The problem is that the 'sysu' gestalt selector isn't available under OSX. The code in _mac_ver_lookup does a try/except on RuntimeError around the call to gestalt, but I don't remember MacOS.Error ever being a subclass of RuntimeError. Currently MacOS.Error is in a class by itself, it should probably be an OSError subclass, but that still won't fix this. I suggest doing the try/except on MacOS.Error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 From noreply@sourceforge.net Fri Aug 1 10:45:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 02:45:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Fri Aug 1 12:21:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 04:21:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 19:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 17:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 11:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Fri Aug 1 12:40:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 04:40:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-780461 ] MacOS.Error for platform.mac_ver under OS X Message-ID: Bugs item #780461, was opened at 2003-07-30 22:20 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: M.-A. Lemburg (lemburg) Summary: MacOS.Error for platform.mac_ver under OS X Initial Comment: >>> platform.mac_ver() Traceback (most recent call last): File "", line 1, in ? File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 563, in mac_ver sysv,sysu,sysa = _mac_ver_lookup(('sysv','sysu','sysa')) File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 532, in _mac_ver_lookup append(gestalt(selector)) MacOS.Error: (-5551, 'undefined selector was passed to Gestalt') This is on an OS X 10.2.6 system. Any chance this is because I compiled with --enable- unicode=ucs4 ? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-01 13:40 Message: Logged In: YES user_id=38388 Catching MacOS.Error doesn't help much: if 'sysu' is not available on MacOSX, then I need the system information from somewhere else. Any hints ? (don't have a MacOSX to test on, so it's up to you to provide the necessary information or patch :-) Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:40 Message: Logged In: YES user_id=45365 The problem is not with your ucs4 build, this call always fails under MacOSX. The problem is that the 'sysu' gestalt selector isn't available under OSX. The code in _mac_ver_lookup does a try/except on RuntimeError around the call to gestalt, but I don't remember MacOS.Error ever being a subclass of RuntimeError. Currently MacOS.Error is in a class by itself, it should probably be an OSError subclass, but that still won't fix this. I suggest doing the try/except on MacOS.Error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 From noreply@sourceforge.net Fri Aug 1 13:00:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 05:00:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-781433 ] MacOS module doesn't compile on 10.1 Message-ID: Bugs item #781433, was opened at 2003-08-01 14:00 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=781433&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS module doesn't compile on 10.1 Initial Comment: The MacOS module (Mac/Modules/macosmodule.c) doesn't compile on OSX 10.1. A patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781433&group_id=5470 From noreply@sourceforge.net Fri Aug 1 13:09:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 05:09:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-779506 ] strftime returns empty strings with %Z when giving instant Message-ID: Bugs item #779506, was opened at 2003-07-29 12:59 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 Category: Macintosh >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Jack Jansen (jackjansen) Summary: strftime returns empty strings with %Z when giving instant Initial Comment: I begin with %Z, no instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z') '2003-07-29 03.49.17 PDT' now I add the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime()) '' variation on the same: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime(time.time())) '' and now I drop the %Z but keep the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S', time.localtime(time.time())) '2003-07-29 03.51.42' my build info: >>> import sys; sys.version '2.3c2 (#1, Jul 28 2003, 13:47:18) \n[GCC 2.95.2 19991024 (release)]' this is on Darwin 5.5 (Mac OS X 10.1.5) using a framework installation. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=45365 On 10.1, any format with "%Z" in it will result in an empty string return. Googling on it revealed that the Perl folks also ran into it last year, and submitted a bug report to Apple. Apparently this caused the bug to be fixed for 10.2. Closing this as "won't fix". ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 14:21 Message: Logged In: YES user_id=45365 It works for me, on MacOSX 10.2.6: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime(time.time())) '2003-07-29 02.22.10 CEST' I haven't tested anything on 10.1 for a long time, I'll do so later this week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-29 13:42 Message: Logged In: YES user_id=33168 These work for me on Linux (rh9). My guess is that this is a platform specific problem. Jack, can you test/confirm this behaviour? boredzo how did you find this problem? Did a test fail or did you just discover it? Perhaps we should add a test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 From noreply@sourceforge.net Fri Aug 1 13:10:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 05:10:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) >Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 08:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 03:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 14:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 09:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 20:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include #include . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 10:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-22 02:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 19:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 13:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 14:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 08:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Fri Aug 1 13:40:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 05:40:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-781445 ] Applets don't work on 10.1 Message-ID: Bugs item #781445, was opened at 2003-08-01 14: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=781445&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Applets don't work on 10.1 Initial Comment: MacPython works fine on Mac OS X 10.1, except for one showstopper bug. I am filing this bug report so that we have all relevant information together in case someone feels like fixing it. The problem is that our applets use a python script as their executable, with a #! first line pointing to Python. This works in 10.1 when run from the command line, but not when double-clicked from the finder. A discussion on this can be found in the pythonmac-sig archives for Feb-2003, start with message . With no applet support we have no IDE and no Package Manager, so there is little point in doing a binary installer unless someone fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781445&group_id=5470 From noreply@sourceforge.net Fri Aug 1 15:11:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 07:11:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 15:18:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 07:18:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 15:27:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 07:27:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by dmgrime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 15:52:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 07:52:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 15:53:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 07:53:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) >Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 16:42:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 08:42:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 18:04 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 10:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 06:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 13:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 05:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Fri Aug 1 17:20:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 09:20:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 16:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 19:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 17:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 11:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Fri Aug 1 17:21:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 09:21:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) >Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 16:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 19:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 17:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 11:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Fri Aug 1 17:34:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 09:34:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-781592 ] OverflowError exception in garbage collector Message-ID: Bugs item #781592, was opened at 2003-08-02 00: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=781592&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Kwan (dipsypo82) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError exception in garbage collector Initial Comment: It is known that Python 2.3 will issue warnings for hex/oct literals > sys.maxint. According to documentation, one get around is to append "L" to the literal to make it explicitly long. For example, instead of 0x80ff3366, use 0x80ff3366L. However, the long value will cause Python 2.3 terminates with the following fatal error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection abnormal program termination The Python code under testing is passing the above constant to a C routine as an argument. The C routine calls: //convert the given argument to Long in case //it is not already Long PyObject *longObj = PyNumber_Long(argument); //get the value of the Python Long variable long ret = PyLong_AsLong(longObj); The error occur shortly after the above code (during subsequent garbage collection?). It does not occur if I used 0x80ff3366 instead of 0x80ff3366L. Also, it does not occur if the second line of C code is commented out. The error also does not occur in Python 1.5.2 up to Python 2.2, no matter I use 0x80ff3366 or 0x80ff3366L. The code is running on Windows 2000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 From noreply@sourceforge.net Fri Aug 1 17:58:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 09:58:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-781592 ] OverflowError exception in garbage collector Message-ID: Bugs item #781592, was opened at 2003-08-01 12:34 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Peter Kwan (dipsypo82) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError exception in garbage collector Initial Comment: It is known that Python 2.3 will issue warnings for hex/oct literals > sys.maxint. According to documentation, one get around is to append "L" to the literal to make it explicitly long. For example, instead of 0x80ff3366, use 0x80ff3366L. However, the long value will cause Python 2.3 terminates with the following fatal error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection abnormal program termination The Python code under testing is passing the above constant to a C routine as an argument. The C routine calls: //convert the given argument to Long in case //it is not already Long PyObject *longObj = PyNumber_Long(argument); //get the value of the Python Long variable long ret = PyLong_AsLong(longObj); The error occur shortly after the above code (during subsequent garbage collection?). It does not occur if I used 0x80ff3366 instead of 0x80ff3366L. Also, it does not occur if the second line of C code is commented out. The error also does not occur in Python 1.5.2 up to Python 2.2, no matter I use 0x80ff3366 or 0x80ff3366L. The code is running on Windows 2000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 From noreply@sourceforge.net Fri Aug 1 18:04:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 10:04:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-781614 ] Windows _bsddb link warnings Message-ID: Bugs item #781614, was opened at 2003-08-01 10:04 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=781614&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Tim Peters (tim_one) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 From noreply@sourceforge.net Fri Aug 1 18:12:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 10:12:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-781592 ] OverflowError exception in garbage collector Message-ID: Bugs item #781592, was opened at 2003-08-01 16:34 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Peter Kwan (dipsypo82) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError exception in garbage collector Initial Comment: It is known that Python 2.3 will issue warnings for hex/oct literals > sys.maxint. According to documentation, one get around is to append "L" to the literal to make it explicitly long. For example, instead of 0x80ff3366, use 0x80ff3366L. However, the long value will cause Python 2.3 terminates with the following fatal error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection abnormal program termination The Python code under testing is passing the above constant to a C routine as an argument. The C routine calls: //convert the given argument to Long in case //it is not already Long PyObject *longObj = PyNumber_Long(argument); //get the value of the Python Long variable long ret = PyLong_AsLong(longObj); The error occur shortly after the above code (during subsequent garbage collection?). It does not occur if I used 0x80ff3366 instead of 0x80ff3366L. Also, it does not occur if the second line of C code is commented out. The error also does not occur in Python 1.5.2 up to Python 2.2, no matter I use 0x80ff3366 or 0x80ff3366L. The code is running on Windows 2000. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-08-01 17:12 Message: Logged In: YES user_id=35752 It sounds as though you are not checking return values. Both PyNumber_Long() and PyLong_AsLong() can return an error. If your code does not check for the error then it will be detected by some later code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 From noreply@sourceforge.net Fri Aug 1 19:30:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 11:30:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-781592 ] OverflowError exception in garbage collector Message-ID: Bugs item #781592, was opened at 2003-08-02 00:34 Message generated for change (Comment added) made by dipsypo82 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Peter Kwan (dipsypo82) Assigned to: Nobody/Anonymous (nobody) Summary: OverflowError exception in garbage collector Initial Comment: It is known that Python 2.3 will issue warnings for hex/oct literals > sys.maxint. According to documentation, one get around is to append "L" to the literal to make it explicitly long. For example, instead of 0x80ff3366, use 0x80ff3366L. However, the long value will cause Python 2.3 terminates with the following fatal error: Exception exceptions.OverflowError: 'long int too large to convert to int' in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection abnormal program termination The Python code under testing is passing the above constant to a C routine as an argument. The C routine calls: //convert the given argument to Long in case //it is not already Long PyObject *longObj = PyNumber_Long(argument); //get the value of the Python Long variable long ret = PyLong_AsLong(longObj); The error occur shortly after the above code (during subsequent garbage collection?). It does not occur if I used 0x80ff3366 instead of 0x80ff3366L. Also, it does not occur if the second line of C code is commented out. The error also does not occur in Python 1.5.2 up to Python 2.2, no matter I use 0x80ff3366 or 0x80ff3366L. The code is running on Windows 2000. ---------------------------------------------------------------------- >Comment By: Peter Kwan (dipsypo82) Date: 2003-08-02 02:30 Message: Logged In: YES user_id=835585 Thanks a lot for your help. I think you are right. Actually, I do check for error return for the PyNumber_Long call, but I just omit them in the bug report for simplicity. I do not check for error for PyLong_AsLong because this API cannot return error when I wrote this code in the past (at the time of Python 1.5.x). I checked the latest Python documentation and found that it now can return error. Apparently, in Python 2.3, I need to use the new Python 2.3 API PyLong_AsUnsignedLongMask instead, which is equivalent to the old PyLong_AsUnsignedLong. So I think we can declare this bug closed - reason: this is not a bug. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-08-02 01:12 Message: Logged In: YES user_id=35752 It sounds as though you are not checking return values. Both PyNumber_Long() and PyLong_AsLong() can return an error. If your code does not check for the error then it will be detected by some later code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781592&group_id=5470 From noreply@sourceforge.net Fri Aug 1 19:58:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 11:58:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-781065 ] test_normalization fails Message-ID: Bugs item #781065, was opened at 2003-07-31 14:43 Message generated for change (Comment added) made by thelinuxduck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: The LinuxDuck (thelinuxduck) Assigned to: Martin v. Löwis (loewis) Summary: test_normalization fails Initial Comment: I d/l the NormalizationTest.txt from unicode.org, as suggested, then run the test as: ----------------------------------- /source/Python-build> ./python ../Python-2.3/Lib/test/regrtest.py -g test_normalization.py test_normalization test test_normalization failed -- 03F9;03F9;03F9;03A3;03A3; 1 test failed: test_normalization ----------------------------------- If I comment out that line in the file, it fails further down: ----------------------------------- test_normalization test test_normalization failed -- 1D2C;1D2C;1D2C;0041;0041; 1 test failed: test_normalization ----------------------------------- GNU C Library stable release version 2.1.3, by Roland McGrath et al. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.14 system on 2000-03-20. Available extensions: GNU libio by Per Bothner linuxthreads-0.8 by Xavier Leroy BIND-4.9.7-REL libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Linux www 2.2.16 #22 Fri Jun 16 16:51:24 PDT 2000 i586 unknown unknown GNU/Linux This is a slack 8.1 box, running gcc 3.0.2. Python version 2.3 ---------------------------------------------------------------------- >Comment By: The LinuxDuck (thelinuxduck) Date: 2003-08-01 13:58 Message: Logged In: YES user_id=490655 Doh! Guess I should have known that there would be different versions. Looks like I've got version 4.00. For anyone else having this issue, the corrent d/l location of the NormalizationTest.txt version 3.2 is http://www.unicode.org/Public/3.2-Update/NormalizationTest- 3.2.0.txt. The link provided in the tests will direct you to 4.0. Note: I have not yet recompiled with 3.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:03 Message: Logged In: YES user_id=21627 Can you tell what version of NormalizationTest.txt you use? Python's module is for Unicode 3.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 From noreply@sourceforge.net Fri Aug 1 20:09:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 12:09:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 19:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 21:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 16:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 16:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 16:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 16:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 20:31:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 12:31:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by dmgrime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 14:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 20:50:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 12:50:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-781614 ] Windows _bsddb link warnings Message-ID: Bugs item #781614, was opened at 2003-08-01 19:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Tim Peters (tim_one) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 21:50 Message: Logged In: YES user_id=21627 Can you propose a specific patch? Also, it would be preferable if changing the source code of the Sleepycat distribution would not be necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 From noreply@sourceforge.net Fri Aug 1 21:40:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 13:40:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-781722 ] py-2.3 socket.inet_pton() segfault. Message-ID: Bugs item #781722, was opened at 2003-08-01 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781722&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Wojtek Walczak (gminick) Assigned to: Nobody/Anonymous (nobody) Summary: py-2.3 socket.inet_pton() segfault. Initial Comment: It works (read: segfaults) only when compiled without IPv6 support. Code to exploit this bug: import socket socket.inet_pton(socket.AF_INET6, '5aef:2b::8') It segfaults because of that code from Modules/socketmodule.c: --- #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; #else char packed[sizeof(struct in_addr)]; #endif if (!PyArg_ParseTuple(args, "is:inet_pton", &af, &ip)) { return NULL; } retval = inet_pton(af, ip, packed); --- Because IPv6 is disabled packet is defined in that way: char packed[sizeof(struct in_addr)]; but we're still able to ask inet_pton() to convert some IPv6 address because socket.AF_INET6 constant is available, but packet buffer is too small to hold IPv6 data. A simple patch: #--------------------------------- --- ../../orig/Python-2.3/Modules/socketmodule.c Thu Jul 17 18:58:48 2003 +++ socketmodule.c Fri Aug 1 22:13:30 2003 @@ -2962,6 +2962,14 @@ return NULL; } +#ifndef ENABLE_IPV6 + if(af == AF_INET6) { + PyErr_SetString(socket_error, + "can't use AF_INET6, IPv6 is disabled"); + return NULL; + } +#endif + retval = inet_pton(af, ip, packed); if (retval < 0) { PyErr_SetFromErrno(socket_error); #---------------------------------- Sorry, if you know about this one already. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781722&group_id=5470 From noreply@sourceforge.net Fri Aug 1 21:50:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 13:50:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-781722 ] py-2.3 socket.inet_pton() segfault. Message-ID: Bugs item #781722, was opened at 2003-08-01 16:40 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781722&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Wojtek Walczak (gminick) Assigned to: Nobody/Anonymous (nobody) Summary: py-2.3 socket.inet_pton() segfault. Initial Comment: It works (read: segfaults) only when compiled without IPv6 support. Code to exploit this bug: import socket socket.inet_pton(socket.AF_INET6, '5aef:2b::8') It segfaults because of that code from Modules/socketmodule.c: --- #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; #else char packed[sizeof(struct in_addr)]; #endif if (!PyArg_ParseTuple(args, "is:inet_pton", &af, &ip)) { return NULL; } retval = inet_pton(af, ip, packed); --- Because IPv6 is disabled packet is defined in that way: char packed[sizeof(struct in_addr)]; but we're still able to ask inet_pton() to convert some IPv6 address because socket.AF_INET6 constant is available, but packet buffer is too small to hold IPv6 data. A simple patch: #--------------------------------- --- ../../orig/Python-2.3/Modules/socketmodule.c Thu Jul 17 18:58:48 2003 +++ socketmodule.c Fri Aug 1 22:13:30 2003 @@ -2962,6 +2962,14 @@ return NULL; } +#ifndef ENABLE_IPV6 + if(af == AF_INET6) { + PyErr_SetString(socket_error, + "can't use AF_INET6, IPv6 is disabled"); + return NULL; + } +#endif + retval = inet_pton(af, ip, packed); if (retval < 0) { PyErr_SetFromErrno(socket_error); #---------------------------------- Sorry, if you know about this one already. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781722&group_id=5470 From noreply@sourceforge.net Fri Aug 1 21:52:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 13:52:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 19:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 22:52 Message: Logged In: YES user_id=21627 I don't know of any other approach to solve the problem. Also notice that the wrapper object has existed for a long time already, on some systems. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 21:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 21:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 16:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 16:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 16:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 16:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Fri Aug 1 22:43:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 14:43:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-781770 ] Pynche crash on Win32 Message-ID: Bugs item #781770, was opened at 2003-08-01 23: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=781770&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) Assigned to: Nobody/Anonymous (nobody) Summary: Pynche crash on Win32 Initial Comment: WinXP, Python 2.3 standard installation C:\Python23\Tools\pynche>pynche.py Traceback (most recent call last): File "C:\Python23\Tools\pynche\pynche.py", line 7, in ? Main.main() File "c:\Python23\Tools\pynche\Main.py", line 220, in main dbfile=dbfile) File "c:\Python23\Tools\pynche\Main.py", line 130, in build dbfile = s.optiondb()['DBFILE'] KeyError: 'DBFILE' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781770&group_id=5470 From noreply@sourceforge.net Fri Aug 1 22:45:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 14:45:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-781770 ] Pynche crash on Win32 Message-ID: Bugs item #781770, was opened at 2003-08-01 23:43 Message generated for change (Settings changed) made by adsr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781770&group_id=5470 Category: Demos and Tools Group: None Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) Assigned to: Nobody/Anonymous (nobody) Summary: Pynche crash on Win32 Initial Comment: WinXP, Python 2.3 standard installation C:\Python23\Tools\pynche>pynche.py Traceback (most recent call last): File "C:\Python23\Tools\pynche\pynche.py", line 7, in ? Main.main() File "c:\Python23\Tools\pynche\Main.py", line 220, in main dbfile=dbfile) File "c:\Python23\Tools\pynche\Main.py", line 130, in build dbfile = s.optiondb()['DBFILE'] KeyError: 'DBFILE' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781770&group_id=5470 From noreply@sourceforge.net Fri Aug 1 23:35:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 01 Aug 2003 15:35:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-781770 ] Pynche crash on Win32 Message-ID: Bugs item #781770, was opened at 2003-08-01 17:43 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781770&group_id=5470 Category: Demos and Tools Group: None >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Artur de Sousa Rocha (adsr) Assigned to: Nobody/Anonymous (nobody) Summary: Pynche crash on Win32 Initial Comment: WinXP, Python 2.3 standard installation C:\Python23\Tools\pynche>pynche.py Traceback (most recent call last): File "C:\Python23\Tools\pynche\pynche.py", line 7, in ? Main.main() File "c:\Python23\Tools\pynche\Main.py", line 220, in main dbfile=dbfile) File "c:\Python23\Tools\pynche\Main.py", line 130, in build dbfile = s.optiondb()['DBFILE'] KeyError: 'DBFILE' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781770&group_id=5470 From noreply@sourceforge.net Sat Aug 2 09:01:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 01:01:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-781883 ] Listbox itemconfigure leaks memory Message-ID: Bugs item #781883, was opened at 2003-08-02 01:01 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=781883&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Angelo Bonet (abonet) Assigned to: Nobody/Anonymous (nobody) Summary: Listbox itemconfigure leaks memory Initial Comment: Calling itemconfigure on Tkinter.Listbox to change item colors seems to leak memory without bounds. I've seen this in Python 2.2 and 2.3 on SunOS, Tru64, and Linux. Here's a small script that demostrates it: import Tkinter as Tk Lb = None def update_lb (): global Lb Lb.delete(0, Tk.END) for ii in range(100): Lb.insert(Tk.END, 'Item %d' % ii) Lb.itemconfigure(ii, bg='red') Lb.after(10, update_lb) root = Tk.Tk() Lb = Tk.Listbox(root) Lb.pack() Lb.after(1000, update_lb) root.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 From noreply@sourceforge.net Sat Aug 2 09:06:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 01:06:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-781883 ] Listbox itemconfigure leaks memory Message-ID: Bugs item #781883, was opened at 2003-08-02 01:01 Message generated for change (Comment added) made by abonet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Angelo Bonet (abonet) Assigned to: Nobody/Anonymous (nobody) Summary: Listbox itemconfigure leaks memory Initial Comment: Calling itemconfigure on Tkinter.Listbox to change item colors seems to leak memory without bounds. I've seen this in Python 2.2 and 2.3 on SunOS, Tru64, and Linux. Here's a small script that demostrates it: import Tkinter as Tk Lb = None def update_lb (): global Lb Lb.delete(0, Tk.END) for ii in range(100): Lb.insert(Tk.END, 'Item %d' % ii) Lb.itemconfigure(ii, bg='red') Lb.after(10, update_lb) root = Tk.Tk() Lb = Tk.Listbox(root) Lb.pack() Lb.after(1000, update_lb) root.mainloop() ---------------------------------------------------------------------- >Comment By: Angelo Bonet (abonet) Date: 2003-08-02 01:06 Message: Logged In: YES user_id=716439 Sorry, but indentation got lost on script sample. Look at attached file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 From noreply@sourceforge.net Sat Aug 2 09:51:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 01:51:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 08:51 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=781891&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Patrick Useldinger (uselpa) Assigned to: Nobody/Anonymous (nobody) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply@sourceforge.net Sat Aug 2 09:53:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 01:53:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1,200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 07:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: Malte John (drmalte) >Assigned to: Brett Cannon (bcannon) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 03:53 Message: Logged In: YES user_id=80475 It would be interesting for you to pull down the CVS version from two weeks ago and re-run your timings. The caching code was removed at the end because it was a temporary suspect on a bug-hunt just days before the release. Note, the whole purpose of the pure python version was to avoid the non-portable differences between strptime() implementations on various target systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply@sourceforge.net Sat Aug 2 09:58:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 01:58:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-780407 ] cast from pointer to integer of different size Message-ID: Bugs item #780407, was opened at 2003-07-30 13:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780407&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Guido van Rossum (gvanrossum) Summary: cast from pointer to integer of different size Initial Comment: this warning (gcc-3.2 or gcc-3.3) was introduced betwen 20030321 and 20030505, when compiling on 64bit targets gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Include -DPy_BUILD_CORE -o Parser/grammar.o ../Parser/grammar.c ../Parser/grammar.c: In function `_Py_addlabel': ../Parser/grammar.c:107: warning: cast from pointer to integer of different size printf("Label @ %08x, %d: %s\n", (unsigned)ll, ... this should be casted to an unsigned long, and %lx format. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 03:58 Message: Logged In: YES user_id=80475 Guido, this was your code addition in April 2003. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780407&group_id=5470 From noreply@sourceforge.net Sat Aug 2 10:01:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 02:01:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-781883 ] Listbox itemconfigure leaks memory Message-ID: Bugs item #781883, was opened at 2003-08-02 03:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Angelo Bonet (abonet) Assigned to: Nobody/Anonymous (nobody) Summary: Listbox itemconfigure leaks memory Initial Comment: Calling itemconfigure on Tkinter.Listbox to change item colors seems to leak memory without bounds. I've seen this in Python 2.2 and 2.3 on SunOS, Tru64, and Linux. Here's a small script that demostrates it: import Tkinter as Tk Lb = None def update_lb (): global Lb Lb.delete(0, Tk.END) for ii in range(100): Lb.insert(Tk.END, 'Item %d' % ii) Lb.itemconfigure(ii, bg='red') Lb.after(10, update_lb) root = Tk.Tk() Lb = Tk.Listbox(root) Lb.pack() Lb.after(1000, update_lb) root.mainloop() ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 04:01 Message: Logged In: YES user_id=80475 Try a gc.collect() to see if the problem persists. ---------------------------------------------------------------------- Comment By: Angelo Bonet (abonet) Date: 2003-08-02 03:06 Message: Logged In: YES user_id=716439 Sorry, but indentation got lost on script sample. Look at attached file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 From noreply@sourceforge.net Sat Aug 2 13:32:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 05:32:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 04:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Patrick Useldinger (uselpa) Assigned to: Nobody/Anonymous (nobody) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-02 08:32 Message: Logged In: YES user_id=31435 Python has no idea how much space you have left. Write the code in raw C, and the same thing will happen (Python raises an exception because C's I/O returned an error code). It looks like you in fact don't have enough disk space to complete the write. That's why C is complaining. As someone already explained on comp.lang.python, filesystems have hidden overheads, and hoping you can fill it to the last byte with usable data is futile. Experiment: since you're on Windows, try making a copy of the file from a DOS box with "copy /b". That should fail too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply@sourceforge.net Sat Aug 2 21:22:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 13:22:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 08:51 Message generated for change (Comment added) made by uselpa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Patrick Useldinger (uselpa) Assigned to: Nobody/Anonymous (nobody) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- >Comment By: Patrick Useldinger (uselpa) Date: 2003-08-02 20:22 Message: Logged In: YES user_id=835987 As already explained on c.l.python, a manual copy via Explorer *does* work. I've just repeated the same with a copy /b, and again that's OK. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-02 12:32 Message: Logged In: YES user_id=31435 Python has no idea how much space you have left. Write the code in raw C, and the same thing will happen (Python raises an exception because C's I/O returned an error code). It looks like you in fact don't have enough disk space to complete the write. That's why C is complaining. As someone already explained on comp.lang.python, filesystems have hidden overheads, and hoping you can fill it to the last byte with usable data is futile. Experiment: since you're on Windows, try making a copy of the file from a DOS box with "copy /b". That should fail too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply@sourceforge.net Sat Aug 2 21:26:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 13:26:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 08:51 Message generated for change (Settings changed) made by uselpa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 Category: Python Library Group: Not a Bug >Status: Open Resolution: Invalid Priority: 5 Submitted By: Patrick Useldinger (uselpa) Assigned to: Nobody/Anonymous (nobody) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-02 20:22 Message: Logged In: YES user_id=835987 As already explained on c.l.python, a manual copy via Explorer *does* work. I've just repeated the same with a copy /b, and again that's OK. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-02 12:32 Message: Logged In: YES user_id=31435 Python has no idea how much space you have left. Write the code in raw C, and the same thing will happen (Python raises an exception because C's I/O returned an error code). It looks like you in fact don't have enough disk space to complete the write. That's why C is complaining. As someone already explained on comp.lang.python, filesystems have hidden overheads, and hoping you can fill it to the last byte with usable data is futile. Experiment: since you're on Windows, try making a copy of the file from a DOS box with "copy /b". That should fail too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply@sourceforge.net Sat Aug 2 21:40:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 02 Aug 2003 13:40:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-781883 ] Listbox itemconfigure leaks memory Message-ID: Bugs item #781883, was opened at 2003-08-02 01:01 Message generated for change (Comment added) made by abonet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Angelo Bonet (abonet) Assigned to: Nobody/Anonymous (nobody) Summary: Listbox itemconfigure leaks memory Initial Comment: Calling itemconfigure on Tkinter.Listbox to change item colors seems to leak memory without bounds. I've seen this in Python 2.2 and 2.3 on SunOS, Tru64, and Linux. Here's a small script that demostrates it: import Tkinter as Tk Lb = None def update_lb (): global Lb Lb.delete(0, Tk.END) for ii in range(100): Lb.insert(Tk.END, 'Item %d' % ii) Lb.itemconfigure(ii, bg='red') Lb.after(10, update_lb) root = Tk.Tk() Lb = Tk.Listbox(root) Lb.pack() Lb.after(1000, update_lb) root.mainloop() ---------------------------------------------------------------------- >Comment By: Angelo Bonet (abonet) Date: 2003-08-02 13:40 Message: Logged In: YES user_id=716439 Calling gc.collect() seems to reduce the rate at which memory is leaking, but it does not eliminate the leak. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 02:01 Message: Logged In: YES user_id=80475 Try a gc.collect() to see if the problem persists. ---------------------------------------------------------------------- Comment By: Angelo Bonet (abonet) Date: 2003-08-02 01:06 Message: Logged In: YES user_id=716439 Sorry, but indentation got lost on script sample. Look at attached file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 From noreply@sourceforge.net Sun Aug 3 16:11:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 08:11:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-778681 ] struct does not pad to alignment Message-ID: Bugs item #778681, was opened at 2003-07-27 20:28 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778681&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: struct does not pad to alignment Initial Comment: Given this C code: --- struct x { int a; char b; }; int main() { printf("sizeof(x)=%d\n", sizeof(struct x)); } --- And its Python counterpart: --- import struct print "calcsize(\iB\)=%d" % struct.calcsize("iB") --- On Intel (x86) Linux, Python 2.3b2+ (#2, Jul 5 2003, 11:28:28) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2, the former shows 8 while the latter 5. I'm working with struct cdrom_tocentry from linux/include.h, and if I use the results of struct.pack, I get a string that's three bytes too short. Whether that is an actual issue or not depends on whether Linux expects to be able to use the entire 8 bytes in an ioctl or not, I suppose. ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-03 10:11 Message: Logged In: YES user_id=2772 As a workaround you can manually pad, using "iBxxx" as the struct format string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778681&group_id=5470 From noreply@sourceforge.net Sun Aug 3 16:24:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 08:24:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-781883 ] Listbox itemconfigure leaks memory Message-ID: Bugs item #781883, was opened at 2003-08-02 03:01 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Angelo Bonet (abonet) Assigned to: Nobody/Anonymous (nobody) Summary: Listbox itemconfigure leaks memory Initial Comment: Calling itemconfigure on Tkinter.Listbox to change item colors seems to leak memory without bounds. I've seen this in Python 2.2 and 2.3 on SunOS, Tru64, and Linux. Here's a small script that demostrates it: import Tkinter as Tk Lb = None def update_lb (): global Lb Lb.delete(0, Tk.END) for ii in range(100): Lb.insert(Tk.END, 'Item %d' % ii) Lb.itemconfigure(ii, bg='red') Lb.after(10, update_lb) root = Tk.Tk() Lb = Tk.Listbox(root) Lb.pack() Lb.after(1000, update_lb) root.mainloop() ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-03 10:24 Message: Logged In: YES user_id=2772 The problem can be seen in an equivalent tcl script. This may indicate that the problem is not in Python itself, but in the third-party Tcl/Tk library. The script follows. I hope indentation isn't lost, but at least Tk has curly braces for just such an emergency. proc update_lb {} { .lb delete 0 end for {set i 0} {$i < 100} {incr i} { .lb insert end "Item $i" .lb itemco $i -bg red } after 10 update_lb } listbox .lb pack .lb after 10 update_lb ---------------------------------------------------------------------- Comment By: Angelo Bonet (abonet) Date: 2003-08-02 15:40 Message: Logged In: YES user_id=716439 Calling gc.collect() seems to reduce the rate at which memory is leaking, but it does not eliminate the leak. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 04:01 Message: Logged In: YES user_id=80475 Try a gc.collect() to see if the problem persists. ---------------------------------------------------------------------- Comment By: Angelo Bonet (abonet) Date: 2003-08-02 03:06 Message: Logged In: YES user_id=716439 Sorry, but indentation got lost on script sample. Look at attached file instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781883&group_id=5470 From noreply@sourceforge.net Sun Aug 3 17:15:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 09:15:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 12:15 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=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Sun Aug 3 17:37:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 09:37:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-778681 ] struct does not pad to alignment Message-ID: Bugs item #778681, was opened at 2003-07-27 21:28 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778681&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: struct does not pad to alignment Initial Comment: Given this C code: --- struct x { int a; char b; }; int main() { printf("sizeof(x)=%d\n", sizeof(struct x)); } --- And its Python counterpart: --- import struct print "calcsize(\iB\)=%d" % struct.calcsize("iB") --- On Intel (x86) Linux, Python 2.3b2+ (#2, Jul 5 2003, 11:28:28) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2, the former shows 8 while the latter 5. I'm working with struct cdrom_tocentry from linux/include.h, and if I use the results of struct.pack, I get a string that's three bytes too short. Whether that is an actual issue or not depends on whether Linux expects to be able to use the entire 8 bytes in an ioctl or not, I suppose. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-03 12:37 Message: Logged In: YES user_id=31435 You shouldn't pad the end "by hand". The last paragraph of the struct module docs explains the intended method: """ Hint: to align the end of a structure to the alignment requirement of a particular type, end the format with the code for that type with a repeat count of zero. For example, the format 'llh0l' specifies two pad bytes at the end, assuming longs are aligned on 4-byte boundaries. This only works when native size and alignment are in effect; standard size and alignment does not enforce any alignment. """ Python can't guess how a platform compiler is going to pad the *end* of a struct; indeed, it may well depend on C compiler options. If the OP's compiler pads the end to int alignment in the examle, then the OP can tell the struct module that by using "iB0i". I'm closing this now as WontFix, because Python is likely doing the best it can already here; and, if it's not, it can't be changed now without breaking working code (so if someone thinks they know how to do better, it would have to go in as a new function, or new option to calcsize (etc) -- then it's a new feature, not a bugfix). ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-03 11:11 Message: Logged In: YES user_id=2772 As a workaround you can manually pad, using "iBxxx" as the struct format string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778681&group_id=5470 From noreply@sourceforge.net Sun Aug 3 18:45:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 10:45:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1,200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 12:17 Message generated for change (Comment added) made by drmalte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Malte John (drmalte) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- >Comment By: Malte John (drmalte) Date: 2003-08-03 17:45 Message: Logged In: YES user_id=834648 Thanks for the hint! I pulled out _strptimy.py Version 1.23 which is identical to the version in the Python-2.3.tgz I used. :( Here is the output of tar -ztvf ... -rw-rw-r-- barry/barry 20933 2003-07-24 22:02:28 Python-2.3/Lib/_strptime.py ... Regards Malte ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 08:53 Message: Logged In: YES user_id=80475 It would be interesting for you to pull down the CVS version from two weeks ago and re-run your timings. The caching code was removed at the end because it was a temporary suspect on a bug-hunt just days before the release. Note, the whole purpose of the pure python version was to avoid the non-portable differences between strptime() implementations on various target systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply@sourceforge.net Sun Aug 3 18:50:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 10:50:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 12:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Raymond Hettinger (rhettinger) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 13:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Sun Aug 3 19:13:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 11:13:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) >Assigned to: Martin v. Löwis (loewis) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 20:13 Message: Logged In: YES user_id=21627 Attached is a patch that fixes the problem that IDLE is unable to save test_01.py. I'll apply it as soon as the maintenance branch is open. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 06:39 Message: Logged In: YES user_id=21627 IDLE 0.8 interprets this example because of a bug; the data are still bogus. You can use the attached clean.py to convert the file into iso-8859-1. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-23 00:22 Message: Logged In: YES user_id=624347 What does it mean "completely corrupted"? IDLE 0.8 can open and execute it. Is there a way of "cleaning" it? Do you need more information from me? I will be available until Saturday the 26th of July. Best regards. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:53 Message: Logged In: YES user_id=21627 I finally understand what is going on. The file test_01.py is completely corrupted. The second line is encoded in Latin-1, whereas the last line is encoded in UTF-8. There is no way IDLE 1.0 could possibly process it in a meaningful way. The problem with saving it still needs to be addressed. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-22 23:40 Message: Logged In: YES user_id=624347 1. I have added getdefaultencoding() to test_01.py: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" In Python 2.2.3 (IDLE 0.8) the ouput of the program is now: cp1252 ¡hola, mundo! áéíóú (as expected) 2. In Python 2.3rc1 (IDLE 1.0rc1) the output of test_01.py is: ascii ¡hola, mundo! áéíóú But I can not save it as test_02.py (as I have explained in my previous post). 3. I delete the non-ASCII characters. test_02.py is now: from sys import * print getdefaultencoding() print "hola, mundo!" print Now I can save it in IDLE 1.0rc1 and the output is: ascii hola, mundo! 4. In IDLE 1.0rc1 I add non-ASCII characters. The program is now: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" But I can not save it as test_03.py (as I have explained in my previous post). 5. I am sending attached test_01.py and test_02.py in a zip file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Sun Aug 3 19:23:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 11:23:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-780887 ] recent-files defaulted to strange place and bad permissions Message-ID: Bugs item #780887, was opened at 2003-07-31 16:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lloyd Hugh Allen (lha2) Assigned to: Nobody/Anonymous (nobody) Summary: recent-files defaulted to strange place and bad permissions Initial Comment: After a non-admin install of Python 2.3 with Python 2.2 admin-installed, I got: C:\Python23\Lib\idlelib>c:\python23\python idle.py Traceback (most recent call last): File "idle.py", line 23, in ? idlelib.PyShell.main() File "C:\Python23\lib\idlelib\PyShell.py", line 1277, in main flist.pyshell = PyShell(flist) File "C:\Python23\lib\idlelib\PyShell.py", line 721, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Python23\lib\idlelib\OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "C:\Python23\lib\idlelib\EditorWindow.py", line 181, in __init__ self.UpdateRecentFilesList() File "C:\Python23\lib\idlelib\EditorWindow.py", line 580, in UpdateRecentFilesList RFfile=open(self.recentFilesPath,'r') IOError: [Errno13] Permission denied: 'F:\.idlerc\recent- files.lst' ====== I have a login to a university server, and the F drive is the user drive. I don't recall specifying that anything should be kept on the F drive, and would prefer that recent files be kept on the local machine. Changing my own permissions to .idlerc to allow full permissions, and to apply these permissions to contents, worked and resolved the problem, except that multiple users use the same network drive and will now share recent files. Idle 1.0 under the brand-spanking-new Python2.3, with Windows XP Professional 5.1.2600 Service Pack 1 Build 2600. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 20:23 Message: Logged In: YES user_id=21627 IDLE first tries %HOME%, then %HOMEDRIVE%/%HOMEPATH% The latter is the system convention, so IDLE should follow it. So setting the HOME environment variable should fix this problem. Is this a sufficient solution? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780887&group_id=5470 From noreply@sourceforge.net Sun Aug 3 20:19:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 12:19:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Sun Aug 3 20:31:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 12:31:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Sun Aug 3 20:48:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 12:48:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-779147 ] FutureWarning in Carbon/Controls.py Message-ID: Bugs item #779147, was opened at 2003-07-28 16:27 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779147&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Jack Jansen (jackjansen) Summary: FutureWarning in Carbon/Controls.py Initial Comment: While building a wxPython standalone with bundlebuilder.py I got the following warning that I hadn't seen before. Just in case this is an issue for 2.3rc2 I thought I should bring it up here. Finding module dependencies /Library/Frameworks/Python.framework/Versions/2.3/lib/p ython2.3/plat-mac/Carbon/Controls.py:11: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up kDataBrowserClientPropertyFlagsMask = 0xFF000000 ka ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-08-03 15:48 Message: Logged In: YES user_id=593130 This is a new warning intentionally added to 2.3. It means just what it says, to warn you in case the planned change will break your code. Check the PEP on int/long unification, discussions on c.l.py and pydev, and I presume, somewhere in the 2.3 release docs. If you still have questions, ask on c.l.py. Unless you still see a bug, please close his (I can't). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779147&group_id=5470 From noreply@sourceforge.net Sun Aug 3 21:22:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 13:22:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 22:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Sun Aug 3 23:40:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 15:40:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-782510 ] idna codec and absolute names Message-ID: Bugs item #782510, was opened at 2003-08-03 15: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=782510&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Nobody/Anonymous (nobody) Summary: idna codec and absolute names Initial Comment: If you give the idna codec an explicitly absolute domain name, i.e. one ending in '.', it dies: >>> u'www.python.org.'.encode('idna') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/encodings/idna.py", line 154, in encode result.append(ToASCII(label)) File "/usr/local/lib/python2.3/encodings/idna.py", line 72, in ToASCII raise UnicodeError, "label too long" UnicodeError: label too long The error message is misleading; the problem isn't that the label is too long, it's that len(label) == 0. The empty label occurs because the code is doing a split() on u'.' (and other unicode code points equivalent to u'.') and is thus getting an empty label at the end due to the trailing u'.' The idna codec is used internally within the Python library, so this bug can manifest in many situations where the user passes a unicode string to a library routine expecting a hostname. E.g. s = socket.socket() s.connect((u'www.python.org.', 80)) will also fail. Domain names with trailing dots should be allowed because they are legal, and because they are useful, allowing the user to say "I mean this name, exactly", and thereby preventing the stub resolver from applying the search list to the name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782510&group_id=5470 From noreply@sourceforge.net Mon Aug 4 00:02:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 16:02:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 11:15 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:02 Message: Logged In: YES user_id=44345 Added a test case to test_array.py (1.25) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 12:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Mon Aug 4 00:21:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 16:21:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 12:15 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-03 19:21 Message: Logged In: YES user_id=31435 Neal, yup, that's the leak. PySequence_GetItem() either returns NULL or a new reference, and in the latter case the result must always be decrefed; PyList_GetItem() returned a borrowed reference (or NULL). The code should also check PySequence_GetItem() for an error (NULL) return, although the laziness of not checking for that was probably inherited from earlier code. Skip, tests that use a refcount-revealing function should be conditionalized on hasattr(sys, 'name_of_function'), to avoid creating headaches for Jython testing. You shouldn't check in failing tests independent of fixes: the intent is that someone getting a fresh checkout should never see a test failure. Leaving assigned to Raymond for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 19:02 Message: Logged In: YES user_id=44345 Added a test case to test_array.py (1.25) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 13:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Mon Aug 4 00:32:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 16:32:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 11:15 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:32 Message: Logged In: YES user_id=44345 Sorry - thought I was saving Raymond about 30 seconds of work. I'll remember in the future. Also, I checked in a version with the required hasattr() check. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-03 18:21 Message: Logged In: YES user_id=31435 Neal, yup, that's the leak. PySequence_GetItem() either returns NULL or a new reference, and in the latter case the result must always be decrefed; PyList_GetItem() returned a borrowed reference (or NULL). The code should also check PySequence_GetItem() for an error (NULL) return, although the laziness of not checking for that was probably inherited from earlier code. Skip, tests that use a refcount-revealing function should be conditionalized on hasattr(sys, 'name_of_function'), to avoid creating headaches for Jython testing. You shouldn't check in failing tests independent of fixes: the intent is that someone getting a fresh checkout should never see a test failure. Leaving assigned to Raymond for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:02 Message: Logged In: YES user_id=44345 Added a test case to test_array.py (1.25) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 12:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Mon Aug 4 07:01:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 03 Aug 2003 23:01:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 11:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Neal Norwitz (nnorwitz) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-04 01:01 Message: Logged In: YES user_id=80475 Attaching a patch for a second review. The refcnt difference between Py_SequenceGetItem and Py_ListGetItem bit me in the behind. Added the DECREF where Neal suggested but used a regular DECREF instead of an XDECREF because it is preceded by a guard. The question then arose as to where the decreffing would affect the subsequent code, so I took another look at the two following sections. It appears to me (and I really could use a second confirmation on this) that the String and UniCode sections were unnecessarily recopying the initializer when the length was greater than zero. So, I changed the "if" to an "else if" to preclude the double copy and to resolve the question about the validity of the decref. Also, I added the NULL check for the getitem as Tim suggested. With the patch, all test cases (including Skip's test) and the OP's code run fine. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:32 Message: Logged In: YES user_id=44345 Sorry - thought I was saving Raymond about 30 seconds of work. I'll remember in the future. Also, I checked in a version with the required hasattr() check. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-03 18:21 Message: Logged In: YES user_id=31435 Neal, yup, that's the leak. PySequence_GetItem() either returns NULL or a new reference, and in the latter case the result must always be decrefed; PyList_GetItem() returned a borrowed reference (or NULL). The code should also check PySequence_GetItem() for an error (NULL) return, although the laziness of not checking for that was probably inherited from earlier code. Skip, tests that use a refcount-revealing function should be conditionalized on hasattr(sys, 'name_of_function'), to avoid creating headaches for Jython testing. You shouldn't check in failing tests independent of fixes: the intent is that someone getting a fresh checkout should never see a test failure. Leaving assigned to Raymond for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:02 Message: Logged In: YES user_id=44345 Added a test case to test_array.py (1.25) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 12:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Mon Aug 4 09:21:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 01:21:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 10:21 Message: Logged In: YES user_id=38388 Uhm, we don't impose Universal readline support on the codecs. They would just get a stream object that happens to know about universal newlines and work with it. That's completely in line with the codec spec. I'm +1 on adding this to 2.3.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 22:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Mon Aug 4 09:24:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 01:24:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 10:24 Message: Logged In: YES user_id=45365 There's no such things as "rbU", I think, but simply "rU" should work. As far as I know the only difference between "r" and "rb" is newline conversion, right? If there are C libraries that do more then we should implement "rbU". About 2.3.1 compatibility: technically we could break workarounds people have done themselves, but I think the chances are slim. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 10:21 Message: Logged In: YES user_id=38388 Uhm, we don't impose Universal readline support on the codecs. They would just get a stream object that happens to know about universal newlines and work with it. That's completely in line with the codec spec. I'm +1 on adding this to 2.3.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 22:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Mon Aug 4 09:34:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 01:34:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-782686 ] IDE defaults to Mac linefeeds Message-ID: Bugs item #782686, was opened at 2003-08-04 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=782686&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE defaults to Mac linefeeds Initial Comment: The IDE defaults to Mac linefeeds for new files, also in MacPython-OSX. In PyEdit.Editor.__init__ the logic for initializing self._eoln is fishy, and also incorrect. It should probably use "rU" for reading the files and use f.newlines to initialize it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782686&group_id=5470 From noreply@sourceforge.net Mon Aug 4 09:38:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 01:38:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-782689 ] PyObject_Free unallocated memory read warning Message-ID: Bugs item #782689, was opened at 2003-08-04 10: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=782689&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: PyObject_Free unallocated memory read warning Initial Comment: win2k, vc6sp5 ADDRESS_IN_RANGE(p, pool->arenaindex)) is too simple and may read unmanaged memory when "p" does not belong to selected pool and there is something allocated by python allocator and pool->arenaindex is smaller than narenas (random case). valgrind messages for PyObject_Free line 711: Conditional jump or move depends on uninitialised value(s) Use of uninitialised value of size 4 Invalid read of size 4 simple test: #include extern void *PyObject_Malloc(int size); extern void PyObject_Free(void *mem); void main() { void *p0; void *p; int i; p0 = PyObject_Malloc(100); for(i = 1; i < 512; i++ ){ p = PyObject_Malloc(i); PyObject_Free(p); } PyObject_Free(p0); } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782689&group_id=5470 From noreply@sourceforge.net Mon Aug 4 12:07:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 04:07:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-782752 ] ImportError: cannot import name __all__ Message-ID: Bugs item #782752, was opened at 2003-08-04 14: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=782752&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Indrek Kruusa (ikruusa) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: cannot import name __all__ Initial Comment: in module fnmatch.py: from sre import __all__ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782752&group_id=5470 From noreply@sourceforge.net Mon Aug 4 12:16:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 04:16:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-782755 ] Typo in os.py? Message-ID: Bugs item #782755, was opened at 2003-08-04 14: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=782755&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Indrek Kruusa (ikruusa) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in os.py? Initial Comment: from first row in os.py: r"""OS routines for Mac... This char "r" at first position seems to be typo. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782755&group_id=5470 From noreply@sourceforge.net Mon Aug 4 12:21:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 04:21:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Walter Dörwald (doerwalter) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 13:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply@sourceforge.net Mon Aug 4 12:24:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 04:24:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-782755 ] Typo in os.py? Message-ID: Bugs item #782755, was opened at 2003-08-04 13:16 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782755&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Indrek Kruusa (ikruusa) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in os.py? Initial Comment: from first row in os.py: r"""OS routines for Mac... This char "r" at first position seems to be typo. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 13:24 Message: Logged In: YES user_id=89016 This is not a bug. The prefix r makes the string constant a raw string, i.e. one where raw backslashes can be use literally (see http://www.python.org/doc/current/ref/strings.html) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782755&group_id=5470 From noreply@sourceforge.net Mon Aug 4 12:41:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 04:41:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Walter Dörwald (doerwalter) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 13:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 13:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply@sourceforge.net Mon Aug 4 13:37:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 05:37:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by dmgrime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 07:37 Message: Logged In: YES user_id=699265 I know the wrapper has been there for a long time - some platforms don't support the "native" underlying FILE implementation, but many (most) platforms did. What was the problem that necessitated the change? I'd be more than willing to spend some time looking into alternative solutions which keep the optimized implementation where possible. Can you provide me with some history of the motivations for the current solution? Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 15:52 Message: Logged In: YES user_id=21627 I don't know of any other approach to solve the problem. Also notice that the wrapper object has existed for a long time already, on some systems. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 14:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Mon Aug 4 14:33:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 06:33:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 15:33 Message: Logged In: YES user_id=89016 Can you try the following patch (diff.txt)? The patch changes all open() statements to use text mode. I've tested the patch on Windows and Linux. I don't know why the old test mixed text and binary mode. The test should have failed even before the port to PyUnit. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 13:41 Message: Logged In: YES user_id=45365 It's in test_decode. The log is attached. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-08-04 13:21 Message: Logged In: YES user_id=89016 It would help to see a complete traceback (Is the error in test_encode or test_decode?) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply@sourceforge.net Mon Aug 4 14:53:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 06:53:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 08:53 Message: Logged In: YES user_id=44345 The original socket.makefile dup()s the socket to create a new file descriptor. If you have a timeout set on the original socket the new file descriptor loses this property. This was a big problem for the various modules which sit atop socket (httplib, etc) because they generally all just call s.makefile() and then treat the connected socket as a file. These are precisely the modules/classes which benefit most from socket timeouts. Note also that the current Unix implementation is what Windows (and any other platforms without a dup() system call) use to emulate makefile(). In the long run, I see a few other possibilities. Note that I haven't considered the first two in any detail. I'm in the midst of working on the third. 1. Add timeout functionality to the various higher-level modules such as httplib. Once they call s.makefile() they could propagate their current timeout to the new file object. Of course, this means file objects need to be able to timeout (not obvious that this is generally possible). 2. Store timeout information in the socket, so that if it's dup()'d it propagates the timeout to the new descriptor. Again, it's not obvious that this is possible. 3. Extend more general object support to marshal. I am working on this and hope to have something available for review later this week. As Martin indicated, it's not unreasonable to expect people wanting to marshal data to non-file objects to first pass them through marshal.dumps(). You can't, for example, marshal data to StringIO objects directly. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 07:37 Message: Logged In: YES user_id=699265 I know the wrapper has been there for a long time - some platforms don't support the "native" underlying FILE implementation, but many (most) platforms did. What was the problem that necessitated the change? I'd be more than willing to spend some time looking into alternative solutions which keep the optimized implementation where possible. Can you provide me with some history of the motivations for the current solution? Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 15:52 Message: Logged In: YES user_id=21627 I don't know of any other approach to solve the problem. Also notice that the wrapper object has existed for a long time already, on some systems. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 14:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Mon Aug 4 14:54:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 06:54:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-778804 ] CGIHTTPServer cannot manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 04:00 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Raymond Hettinger (rhettinger) >Summary: CGIHTTPServer cannot manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply@sourceforge.net Mon Aug 4 15:34:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 07:34:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Comment added) made by dmgrime You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Skip Montanaro (montanaro) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- >Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 09:34 Message: Logged In: YES user_id=699265 Thanks Skip. I see that the ripple effect here is enormous (not surprising, given that socket is used by many standard modules). As for #3 - I understand you can use marshal.dumps() and then sock.sendall() to achieve the write side of a socket-based marshalling transaction, but for a long- lived connection, marshal.load() on the .makefile()'d file of the read-side provided a very nice message-boundary mechanism, i.e. - marshal was the "protocol" on the wire... Obviously (I've already done this in my application) I can just use a thin length header on the wire, but it was just very nice that marshal accomplished this by itself. I can also (since my platform scope is known, controlled, and limited) create a socket.py local to my application which is simply (I don't use getfqdn()): from _socket import * And leave everything else as-is. Again, I appreciate the attention and effort - I think the ramifications of eliminating the "native C" implementation which previously backed .makefile() (where supported) are more than just the impact on marshal - I see potential performance loss for things which rely on it. In any event, generic object support for marshal.load() and .dump() would be great! Thanks again, Dave. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 08:53 Message: Logged In: YES user_id=44345 The original socket.makefile dup()s the socket to create a new file descriptor. If you have a timeout set on the original socket the new file descriptor loses this property. This was a big problem for the various modules which sit atop socket (httplib, etc) because they generally all just call s.makefile() and then treat the connected socket as a file. These are precisely the modules/classes which benefit most from socket timeouts. Note also that the current Unix implementation is what Windows (and any other platforms without a dup() system call) use to emulate makefile(). In the long run, I see a few other possibilities. Note that I haven't considered the first two in any detail. I'm in the midst of working on the third. 1. Add timeout functionality to the various higher-level modules such as httplib. Once they call s.makefile() they could propagate their current timeout to the new file object. Of course, this means file objects need to be able to timeout (not obvious that this is generally possible). 2. Store timeout information in the socket, so that if it's dup()'d it propagates the timeout to the new descriptor. Again, it's not obvious that this is possible. 3. Extend more general object support to marshal. I am working on this and hope to have something available for review later this week. As Martin indicated, it's not unreasonable to expect people wanting to marshal data to non-file objects to first pass them through marshal.dumps(). You can't, for example, marshal data to StringIO objects directly. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-04 07:37 Message: Logged In: YES user_id=699265 I know the wrapper has been there for a long time - some platforms don't support the "native" underlying FILE implementation, but many (most) platforms did. What was the problem that necessitated the change? I'd be more than willing to spend some time looking into alternative solutions which keep the optimized implementation where possible. Can you provide me with some history of the motivations for the current solution? Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 15:52 Message: Logged In: YES user_id=21627 I don't know of any other approach to solve the problem. Also notice that the wrapper object has existed for a long time already, on some systems. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 14:31 Message: Logged In: YES user_id=699265 It is clear that something which used to work no longer works, and I'm just wondering if the breakage is necessary. I'm not sure what all was involved with respect to timeouts and why the makefile() implementation had to change. I guess I see 3 problems: 1) Previously functional code breaks. While marshal is not "general purpose" in the sense it can't deal with instances, etc. it is still very useful and for data which doesn't contain many redundant references (where cPickle reduces them) it is the most efficient way to serialize and unserialize "native" python types. 2) The performance of everything which uses the results of socket.makefile() now suffers the cost of a pure-python implementation where it had perviously been optimized as a C implementation on platforms which supported it (most). 3) Any other 3rd party C extensions which use the PyFile_Check (and would previously have worked) break. Is there another way to solve the timeout problem? Breaking something which has worked since 1.5 somehow feels wrong to me. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 14:09 Message: Logged In: YES user_id=21627 I don't think anymore that marshal has a problem. There is nothing wrong with it breaking when operating on a socket; marshal is not for general application use, anyway. Anybody who wants to transmit marshalled data over a socket can still dump them into a string first. So I propose to fix this aspect by documenting this intended limitation. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:52 Message: Logged In: YES user_id=44345 Agreed, marshal has problems. It's problems are a bit deeper than the technique in cPickle can solve, however. It seems to me that the WFILE struct is a bad hack. It should contain a union with three elements, one is the regular FILE * stuff, one is the current write-to-string stuff, and a third is a "generic object which has a write method". I'll see if I can whip something up and pass along to Martin for review. ---------------------------------------------------------------------- Comment By: David M. Grimes (dmgrime) Date: 2003-08-01 09:27 Message: Logged In: YES user_id=699265 Skip -- I stand corrected (for cPickle, anyway) - but I imagine there is a performance degredation over the "old" way of doing things - if I get a chance, I'll test that. The problem does still exist at least in marshal (.load and .dump only accept a "real" file object). I did a grep for PyFile_Check in the source tree prior to posting the bug report, and was a little over zealous to include cPickle in the subject. There are other places in the source ( and possibly in 3rd party extensions) which use PyFile_Check, and I haven't had a change to analyze those yet. In any case, marshal doesn't work - in your test, if you change the cPickle to marshal, you'll get: Traceback (most recent call last): File "x.py", line 10, in ? marshal.dump("Hello, world", f) TypeError: marshal.dump() 2nd arg must be file Again, I'm not sure of the impact other places where PyFile_Check is used, and I don't know the performance loss in cPickle (as compared to the "real" file implementation in pre-2.3 socket.makefile()) Let me know if there is anything I can do to help debug/fix! ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:18 Message: Logged In: YES user_id=44345 I modified the Demo/sockets/unixclient.py script to the following: # Echo client demo using Unix sockets # Piet van Oostrum from socket import * FILE = 'blabla' s = socket(AF_UNIX, SOCK_STREAM) s.connect(FILE) import cPickle f = s.makefile("wb") cPickle.dump("Hello, world", f) f.close() #s.send('Hello, world') data = s.recv(1024) s.close() print 'Received', `data` It seemed to work fine when connected to the corresponding unixserver.py script. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-01 09:11 Message: Logged In: YES user_id=44345 Looking at the code in cPickle.c it appears that as long as the object being written to has a 'write' method it should do the right thing. Can you provide a simple test case which fails? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 02:14 Message: Logged In: YES user_id=21627 See the bug that this patch closes; I doubt there is an alternative approach. Instead, I think the C modules that expect file objects need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Mon Aug 4 16:57:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 08:57:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 17:57 Message: Logged In: YES user_id=38388 Jack, I was just looking at the code I posted and the one in fileobect.c. The latter enables universal newline support whenever it sees a 'U' in the mode string, so I throught that adding a 'U' to the mode would be enough. The only system where 'b' does make a difference that I'm aware of is Windows, so you may want to check whether it makes a difference there. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 10:24 Message: Logged In: YES user_id=45365 There's no such things as "rbU", I think, but simply "rU" should work. As far as I know the only difference between "r" and "rb" is newline conversion, right? If there are C libraries that do more then we should implement "rbU". About 2.3.1 compatibility: technically we could break workarounds people have done themselves, but I think the chances are slim. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 10:21 Message: Logged In: YES user_id=38388 Uhm, we don't impose Universal readline support on the codecs. They would just get a stream object that happens to know about universal newlines and work with it. That's completely in line with the codec spec. I'm +1 on adding this to 2.3.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 22:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Mon Aug 4 17:36:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 09:36:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1,200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 05:17 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Malte John (drmalte) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-04 09:36 Message: Logged In: YES user_id=357491 Raymond is talking about version 1.21 . That was the last version with caching. I realize that strptime is no longer a speed demon for those platforms that have a C version, but now everyone has a version that is consistent which I think is worth the slowdown. But there still might be hope for a speedup. There is a chance that I will be allowed to reintroduce the caching code for 2.3.1 . If that happens performance will pick up significantly. If not you will have to wait until 2.4 . ---------------------------------------------------------------------- Comment By: Malte John (drmalte) Date: 2003-08-03 10:45 Message: Logged In: YES user_id=834648 Thanks for the hint! I pulled out _strptimy.py Version 1.23 which is identical to the version in the Python-2.3.tgz I used. :( Here is the output of tar -ztvf ... -rw-rw-r-- barry/barry 20933 2003-07-24 22:02:28 Python-2.3/Lib/_strptime.py ... Regards Malte ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 01:53 Message: Logged In: YES user_id=80475 It would be interesting for you to pull down the CVS version from two weeks ago and re-run your timings. The caching code was removed at the end because it was a temporary suspect on a bug-hunt just days before the release. Note, the whole purpose of the pure python version was to avoid the non-portable differences between strptime() implementations on various target systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply@sourceforge.net Mon Aug 4 19:02:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 11:02:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-782752 ] ImportError: cannot import name __all__ Message-ID: Bugs item #782752, was opened at 2003-08-04 07:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782752&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Indrek Kruusa (ikruusa) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: cannot import name __all__ Initial Comment: in module fnmatch.py: from sre import __all__ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-04 14:02 Message: Logged In: YES user_id=33168 The only "from sre import __all__" is in re.py, not fnmatch.py. If this is failing it is probably because Modules/sre.c failed to compile. You can try starting python with -v to see more about imports. There's not enough information to know what's going on. What platform is this on? Did sre.c compile? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782752&group_id=5470 From noreply@sourceforge.net Mon Aug 4 20:34:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 12:34:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 09:16 Message generated for change (Comment added) made by johnjsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-08-04 19:34 Message: Logged In: YES user_id=830565 In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated as EOF, unless the file is opened with 'rb'. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 15:57 Message: Logged In: YES user_id=38388 Jack, I was just looking at the code I posted and the one in fileobect.c. The latter enables universal newline support whenever it sees a 'U' in the mode string, so I throught that adding a 'U' to the mode would be enough. The only system where 'b' does make a difference that I'm aware of is Windows, so you may want to check whether it makes a difference there. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 08:24 Message: Logged In: YES user_id=45365 There's no such things as "rbU", I think, but simply "rU" should work. As far as I know the only difference between "r" and "rb" is newline conversion, right? If there are C libraries that do more then we should implement "rbU". About 2.3.1 compatibility: technically we could break workarounds people have done themselves, but I think the chances are slim. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 08:21 Message: Logged In: YES user_id=38388 Uhm, we don't impose Universal readline support on the codecs. They would just get a stream object that happens to know about universal newlines and work with it. That's completely in line with the codec spec. I'm +1 on adding this to 2.3.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 20:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 19:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 19:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 09:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 08:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 07:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 07:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Mon Aug 4 21:54:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 13:54:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-783095 ] MacOS9: installer should test CarbonLib version Message-ID: Bugs item #783095, was opened at 2003-08-04 22: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=783095&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: installer should test CarbonLib version Initial Comment: Apparently MacPython 2.3 needs CarbonLib 1.3 or later. The installer should test for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783095&group_id=5470 From noreply@sourceforge.net Mon Aug 4 22:08:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 14:08:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 08:51 Message generated for change (Comment added) made by uselpa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Patrick Useldinger (uselpa) >Assigned to: Tim Peters (tim_one) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- >Comment By: Patrick Useldinger (uselpa) Date: 2003-08-04 21:08 Message: Logged In: YES user_id=835987 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 ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-04 21:08 Message: Logged In: YES user_id=835987 I have done a final test; my program is now either able to use shutil.copy2, or an external copy program, in exactly the same situation. shutil2.copy() fails xcopy.exe on Windows works ok Source code is attached; see module dfcProcCopy ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-02 20:22 Message: Logged In: YES user_id=835987 As already explained on c.l.python, a manual copy via Explorer *does* work. I've just repeated the same with a copy /b, and again that's OK. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-02 12:32 Message: Logged In: YES user_id=31435 Python has no idea how much space you have left. Write the code in raw C, and the same thing will happen (Python raises an exception because C's I/O returned an error code). It looks like you in fact don't have enough disk space to complete the write. That's why C is complaining. As someone already explained on comp.lang.python, filesystems have hidden overheads, and hoping you can fill it to the last byte with usable data is futile. Experiment: since you're on Windows, try making a copy of the file from a DOS box with "copy /b". That should fail too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply@sourceforge.net Mon Aug 4 22:34:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 14:34:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 12:15 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Raymond Hettinger (rhettinger) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-04 17:34 Message: Logged In: YES user_id=33168 Patch looks good to me. Do you know if there were any other changes from Py_ListGetItem to Py_SequenceGetItem? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-04 02:01 Message: Logged In: YES user_id=80475 Attaching a patch for a second review. The refcnt difference between Py_SequenceGetItem and Py_ListGetItem bit me in the behind. Added the DECREF where Neal suggested but used a regular DECREF instead of an XDECREF because it is preceded by a guard. The question then arose as to where the decreffing would affect the subsequent code, so I took another look at the two following sections. It appears to me (and I really could use a second confirmation on this) that the String and UniCode sections were unnecessarily recopying the initializer when the length was greater than zero. So, I changed the "if" to an "else if" to preclude the double copy and to resolve the question about the validity of the decref. Also, I added the NULL check for the getitem as Tim suggested. With the patch, all test cases (including Skip's test) and the OP's code run fine. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 19:32 Message: Logged In: YES user_id=44345 Sorry - thought I was saving Raymond about 30 seconds of work. I'll remember in the future. Also, I checked in a version with the required hasattr() check. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-03 19:21 Message: Logged In: YES user_id=31435 Neal, yup, that's the leak. PySequence_GetItem() either returns NULL or a new reference, and in the latter case the result must always be decrefed; PyList_GetItem() returned a borrowed reference (or NULL). The code should also check PySequence_GetItem() for an error (NULL) return, although the laziness of not checking for that was probably inherited from earlier code. Skip, tests that use a refcount-revealing function should be conditionalized on hasattr(sys, 'name_of_function'), to avoid creating headaches for Jython testing. You shouldn't check in failing tests independent of fixes: the intent is that someone getting a fresh checkout should never see a test failure. Leaving assigned to Raymond for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 19:02 Message: Logged In: YES user_id=44345 Added a test case to test_array.py (1.25) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 13:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Tue Aug 5 03:45:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 19:45:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-726911 ] platform module needs docs (LaTeX) Message-ID: Bugs item #726911, was opened at 2003-04-24 10:22 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Brett Cannon (bcannon) Summary: platform module needs docs (LaTeX) Initial Comment: The platform module needs to be documented in the Library Reference. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-04 22:45 Message: Logged In: YES user_id=3066 We have a volunteer! Just check it in when you're ready, Brett. I'll be glad to make any ancilliary updates if you're not able to test the LaTeX yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470 From noreply@sourceforge.net Tue Aug 5 04:08:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 20:08:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-621554 ] menues in emacs21 in transient mode Message-ID: Bugs item #621554, was opened at 2002-10-10 15:32 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: menues in emacs21 in transient mode Initial Comment: [from http://bugs.debian.org/160130 and http://bugs.debian.org/144653] python-elisp: Menus don't work under emacs21 in transient mark mode Under Emacs 21, any attempt to access the menus in python-mode fails unless the mark is active, with the message Debugger entered--Lisp error: (mark-inactive) signal(mark-inactive nil) mark() This happens only if transient-mark-mode (menu item: Options->Active Region Highlighting) is active and 'debug-on-error' is on. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:08 Message: Logged In: YES user_id=44345 closing - migrating to the new python-mode project. Here's a link to that bug report: https://sourceforge.net/tracker/ index.php?func=detail&aid=783237&group_id=86916&ati d=581349 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=621554&group_id=5470 From noreply@sourceforge.net Tue Aug 5 04:10:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 20:10:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-587239 ] python-mode and nested indents Message-ID: Bugs item #587239, was opened at 2002-07-26 15:56 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587239&group_id=5470 Category: Demos and Tools Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode and nested indents Initial Comment: Using Python-mode 4.6 and GNU emacs 21.2.2, I enter the following: if x < 0: for i in range(100): print i else: print "x is negative" If I now put the cursor on the "else:" line and hit tab, it erroneously changes the indentation to line the "else" up with the "for" above it. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:10 Message: Logged In: YES user_id=44345 Migrating to the new python-mode project. You can follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783235&group_id=86916&ati d=581349 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-26 17:40 Message: Logged In: YES user_id=31435 It's up to Barry to decide (and I assigned the report to him). I'll only add that the behavior does appear to be as documented: """ The \[indent-for-tab-command] and \[py-newline-and- indent] keys try to suggest plausible indentation, based on the indentation of preceding statements. [example snipped] Python-mode cannot know whether that's what you intended, or whether \tif a > 0: \t c = d \t_ was your intent. In general, Python-mode either reproduces the indentation of the (closest code or indenting-comment) preceding statement, or adds an extra py-indent-offset blanks if the preceding statement has `:' as its last significant (non-whitespace and non-comment) character. If the suggested indentation is too much, use \[py-electric-backspace] to reduce it. "" That seems (to me) easy to remember and to live with. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-07-26 17:14 Message: Logged In: YES user_id=418174 If you really believe that hitting tab means that the block structure isn't what you intended, then you should also believe that hitting tab repeatedly on a line that can legally be indented in exactly two different ways (presumably with different meanings) should cycle between the meanings. Which it doesn't in this case. I am willing to accept that hitting tab should generate the maximum legal indent, which would mean that the behavior I described with "else:" isn't a bug. I do think, though, that generating an illegal indent should be considered a bug. I also think that for most cases, lining up an "else" with the nearest preceding "if" or "elif" rather than the nearest preceding "for" or "while" is less surprising, though I'll admit that's a matter of taste. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-26 17:05 Message: Logged In: YES user_id=31435 I agree that the second one (elif) may be considered a bug. Afraid I can't agree aboiut the first reason, though: of course hitting tab in pymode can change the meaning. When you've got if whatever: ->x y and hit tab when on the line containing y, it assumes you're hitting tab for a reason, not just to make trouble . I believe there's a discussion about this in the long form of the pymode help. Since pymod can't *know* the block structure you intend, it does its best to guess, and hitting a "guess the block structure I intended" key is taken as meaning, for a start, that the block structure on the current line isn't what you intended (else why would have hit the key? as a Python programmer, you should already know this isn't C mode ). ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-07-26 16:49 Message: Logged In: YES user_id=418174 Frankly, I hadn't thought of that possibility! However, I still consider the behavior a bug, for two reasons: (1) I can type something that's syntactically valid, hit tab, and have it change the meaning of what I typed, and (2) It changes the indentation in the same way if I say "elif:" instead of "else:", even though that change is not syntactically valid. That is (using -> to indicate a tab): if x < 0: ->for i in range(100): ->->print i elif x > 0: ->print x Again, hitting tab on the "elif" line will indent the "elif" to line up with the "for", even though the result is syntactically invalid. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-26 16:14 Message: Logged In: YES user_id=31435 Andrew, why is that erroneous? Loops in Python have (optional) "else:" clauses too. There's no way for pymode to guess whether you intended the else to go with the if or the for. I expect it looks backward for the closest-preceding construct the else-statement could "belong to", and finds the for-loop first. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=587239&group_id=5470 From noreply@sourceforge.net Tue Aug 5 04:12:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 20:12:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-685465 ] python-mode loops on if/else Message-ID: Bugs item #685465, was opened at 2003-02-12 12:58 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685465&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Barry A. Warsaw (bwarsaw) Summary: python-mode loops on if/else Initial Comment: Here's how to reproduce. Create a .py file in XEmacs containing this text: x = (if 1: 2 ____else: 3) (except that the ____ really means four spaces). Now position your cursor somewhere inside those 4 spaces, and hit TAB. XEmacs freezes until you hit ^G. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:12 Message: Logged In: YES user_id=44345 migrating this bug report to the new python-mode project. you can follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783240&group_id=86916&ati d=581349 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-31 22:41 Message: Logged In: YES user_id=44345 The code gets into an infloop in py-outdent-p. The loop looks odd to me: (while (or (looking-at py-blank-or-comment-re) (bobp)) (backward-to-indentation 1)) If you were at (bobp), why would you want to try to move back a line? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=685465&group_id=5470 From noreply@sourceforge.net Tue Aug 5 04:14:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 20:14:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-783242 ] test_ossaudiodev timing failure Message-ID: Bugs item #783242, was opened at 2003-08-04 23: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=783242&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: test_ossaudiodev timing failure Initial Comment: test_audiodev reports a failure because the expected output includes the line: elapsed time: 2.9 sec but when run on my system (RH 9.0), produces the output: elapsed time: 3.0 sec I'm not sure what the right fix is, but including that bit of timing information seems somewhat fragile; you don't want to number to be too low, but it should be ok for it to be a little high since you can't control time slices allocated to the test all that precisely. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783242&group_id=5470 From noreply@sourceforge.net Tue Aug 5 04:14:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 20:14:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-705005 ] python-mode.el: sexp commands don't understand Python Message-ID: Bugs item #705005, was opened at 2003-03-17 08:59 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705005&group_id=5470 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Ed Avis (epaepa) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el: sexp commands don't understand Python Initial Comment: Emacs has a whole lot of commands dealing with 'sexps', such as forward-sexp and kill-sexp. These originated with Lisp but are useful for other languages too. For example in c-mode, editing the text if (x > 7) { puts("hello"); } with point before the 'i', pressing M-C-k (kill-sexp) will first kill the 'if' keyword, leaving: (x > 7) { puts("hello"); } Then a second press of M-C-k leaves { puts("hello"); } and a third press kills the whole block following. So you can kill the whole if-statement, and nothing more, with three keypresses. This is useful for moving chunks of code around. However the same doesn't work in python-mode because Emacs doesn't appear to know about the definition of a sexp. You can kill balanced expressions on a particular line but it's not possible to remove the whole of an 'if' or 'while' block. Along the same lines, while commands like mark-defun work in most languages to select the current function definition, they don't work with Python's 'def' blocks, instead highlighting the whole file. Is it possible to get these and similar commands working, or is Emacs hardwired to look for starting and ending delimiters around each block? If it's not possible to make these commands work correctly, it might be better to disable them for python-mode rather than leave them present but wrong (eg mark-defun marks the whole buffer). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-04 22:14 Message: Logged In: YES user_id=44345 migrating to the new python-mode project. You can follow it here: https://sourceforge.net/tracker/ index.php?func=detail&aid=783241&group_id=86916&ati d=581349 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705005&group_id=5470 From noreply@sourceforge.net Tue Aug 5 06:52:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 22:52:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Martin v. Löwis (loewis) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-05 07:52 Message: Logged In: YES user_id=21627 This is now fixed in IOBinding.py 1.20 and 1.19.8.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 20:13 Message: Logged In: YES user_id=21627 Attached is a patch that fixes the problem that IDLE is unable to save test_01.py. I'll apply it as soon as the maintenance branch is open. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 06:39 Message: Logged In: YES user_id=21627 IDLE 0.8 interprets this example because of a bug; the data are still bogus. You can use the attached clean.py to convert the file into iso-8859-1. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-23 00:22 Message: Logged In: YES user_id=624347 What does it mean "completely corrupted"? IDLE 0.8 can open and execute it. Is there a way of "cleaning" it? Do you need more information from me? I will be available until Saturday the 26th of July. Best regards. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:53 Message: Logged In: YES user_id=21627 I finally understand what is going on. The file test_01.py is completely corrupted. The second line is encoded in Latin-1, whereas the last line is encoded in UTF-8. There is no way IDLE 1.0 could possibly process it in a meaningful way. The problem with saving it still needs to be addressed. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-22 23:40 Message: Logged In: YES user_id=624347 1. I have added getdefaultencoding() to test_01.py: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" In Python 2.2.3 (IDLE 0.8) the ouput of the program is now: cp1252 ¡hola, mundo! áéíóú (as expected) 2. In Python 2.3rc1 (IDLE 1.0rc1) the output of test_01.py is: ascii ¡hola, mundo! áéíóú But I can not save it as test_02.py (as I have explained in my previous post). 3. I delete the non-ASCII characters. test_02.py is now: from sys import * print getdefaultencoding() print "hola, mundo!" print Now I can save it in IDLE 1.0rc1 and the output is: ascii hola, mundo! 4. In IDLE 1.0rc1 I add non-ASCII characters. The program is now: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" But I can not save it as test_03.py (as I have explained in my previous post). 5. I am sending attached test_01.py and test_02.py in a zip file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Tue Aug 5 07:01:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 23:01:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-781065 ] test_normalization fails Message-ID: Bugs item #781065, was opened at 2003-07-31 21:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: The LinuxDuck (thelinuxduck) Assigned to: Martin v. Löwis (loewis) Summary: test_normalization fails Initial Comment: I d/l the NormalizationTest.txt from unicode.org, as suggested, then run the test as: ----------------------------------- /source/Python-build> ./python ../Python-2.3/Lib/test/regrtest.py -g test_normalization.py test_normalization test test_normalization failed -- 03F9;03F9;03F9;03A3;03A3; 1 test failed: test_normalization ----------------------------------- If I comment out that line in the file, it fails further down: ----------------------------------- test_normalization test test_normalization failed -- 1D2C;1D2C;1D2C;0041;0041; 1 test failed: test_normalization ----------------------------------- GNU C Library stable release version 2.1.3, by Roland McGrath et al. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.14 system on 2000-03-20. Available extensions: GNU libio by Per Bothner linuxthreads-0.8 by Xavier Leroy BIND-4.9.7-REL libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Linux www 2.2.16 #22 Fri Jun 16 16:51:24 PDT 2000 i586 unknown unknown GNU/Linux This is a slack 8.1 box, running gcc 3.0.2. Python version 2.3 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-05 08:01 Message: Logged In: YES user_id=21627 At the time the test was written, Unicode 3.2 was current, so the URL was correct then. I have now updated the URL in test_normalization.py 1.8 and 1.7.8.1. ---------------------------------------------------------------------- Comment By: The LinuxDuck (thelinuxduck) Date: 2003-08-01 20:58 Message: Logged In: YES user_id=490655 Doh! Guess I should have known that there would be different versions. Looks like I've got version 4.00. For anyone else having this issue, the corrent d/l location of the NormalizationTest.txt version 3.2 is http://www.unicode.org/Public/3.2-Update/NormalizationTest- 3.2.0.txt. The link provided in the tests will direct you to 4.0. Note: I have not yet recompiled with 3.2. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:03 Message: Logged In: YES user_id=21627 Can you tell what version of NormalizationTest.txt you use? Python's module is for Unicode 3.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 From noreply@sourceforge.net Tue Aug 5 07:13:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 23:13:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-783312 ] Serious mem leak in socket module Message-ID: Bugs item #783312, was opened at 2003-08-05 02: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=783312&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: Serious mem leak in socket module Initial Comment: There are memory leaks in Python 2.3's socketmodule.c:getsockaddrarg function. In the AF_INET clause of that function's switch, the PyArg_ParseTuple format was changed from "si:getsockaddrarg" in 2.2 to "eti:getsockaddrarg" in 2.3; in the AF_INET6 clause, the format was changed from "si|ii" in 2.2 to "eti|ii" in 2.3. The memory leak occurs because the "s" extractor did not allocate any memory that needed to be manually freed, whereas "et" does, yet no provision was added to free the newly allocated memory. Looks like this bug was introduced in CVS revision 1.259: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/socketmodule.c.diff?r1=1.258&r2=1.259 I've attached a test program that demonstrates the leak, plus a patch to socketmodule.c in unified diff format. To me, this leak seems serious because it affects virtually every Python program that uses the socket module (getsockaddrarg is called by the socket.socket methods bind, connect, connect_ex, and sendto). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 From noreply@sourceforge.net Tue Aug 5 07:21:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 23:21:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-782510 ] idna codec and absolute names Message-ID: Bugs item #782510, was opened at 2003-08-04 00:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782510&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: Nobody/Anonymous (nobody) Summary: idna codec and absolute names Initial Comment: If you give the idna codec an explicitly absolute domain name, i.e. one ending in '.', it dies: >>> u'www.python.org.'.encode('idna') Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/encodings/idna.py", line 154, in encode result.append(ToASCII(label)) File "/usr/local/lib/python2.3/encodings/idna.py", line 72, in ToASCII raise UnicodeError, "label too long" UnicodeError: label too long The error message is misleading; the problem isn't that the label is too long, it's that len(label) == 0. The empty label occurs because the code is doing a split() on u'.' (and other unicode code points equivalent to u'.') and is thus getting an empty label at the end due to the trailing u'.' The idna codec is used internally within the Python library, so this bug can manifest in many situations where the user passes a unicode string to a library routine expecting a hostname. E.g. s = socket.socket() s.connect((u'www.python.org.', 80)) will also fail. Domain names with trailing dots should be allowed because they are legal, and because they are useful, allowing the user to say "I mean this name, exactly", and thereby preventing the stub resolver from applying the search list to the name. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-05 08:21 Message: Logged In: YES user_id=21627 Thanks for the report. This is now fixed in idna.py 1.3 test_unicode.py 1.85 idna.py 1.2.12.1 test_unicode.py 1.84.8.1 NEWS 1.831.4.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782510&group_id=5470 From noreply@sourceforge.net Tue Aug 5 07:27:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 04 Aug 2003 23:27:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-781722 ] py-2.3 socket.inet_pton() segfault. Message-ID: Bugs item #781722, was opened at 2003-08-01 22:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781722&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Wojtek Walczak (gminick) Assigned to: Nobody/Anonymous (nobody) Summary: py-2.3 socket.inet_pton() segfault. Initial Comment: It works (read: segfaults) only when compiled without IPv6 support. Code to exploit this bug: import socket socket.inet_pton(socket.AF_INET6, '5aef:2b::8') It segfaults because of that code from Modules/socketmodule.c: --- #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; #else char packed[sizeof(struct in_addr)]; #endif if (!PyArg_ParseTuple(args, "is:inet_pton", &af, &ip)) { return NULL; } retval = inet_pton(af, ip, packed); --- Because IPv6 is disabled packet is defined in that way: char packed[sizeof(struct in_addr)]; but we're still able to ask inet_pton() to convert some IPv6 address because socket.AF_INET6 constant is available, but packet buffer is too small to hold IPv6 data. A simple patch: #--------------------------------- --- ../../orig/Python-2.3/Modules/socketmodule.c Thu Jul 17 18:58:48 2003 +++ socketmodule.c Fri Aug 1 22:13:30 2003 @@ -2962,6 +2962,14 @@ return NULL; } +#ifndef ENABLE_IPV6 + if(af == AF_INET6) { + PyErr_SetString(socket_error, + "can't use AF_INET6, IPv6 is disabled"); + return NULL; + } +#endif + retval = inet_pton(af, ip, packed); if (retval < 0) { PyErr_SetFromErrno(socket_error); #---------------------------------- Sorry, if you know about this one already. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-05 08:27 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as socketmodule.c 1.272 and 1.271.6.1, NEWS 1.831.4.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781722&group_id=5470 From noreply@sourceforge.net Tue Aug 5 08:18:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 00:18:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 19:04 Message generated for change (Comment added) made by drauh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 03:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 11:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 07:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 14:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 12:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 06:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Tue Aug 5 08:31:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 00:31:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-05 09:31 Message: Logged In: YES user_id=38388 Thanks John. Not sure whether any of codecs would actually use 0x1A, but using "rbU" sounds like the safer approach then. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-08-04 21:34 Message: Logged In: YES user_id=830565 In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated as EOF, unless the file is opened with 'rb'. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 17:57 Message: Logged In: YES user_id=38388 Jack, I was just looking at the code I posted and the one in fileobect.c. The latter enables universal newline support whenever it sees a 'U' in the mode string, so I throught that adding a 'U' to the mode would be enough. The only system where 'b' does make a difference that I'm aware of is Windows, so you may want to check whether it makes a difference there. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 10:24 Message: Logged In: YES user_id=45365 There's no such things as "rbU", I think, but simply "rU" should work. As far as I know the only difference between "r" and "rb" is newline conversion, right? If there are C libraries that do more then we should implement "rbU". About 2.3.1 compatibility: technically we could break workarounds people have done themselves, but I think the chances are slim. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 10:21 Message: Logged In: YES user_id=38388 Uhm, we don't impose Universal readline support on the codecs. They would just get a stream object that happens to know about universal newlines and work with it. That's completely in line with the codec spec. I'm +1 on adding this to 2.3.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 22:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Tue Aug 5 08:39:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 00:39:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 19:04 Message generated for change (Comment added) made by drauh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 03:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 03:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 11:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 07:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 14:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 12:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 06:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Tue Aug 5 08:55:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 00:55:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-783348 ] UNIX-locale and repr() Message-ID: Bugs item #783348, was opened at 2003-08-05 09: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=783348&group_id=5470 Category: None Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Joerg Linnenkohl (jolinnen) Assigned to: Nobody/Anonymous (nobody) Summary: UNIX-locale and repr() Initial Comment: Hi, please look at this code snippet: #!/usr/bin/python import sys import os import random import locale locale.setlocale(locale.LC_ALL, 'de_DE@euro') dp = locale.localeconv().get('decimal_point', '.') # print "--->",locale.localeconv() print "--->",dp a = random.random() b = repr(a) print b with this output : ---> , 0.24851180874790457 I expect that the output of b must be "0,24851180874790457" with a "," as a decimal point corresponding to the locale. But for floating point numbers repr() always delivers the "." as decimal point for the german locale. The real problem occurs in the email package (http://mimelib.sourceforge.net/) in the method : def _make_boundary(text=None): # Craft a random boundary. If text is given, ensure that the chosen # boundary doesn't appear in the text. dp = locale.localeconv().get('decimal_point', '.') boundary = ('=' * 15) + repr(random.random()).split(dp)[1] + '==' for the german locale (error 'listindex out of range') on repr(random.random()).split(dp)[1]. Kind regards Jörg Linnenkohl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 From noreply@sourceforge.net Tue Aug 5 11:48:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 03:48:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-05 11:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 08:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure to delete test_ioctl.pyc. ---------------------------------------------------------------------- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 08:18 Message: Logged In: YES user_id=91293 I compiled with gcc-3.2.3 (compiled from source) on a RH9 system. The error message from doing "./python ./Lib/test/test_ioctl.py" (after appropriately setting LD_LIBRARY_PATH) was: Traceback (most recent call last): File "Lib/test/test_ioctl.py", line 2, in ? from test_support import TestSkipped, run_unittest File "/opt/src/Python-2.3/Lib/test/test_support.py", line 4, in ? raise ImportError, 'test_support must be imported from the test package' ImportError: test_support must be imported from the test package In the file Lib/test/test_ioctl.py, if I replace: from test_support import TestSkipped, run_unittest with from test.test_support import TestSkipped, run_unittest the test passes as expected. Gotta love error messages. ;) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:21 Message: Logged In: YES user_id=6656 IIRC, Anthony wrote the test. Anthony, any other ideas? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 17:20 Message: Logged In: YES user_id=6656 Grr. I wonder if we should find some other ioctl to test. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-08-01 16:42 Message: Logged In: YES user_id=832557 I ran both tests you requested, twice and all four passed. I also ran 'make tests' two more times and test_ioctl now passes. This is bizarre, but test_ioctl has failed only after a fresh build, i.e. when running 'make clean; make install; make test'. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-01 12:21 Message: Logged In: YES user_id=6656 Oh good Can you try: ./python ./Lib/test/regrtest.py (this should run all the tests) and ./python ./Lib/test/regrtest.py test_fork1 test_ioctl (I *suspect* that it's test_fork1 that messes up the environment such that the ioctl test fails, but it's just a guess). ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 19:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 17:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 11:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Tue Aug 5 11:48:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 03:48:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 11:16 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-05 12:48 Message: Logged In: YES user_id=45365 You misunderstand what I tried to say (or I mis-said it:-): there is no such thing as mode "rbU", check the code in fileobject.c. There is "r" == "rt" for text mode, "rb" for binary mode, "U"=="rU" for universal newline textmode. With "rU" the underlying file is opened in binary mode, so I don't think we'll have the control-Z problem. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-05 09:31 Message: Logged In: YES user_id=38388 Thanks John. Not sure whether any of codecs would actually use 0x1A, but using "rbU" sounds like the safer approach then. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-08-04 21:34 Message: Logged In: YES user_id=830565 In MS Windows, a '\x1a' (Ctrl-Z) in a file will be treated as EOF, unless the file is opened with 'rb'. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 17:57 Message: Logged In: YES user_id=38388 Jack, I was just looking at the code I posted and the one in fileobect.c. The latter enables universal newline support whenever it sees a 'U' in the mode string, so I throught that adding a 'U' to the mode would be enough. The only system where 'b' does make a difference that I'm aware of is Windows, so you may want to check whether it makes a difference there. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-04 10:24 Message: Logged In: YES user_id=45365 There's no such things as "rbU", I think, but simply "rU" should work. As far as I know the only difference between "r" and "rb" is newline conversion, right? If there are C libraries that do more then we should implement "rbU". About 2.3.1 compatibility: technically we could break workarounds people have done themselves, but I think the chances are slim. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-04 10:21 Message: Logged In: YES user_id=38388 Uhm, we don't impose Universal readline support on the codecs. They would just get a stream object that happens to know about universal newlines and work with it. That's completely in line with the codec spec. I'm +1 on adding this to 2.3.1. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 22:22 Message: Logged In: YES user_id=21627 That would work indeed. The question is whether we can impose support for universal newlines on all codecs "out there", for Python 2.3.1, when 2.3 makes no such requirement. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-03 21:31 Message: Logged In: YES user_id=38388 I'm not sure this is correct: unless the codecs implement their own .readline() implementation, the one in codecs.py is used and that simply delegates the readline request to the underlying stream object. Now. since the stream object in the source code reader is a plain Python file object, currently opened in "rb" mode, changing the mode to "rbU" should be enough to get universal readline support for all such codecs. The relevant code is in Parser/tokenizer.c:fp_setreadl(): static int fp_setreadl(struct tok_state *tok, const char* enc) { PyObject *reader, *stream, *readline; /* XXX: constify filename argument. */ stream = PyFile_FromFile(tok->fp, (char*)tok->filename, "rb", NULL); if (stream == NULL) return 0; reader = PyCodec_StreamReader(enc, stream, NULL); Py_DECREF(stream); if (reader == NULL) return 0; readline = PyObject_GetAttrString(reader, "readline"); Py_DECREF(reader); if (readline == NULL) return 0; tok->decoding_readline = readline; return 1; } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-03 21:19 Message: Logged In: YES user_id=21627 The only way to implement that would be to add 'U' support for all codecs, and open the codec with the 'U' flag. As this will also affect codecs not part of Python, we cannot fix this bug in Python 2.3, but have to defer a solution to Python 2.4. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 11:45 Message: Logged In: YES user_id=45365 The submitter isn't calling open explicitly, but PEP278 is also about the implicit opening of sourcefiles by the interpreter. My guess (but I don't know the PEP263 implementation at all) is that when you specify an encoding the normal code that the interpreter uses to read sourcefiles is bypassed, and replaced by something that does the encoding magic. Apparently this code does not do universal newline conversion, which it should. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 10:22 Message: Logged In: YES user_id=21627 I see. This is not about PEP 278, though, as you are not calling any open() function, and passing no 'U' argument to it - cross-platform newlines should work independent of that PEP. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2003-08-01 09:35 Message: Logged In: YES user_id=463672 Attached file has encoding definition and it's newline is '\r'. Executing this script on Windows 2000, I got following error. But it runs fine if I remove encoding definition. C:\Python23>python .\test.py File ".\test.py", line 2 a() print 'hi' ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 09:04 Message: Logged In: YES user_id=21627 It's not clear to me what the problem is: Source code files and universal newline support have nothing to do with each other. Can you attach a small example that demonstrates the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Tue Aug 5 12:25:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 04:25:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-782369 ] Massive memory leak in array module Message-ID: Bugs item #782369, was opened at 2003-08-03 11:15 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Raymond Hettinger (rhettinger) Summary: Massive memory leak in array module Initial Comment: Simplified variant of a test program from c.l.py: .import array . .def test(): . for x in xrange(1000000): . b = array.array('B', range(120, 120+64)) . .test() On Win98 under 2.3, it zooms to 200MB in a few seconds. No growth under 2.2.3 (it stays under 2MB until it finishes). Problem goes away if . b = range(120, 120+64) instead. Problem also goes away if . b = array.array('B', range(64)) instead. I expect (but ave not confirmed) that in the latter cases it's leaking refcounts (to the immortal "little integers"). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-05 06:25 Message: Logged In: YES user_id=80475 Committed as Modules/arraymodule.c 2.91 I don't recall any other changes from Py_ListGetItem to PySequence_GetItem but will scan for them this weekend. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-04 16:34 Message: Logged In: YES user_id=33168 Patch looks good to me. Do you know if there were any other changes from Py_ListGetItem to Py_SequenceGetItem? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-04 01:01 Message: Logged In: YES user_id=80475 Attaching a patch for a second review. The refcnt difference between Py_SequenceGetItem and Py_ListGetItem bit me in the behind. Added the DECREF where Neal suggested but used a regular DECREF instead of an XDECREF because it is preceded by a guard. The question then arose as to where the decreffing would affect the subsequent code, so I took another look at the two following sections. It appears to me (and I really could use a second confirmation on this) that the String and UniCode sections were unnecessarily recopying the initializer when the length was greater than zero. So, I changed the "if" to an "else if" to preclude the double copy and to resolve the question about the validity of the decref. Also, I added the NULL check for the getitem as Tim suggested. With the patch, all test cases (including Skip's test) and the OP's code run fine. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:32 Message: Logged In: YES user_id=44345 Sorry - thought I was saving Raymond about 30 seconds of work. I'll remember in the future. Also, I checked in a version with the required hasattr() check. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-03 18:21 Message: Logged In: YES user_id=31435 Neal, yup, that's the leak. PySequence_GetItem() either returns NULL or a new reference, and in the latter case the result must always be decrefed; PyList_GetItem() returned a borrowed reference (or NULL). The code should also check PySequence_GetItem() for an error (NULL) return, although the laziness of not checking for that was probably inherited from earlier code. Skip, tests that use a refcount-revealing function should be conditionalized on hasattr(sys, 'name_of_function'), to avoid creating headaches for Jython testing. You shouldn't check in failing tests independent of fixes: the intent is that someone getting a fresh checkout should never see a test failure. Leaving assigned to Raymond for now. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-03 18:02 Message: Logged In: YES user_id=44345 Added a test case to test_array.py (1.25) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-03 12:50 Message: Logged In: YES user_id=33168 I think the problem may be due to the change on line 1760 of arraymodule from PyList_GetItem (2.2) to PySequence_GetItem (2.3) in 2.88 by Raymond. Adding a Py_XDECREF(v) at line 1765 "fixes" the problem, but I don't think that's necessarily the correct solution for all types. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782369&group_id=5470 From noreply@sourceforge.net Tue Aug 5 12:52:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 04:52:44 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-778763 ] Optional type enforcement Message-ID: Feature Requests item #778763, was opened at 2003-07-28 01:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Perry (occupant4) Assigned to: Nobody/Anonymous (nobody) Summary: Optional type enforcement Initial Comment: One of the things that makes Python easy to code in is the fact that you don't have to explicitly declare the types of variables, or associate a specific type with a variable. However, this can potentially lead to somewhat confusing and hard-to-maintain code, not to mention make it easier to introduce bugs. An idea struck me that it might be possible to combine the power and safety of a strictly type-checked language with the speed and ease of coding of Python. Normal variables as they stand now would be unaffected by this feature, and retain their polymorphic type capabilities. Allow the programmer to optionally declare the type of a variable somehow, be it with the C-like syntax "int x", or Pascal's (I think?) "x: int", or a new syntactic representation. Python could then issue a TypeError if the program attempts to assign a non-int to x. Obviously this feature could apply to any data type, such as string, list, or perhaps user-defined classes. Class member variables can be declared as now in the class definition body, with the same syntax to specify a type, ie: class Test: int x = 5 string name = "test" untyped = None In addition, adding a type specifier to a function's parameters could serve another means of distinguishing it from other functions, which could allow function overloading, ie: def double(int x): return 2*x def double(string x): return x + ' ' + x Advantages: - clarifies the author's intention in writing code, and could help prevent confusion as to what type a variable/parameter is. - helps prevent bugs due to type mistakes - doesn't interfere with existing code or coding style, as dynamically typed variables are still allowed - could allow function overloading if it was wanted Disadvantages: - implementing a type checker could be difficult? - potentially pollutes namespace with extra keywords like 'string' or 'list'. may need to choose different keywords. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-05 06:52 Message: Logged In: YES user_id=80475 To make the most of polymorphism, interface checking would be preferable to enforcing specific types. For example, it is better to check that f is a filelike type rather than requiring that is actually be a file -- that way, StringIO objects can be substituted without breaking code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&group_id=5470 From noreply@sourceforge.net Tue Aug 5 14:46:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 06:46:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1,200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 12:17 Message generated for change (Comment added) made by drmalte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Malte John (drmalte) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- >Comment By: Malte John (drmalte) Date: 2003-08-05 13:46 Message: Logged In: YES user_id=834648 Hi, I pulled out the brand new version 1.24 wih reintroduced caching. Speedup is is about 400 times :) so it is only three times slower than the system strptime in my testloop ( ~6000 lines/s vs. 16200 lines/s ) Thanks a lot! Malte ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-04 16:36 Message: Logged In: YES user_id=357491 Raymond is talking about version 1.21 . That was the last version with caching. I realize that strptime is no longer a speed demon for those platforms that have a C version, but now everyone has a version that is consistent which I think is worth the slowdown. But there still might be hope for a speedup. There is a chance that I will be allowed to reintroduce the caching code for 2.3.1 . If that happens performance will pick up significantly. If not you will have to wait until 2.4 . ---------------------------------------------------------------------- Comment By: Malte John (drmalte) Date: 2003-08-03 17:45 Message: Logged In: YES user_id=834648 Thanks for the hint! I pulled out _strptimy.py Version 1.23 which is identical to the version in the Python-2.3.tgz I used. :( Here is the output of tar -ztvf ... -rw-rw-r-- barry/barry 20933 2003-07-24 22:02:28 Python-2.3/Lib/_strptime.py ... Regards Malte ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 08:53 Message: Logged In: YES user_id=80475 It would be interesting for you to pull down the CVS version from two weeks ago and re-run your timings. The caching code was removed at the end because it was a temporary suspect on a bug-hunt just days before the release. Note, the whole purpose of the pure python version was to avoid the non-portable differences between strptime() implementations on various target systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply@sourceforge.net Tue Aug 5 15:19:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 07:19:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-783528 ] Inconsistent results with super and __getattribute__ Message-ID: Bugs item #783528, was opened at 2003-08-05 14:19 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=783528&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gonçalo Rodrigues (grodr) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent results with super and __getattribute__ Initial Comment: Consider the following scenario of property overriding: >>> class Test(object): ... def __init__(self, n): ... self.__n = n ... #Properties. ... def __get_n(self): ... return self.__n ... def __set_n(self, n): ... self.__n = n ... n = property(__get_n, __set_n) ... >>> a = Test(42) >>> a.n 42 >>> a.n = 32 >>> a.n 32 Now, let us override the n property: >>> class Test2(Test): ... def __init__(self, n): ... super(Test2, self).__init__(n) ... #Properties. ... def __get_n(self): ... return "got ya!" ... def __set_n(self, value): ... print "No way, jose!" ... n = property(__get_n, __set_n) ... >>> a = Test2(42) >>> a.n 'got ya!' >>> a.n = 0 No way, jose! >>> a.n 'got ya!' >>> super(Test2, a).n 42 So far so good, super is working well with properties. But now consider the following inconsistencies: >>> super(Test2, a).__getattribute__('n') 'got ya!' >>> super(Test2, a).n 42 Also: >>> super(Test, Test2).__getattribute__('n') >>> super(Test, Test2).__getattribute__('n').__get__(a) 'got ya!' >>> super(Test, Test2).n Traceback (most recent call last): File "", line 1, in ? AttributeError: 'super' object has no attribute 'n' The last one is particularly damaging, because: >>> super(Test2, a).n = 32 Traceback (most recent call last): File "", line 1, in ? AttributeError: 'super' object has no attribute 'n' I think the above should work, but whatever’s the answer, together with the super(Test, Test2) odd results it does make impossible using super and setting properties together. Tested with the latest Python 2.3 in win2k. With my best regards, G. Rodrigues P.S: bug 729913 talks of similar issues at the end: super does not seem to intercept special methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783528&group_id=5470 From noreply@sourceforge.net Tue Aug 5 17:04:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 09:04:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 17:45 Message generated for change (Comment added) made by bernhard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 18:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. ---------------------------------------------------------------------- Comment By: Dani (asqui) Date: 2003-01-12 17:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply@sourceforge.net Tue Aug 5 19:22:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 11:22:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1,200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 05:17 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Malte John (drmalte) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-05 11:22 Message: Logged In: YES user_id=357491 That sounds reasonable considering you are having to go through the C API for the strings and I am using regexes instead of simple split-on-whitespace/compare parsing like strptime in C pushes for (perk is that Python's strptime can parse %Y%m%d since the separation of whitespace for items is not required). Now I just need to see if I should backport to 2.3.1 . ---------------------------------------------------------------------- Comment By: Malte John (drmalte) Date: 2003-08-05 06:46 Message: Logged In: YES user_id=834648 Hi, I pulled out the brand new version 1.24 wih reintroduced caching. Speedup is is about 400 times :) so it is only three times slower than the system strptime in my testloop ( ~6000 lines/s vs. 16200 lines/s ) Thanks a lot! Malte ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-04 09:36 Message: Logged In: YES user_id=357491 Raymond is talking about version 1.21 . That was the last version with caching. I realize that strptime is no longer a speed demon for those platforms that have a C version, but now everyone has a version that is consistent which I think is worth the slowdown. But there still might be hope for a speedup. There is a chance that I will be allowed to reintroduce the caching code for 2.3.1 . If that happens performance will pick up significantly. If not you will have to wait until 2.4 . ---------------------------------------------------------------------- Comment By: Malte John (drmalte) Date: 2003-08-03 10:45 Message: Logged In: YES user_id=834648 Thanks for the hint! I pulled out _strptimy.py Version 1.23 which is identical to the version in the Python-2.3.tgz I used. :( Here is the output of tar -ztvf ... -rw-rw-r-- barry/barry 20933 2003-07-24 22:02:28 Python-2.3/Lib/_strptime.py ... Regards Malte ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 01:53 Message: Logged In: YES user_id=80475 It would be interesting for you to pull down the CVS version from two weeks ago and re-run your timings. The caching code was removed at the end because it was a temporary suspect on a bug-hunt just days before the release. Note, the whole purpose of the pure python version was to avoid the non-portable differences between strptime() implementations on various target systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply@sourceforge.net Tue Aug 5 19:54:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 11:54:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-783348 ] UNIX-locale and repr() Message-ID: Bugs item #783348, was opened at 2003-08-05 00:55 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 >Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None >Priority: 3 Submitted By: Joerg Linnenkohl (jolinnen) Assigned to: Nobody/Anonymous (nobody) Summary: UNIX-locale and repr() Initial Comment: Hi, please look at this code snippet: #!/usr/bin/python import sys import os import random import locale locale.setlocale(locale.LC_ALL, 'de_DE@euro') dp = locale.localeconv().get('decimal_point', '.') # print "--->",locale.localeconv() print "--->",dp a = random.random() b = repr(a) print b with this output : ---> , 0.24851180874790457 I expect that the output of b must be "0,24851180874790457" with a "," as a decimal point corresponding to the locale. But for floating point numbers repr() always delivers the "." as decimal point for the german locale. The real problem occurs in the email package (http://mimelib.sourceforge.net/) in the method : def _make_boundary(text=None): # Craft a random boundary. If text is given, ensure that the chosen # boundary doesn't appear in the text. dp = locale.localeconv().get('decimal_point', '.') boundary = ('=' * 15) + repr(random.random()).split(dp)[1] + '==' for the german locale (error 'listindex out of range') on repr(random.random()).split(dp)[1]. Kind regards Jörg Linnenkohl ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-05 11:54 Message: Logged In: YES user_id=357491 This is a known issue. Python requires that LC_NUMERIC for locale settings *always* be set to the "C" locale. This is so that numeric values stored in .pyc files can be converted with no issue from their string representation to the proper Python object. This was all recently discussed on python-dev; see the python-dev Summary for July 2003 when it comes out (by the end of the week) for a summary of the issue and discussion. So the code in the email package is wrong for thinking repr will return anything that uses something other than a period for a decimal point. Since this is a 2.1.x issue (changed in 2.2.x branch) I am lowering the priority on this. Or should this just be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 From noreply@sourceforge.net Tue Aug 5 20:19:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 12:19:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 01:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply@sourceforge.net Tue Aug 5 20:22:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 12:22:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 01:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply@sourceforge.net Tue Aug 5 21:35:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 13:35:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-783312 ] Serious mem leak in socket module Message-ID: Bugs item #783312, was opened at 2003-08-05 06:13 Message generated for change (Comment added) made by gottfried You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Nobody/Anonymous (nobody) Summary: Serious mem leak in socket module Initial Comment: There are memory leaks in Python 2.3's socketmodule.c:getsockaddrarg function. In the AF_INET clause of that function's switch, the PyArg_ParseTuple format was changed from "si:getsockaddrarg" in 2.2 to "eti:getsockaddrarg" in 2.3; in the AF_INET6 clause, the format was changed from "si|ii" in 2.2 to "eti|ii" in 2.3. The memory leak occurs because the "s" extractor did not allocate any memory that needed to be manually freed, whereas "et" does, yet no provision was added to free the newly allocated memory. Looks like this bug was introduced in CVS revision 1.259: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/socketmodule.c.diff?r1=1.258&r2=1.259 I've attached a test program that demonstrates the leak, plus a patch to socketmodule.c in unified diff format. To me, this leak seems serious because it affects virtually every Python program that uses the socket module (getsockaddrarg is called by the socket.socket methods bind, connect, connect_ex, and sendto). ---------------------------------------------------------------------- Comment By: Gottfried Stauffenberg (gottfried) Date: 2003-08-05 20:35 Message: Logged In: YES user_id=838410 Since I have installed Python 2.3 Final (on Windows XP Professional) I have got a serious problem in my data uploading scripts to a SAP 7.4 Database on a different server. Python crashes with no traceback available and Windows notifies me of an serious program crash. The amount of data being send before the crash is variable, it can be anything between 100KB and 508KB of SQL INSERT statements (according to my application log file). I am not sure if the memory leak causes the program to crash, however this might be a possible explanation There had been no problems in 2.2.3. with about 300 MB of sql statements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 From noreply@sourceforge.net Tue Aug 5 22:59:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 14:59:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-783789 ] SIGSEGV in _sre.c (IRIX 6.5.20) Message-ID: Bugs item #783789, was opened at 2003-08-05 14: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=783789&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Fredrik Lundh (effbot) Summary: SIGSEGV in _sre.c (IRIX 6.5.20) Initial Comment: Under IRIX (6.5.20) Python 2.3 (final) crashes with a core dump while executing a SCons job (www.scons.org). I've recompiled Python with -g but the behavior is the same. Here is the beginning of the dbx stack trace: dbx version 7.3 MR 55458_Apr30_MR Apr 30 1999 13:44:41 dbx Warning: Unknown processor type 0xe, assuming this is not an R8000 Core from signal SIGSEGV: Segmentation violation (dbx) where > 0 mark_save(state = , lo = , hi = 0, mark_stack_base = (nil)) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":289, 0x10107bc4] 1 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 669) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":979, 0x10109d74] 2 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 668) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 3 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 667) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 4 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 666) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 5 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 665) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 6 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 664) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] The alternation of _sre.c:991, _sre.c:1263 continues to the end of the dbx output which stops at 99; the value of level is decreasing monotonously. To reproduce upload this file to an IRIX machine: http://cci.lbl.gov/cctbx_build/send_octet_stream.cgi? source=results/2003_08_04_2056/cctbx_python_23_ bundle.selfx In a new, empty directory enter the command: perl cctbx_python_23_bundle.selfx When prompted enter the number of available CPU's and wait for the Python 2.3 installation to finish (log is in the file py_install_log). The newly compiled Python is used to start a SCons build procedure. The crash occurs a few files into the process of compiling C++ sources. I've tried the exact same source code under Redhat 8.0. There it finishes without a crash. Therefore I am thinking you will need an IRIX machine to reproduce the crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 From noreply@sourceforge.net Tue Aug 5 23:31:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 15:31:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-783801 ] tell me again how to build statically linked modules? Message-ID: Bugs item #783801, was opened at 2003-08-05 22: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=783801&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: tell me again how to build statically linked modules? Initial Comment: I need to statically link a C module into Python. I read this doc: http://www.python.org/doc/current/ext/compilation.html And followed the very simple instructions of editing Modules/Setup.local and running "make", but it didn't work. I know it didn't work, because first I ran "make" while the .c file was missing, and there was no complaint nor any mention of my module in the output, and then I ran make after the .c file had been cp'ed into place, and make seemed to exit without compiling anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783801&group_id=5470 From noreply@sourceforge.net Wed Aug 6 03:04:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 19:04:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-783789 ] SIGSEGV in _sre.c (IRIX 6.5.20) Message-ID: Bugs item #783789, was opened at 2003-08-05 14:59 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Fredrik Lundh (effbot) Summary: SIGSEGV in _sre.c (IRIX 6.5.20) Initial Comment: Under IRIX (6.5.20) Python 2.3 (final) crashes with a core dump while executing a SCons job (www.scons.org). I've recompiled Python with -g but the behavior is the same. Here is the beginning of the dbx stack trace: dbx version 7.3 MR 55458_Apr30_MR Apr 30 1999 13:44:41 dbx Warning: Unknown processor type 0xe, assuming this is not an R8000 Core from signal SIGSEGV: Segmentation violation (dbx) where > 0 mark_save(state = , lo = , hi = 0, mark_stack_base = (nil)) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":289, 0x10107bc4] 1 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 669) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":979, 0x10109d74] 2 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 668) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 3 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 667) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 4 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 666) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 5 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 665) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 6 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 664) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] The alternation of _sre.c:991, _sre.c:1263 continues to the end of the dbx output which stops at 99; the value of level is decreasing monotonously. To reproduce upload this file to an IRIX machine: http://cci.lbl.gov/cctbx_build/send_octet_stream.cgi? source=results/2003_08_04_2056/cctbx_python_23_ bundle.selfx In a new, empty directory enter the command: perl cctbx_python_23_bundle.selfx When prompted enter the number of available CPU's and wait for the Python 2.3 installation to finish (log is in the file py_install_log). The newly compiled Python is used to start a SCons build procedure. The crash occurs a few files into the process of compiling C++ sources. I've tried the exact same source code under Redhat 8.0. There it finishes without a crash. Therefore I am thinking you will need an IRIX machine to reproduce the crash. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-05 19:04 Message: Logged In: YES user_id=71407 An additional piece of information: I observe the crashes (reproducibly) only when using SCons' -j option for parallel builds, using multiple CPU's. I believe the -j option involves the threading module. If I run the build using only one CPU it finishes without a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 From noreply@sourceforge.net Wed Aug 6 03:45:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 19:45:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-783882 ] os.lstat crashes with Unicode filename Message-ID: Bugs item #783882, was opened at 2003-08-06 12:45 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=783882&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: os.lstat crashes with Unicode filename Initial Comment: As seen on c.l.py. I'll check a patch into both the trunk and the 2.3 maint branch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783882&group_id=5470 From noreply@sourceforge.net Wed Aug 6 03:49:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 19:49:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-783882 ] os.lstat crashes with Unicode filename Message-ID: Bugs item #783882, was opened at 2003-08-06 12:45 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783882&group_id=5470 Category: Windows Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: os.lstat crashes with Unicode filename Initial Comment: As seen on c.l.py. I'll check a patch into both the trunk and the 2.3 maint branch ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-08-06 12:49 Message: Logged In: YES user_id=14198 Checked in on the trunk: Checking in Modules/posixmodule.c; new revision: 2.301; previous revision: 2.300 Checking in Lib/test/test_unicode_file.py; new revision: 1.10; previous revision: 1.9 On 2.3 maint branch: Checking in Modules/posixmodule.c; new revision: 2.300.8.1; previous revision: 2.300 Checking in Lib/test/test_unicode_file.py; new revision: 1.9.10.1; previous revision: 1.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783882&group_id=5470 From noreply@sourceforge.net Wed Aug 6 04:00:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 20:00:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work Message-ID: Bugs item #783887, was opened at 2003-08-05 20:00 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=783887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andy Huibers (ahuibers) Assigned to: Nobody/Anonymous (nobody) Summary: Tab / Space Configuration Does Not Work Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply@sourceforge.net Wed Aug 6 04:00:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 20:00:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE Message-ID: Bugs item #783887, was opened at 2003-08-05 20:00 Message generated for change (Settings changed) made by ahuibers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andy Huibers (ahuibers) Assigned to: Nobody/Anonymous (nobody) >Summary: Tab / Space Configuration Does Not Work in IDLE Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply@sourceforge.net Wed Aug 6 06:17:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 22:17:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE Message-ID: Bugs item #783887, was opened at 2003-08-05 22:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andy Huibers (ahuibers) Assigned to: Nobody/Anonymous (nobody) Summary: Tab / Space Configuration Does Not Work in IDLE Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 00:17 Message: Logged In: YES user_id=80475 I cannot reproduce the problem. This may be a silly question, but did you click Apply after changing the setting? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply@sourceforge.net Wed Aug 6 06:56:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 22:56:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-783312 ] Serious mem leak in socket module Message-ID: Bugs item #783312, was opened at 2003-08-05 01:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Rushby (woodsplitter) >Assigned to: Martin v. Löwis (loewis) Summary: Serious mem leak in socket module Initial Comment: There are memory leaks in Python 2.3's socketmodule.c:getsockaddrarg function. In the AF_INET clause of that function's switch, the PyArg_ParseTuple format was changed from "si:getsockaddrarg" in 2.2 to "eti:getsockaddrarg" in 2.3; in the AF_INET6 clause, the format was changed from "si|ii" in 2.2 to "eti|ii" in 2.3. The memory leak occurs because the "s" extractor did not allocate any memory that needed to be manually freed, whereas "et" does, yet no provision was added to free the newly allocated memory. Looks like this bug was introduced in CVS revision 1.259: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/socketmodule.c.diff?r1=1.258&r2=1.259 I've attached a test program that demonstrates the leak, plus a patch to socketmodule.c in unified diff format. To me, this leak seems serious because it affects virtually every Python program that uses the socket module (getsockaddrarg is called by the socket.socket methods bind, connect, connect_ex, and sendto). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 00:56 Message: Logged In: YES user_id=80475 This was Martin's change (adding IDNA support). Assigning to him to approve your patch. ---------------------------------------------------------------------- Comment By: Gottfried Stauffenberg (gottfried) Date: 2003-08-05 15:35 Message: Logged In: YES user_id=838410 Since I have installed Python 2.3 Final (on Windows XP Professional) I have got a serious problem in my data uploading scripts to a SAP 7.4 Database on a different server. Python crashes with no traceback available and Windows notifies me of an serious program crash. The amount of data being send before the crash is variable, it can be anything between 100KB and 508KB of SQL INSERT statements (according to my application log file). I am not sure if the memory leak causes the program to crash, however this might be a possible explanation There had been no problems in 2.2.3. with about 300 MB of sql statements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 From noreply@sourceforge.net Wed Aug 6 07:08:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 23:08:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-06 16:08 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=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Nobody/Anonymous (nobody) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply@sourceforge.net Wed Aug 6 07:50:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 05 Aug 2003 23:50:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-783348 ] UNIX-locale and repr() Message-ID: Bugs item #783348, was opened at 2003-08-05 09:55 Message generated for change (Comment added) made by jolinnen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None Priority: 3 Submitted By: Joerg Linnenkohl (jolinnen) Assigned to: Nobody/Anonymous (nobody) Summary: UNIX-locale and repr() Initial Comment: Hi, please look at this code snippet: #!/usr/bin/python import sys import os import random import locale locale.setlocale(locale.LC_ALL, 'de_DE@euro') dp = locale.localeconv().get('decimal_point', '.') # print "--->",locale.localeconv() print "--->",dp a = random.random() b = repr(a) print b with this output : ---> , 0.24851180874790457 I expect that the output of b must be "0,24851180874790457" with a "," as a decimal point corresponding to the locale. But for floating point numbers repr() always delivers the "." as decimal point for the german locale. The real problem occurs in the email package (http://mimelib.sourceforge.net/) in the method : def _make_boundary(text=None): # Craft a random boundary. If text is given, ensure that the chosen # boundary doesn't appear in the text. dp = locale.localeconv().get('decimal_point', '.') boundary = ('=' * 15) + repr(random.random()).split(dp)[1] + '==' for the german locale (error 'listindex out of range') on repr(random.random()).split(dp)[1]. Kind regards Jörg Linnenkohl ---------------------------------------------------------------------- >Comment By: Joerg Linnenkohl (jolinnen) Date: 2003-08-06 08:50 Message: Logged In: YES user_id=837832 The problem is that we use the stuff together with Zope, therefore we have to use v.2.1.3. But I have a workaround so for me it's okay to close it. Thank you. Best regards Jörg ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 20:54 Message: Logged In: YES user_id=357491 This is a known issue. Python requires that LC_NUMERIC for locale settings *always* be set to the "C" locale. This is so that numeric values stored in .pyc files can be converted with no issue from their string representation to the proper Python object. This was all recently discussed on python-dev; see the python-dev Summary for July 2003 when it comes out (by the end of the week) for a summary of the issue and discussion. So the code in the email package is wrong for thinking repr will return anything that uses something other than a period for a decimal point. Since this is a 2.1.x issue (changed in 2.2.x branch) I am lowering the priority on this. Or should this just be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 From noreply@sourceforge.net Wed Aug 6 08:17:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 00:17:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-783990 ] test_re failure on 64bit targets (alpha, ia64) Message-ID: Bugs item #783990, was opened at 2003-08-06 07: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=783990&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fredrik Lundh (effbot) Summary: test_re failure on 64bit targets (alpha, ia64) Initial Comment: test test_re failed -- Traceback (most recent call last): File "/home/doko/py/python2.3-2.3/Lib/test/test_re.py", line 283, in test_bigcharset u"\u2222").group(1), u"\u2222") AttributeError: 'NoneType' object has no attribute 'group' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 From noreply@sourceforge.net Wed Aug 6 08:18:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 00:18:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-783990 ] test_re failure on 64bit targets (alpha, ia64) Message-ID: Bugs item #783990, was opened at 2003-08-06 07:17 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Fredrik Lundh (effbot) Summary: test_re failure on 64bit targets (alpha, ia64) Initial Comment: test test_re failed -- Traceback (most recent call last): File "/home/doko/py/python2.3-2.3/Lib/test/test_re.py", line 283, in test_bigcharset u"\u2222").group(1), u"\u2222") AttributeError: 'NoneType' object has no attribute 'group' ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-08-06 07:18 Message: Logged In: YES user_id=60903 this should be alpha-linux, ia64-linux, didn't test any other OS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783990&group_id=5470 From noreply@sourceforge.net Wed Aug 6 08:23:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 00:23:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-782752 ] ImportError: cannot import name __all__ Message-ID: Bugs item #782752, was opened at 2003-08-04 14:07 Message generated for change (Comment added) made by ikruusa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782752&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Indrek Kruusa (ikruusa) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: cannot import name __all__ Initial Comment: in module fnmatch.py: from sre import __all__ ---------------------------------------------------------------------- >Comment By: Indrek Kruusa (ikruusa) Date: 2003-08-06 10:23 Message: Logged In: YES user_id=835078 I found a reason for this anomaly and all others too with my Python 2.3- before compiling I did 'export OPT=$CFLAGS' and among other things my CFLAGS contained also '-fomit-frame pointer -malign-double'. With these the 'make test' will fail right at the beginning. (platform - RH 9.0, gcc 3.2.2). Sorry if this case about CFLAGS is in FAQ or in manual somewhere :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-04 21:02 Message: Logged In: YES user_id=33168 The only "from sre import __all__" is in re.py, not fnmatch.py. If this is failing it is probably because Modules/sre.c failed to compile. You can try starting python with -v to see more about imports. There's not enough information to know what's going on. What platform is this on? Did sre.c compile? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782752&group_id=5470 From noreply@sourceforge.net Wed Aug 6 10:07:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 02:07:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-784031 ] Byte-order bug in socket-module getaddrinfo.c Message-ID: Bugs item #784031, was opened at 2003-08-06 12:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784031&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tuomo Hyyrylainen (therry) Assigned to: Nobody/Anonymous (nobody) Summary: Byte-order bug in socket-module getaddrinfo.c Initial Comment: It seems to me that there is a byte-order bug in Modules/getaddrinfo.c, in function getaddrinfo. On line 415 inet_pton is called, and that is supposed to return IPv4 address in network byte order. So the code below in case block (AF_INET) does not work correctly on little-endian platforms. I would propose adding line v4a = ntohl(v4a); between current lines 423 and 424. -- Tuomo Hyyrylainen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784031&group_id=5470 From noreply@sourceforge.net Wed Aug 6 11:25:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 03:25:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-784075 ] Fatal Python error: unknown scope Message-ID: Bugs item #784075, was opened at 2003-08-06 12:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: unknown scope Initial Comment: The code: def g(a=None, b, c=lambda: None): g Python 2.3/Win98, confirmed in current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 From noreply@sourceforge.net Wed Aug 6 11:38:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 03:38:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-784075 ] Fatal Python error: unknown scope Message-ID: Bugs item #784075, was opened at 2003-08-06 11:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: unknown scope Initial Comment: The code: def g(a=None, b, c=lambda: None): g Python 2.3/Win98, confirmed in current CVS. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-06 11:38 Message: Logged In: YES user_id=6656 Ouch. Probably the best thing to do is check for "non-default argument follows default argument" *before* doing the symtable thing. The relavent code is confusing, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 From noreply@sourceforge.net Wed Aug 6 12:30:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 04:30:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-784115 ] compile error mod_python, 4Suite Tru64 Message-ID: Bugs item #784115, was opened at 2003-08-06 13:30 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=784115&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Mueller (muellergm4t9) Assigned to: Nobody/Anonymous (nobody) Summary: compile error mod_python, 4Suite Tru64 Initial Comment: the compilation of both modules give me the same errors with use of python 2.3 (compilation with python 2.2 without errors) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784115&group_id=5470 From noreply@sourceforge.net Wed Aug 6 13:33:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 05:33:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-784075 ] Fatal Python error: unknown scope Message-ID: Bugs item #784075, was opened at 2003-08-06 11:25 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) >Assigned to: Jeremy Hylton (jhylton) Summary: Fatal Python error: unknown scope Initial Comment: The code: def g(a=None, b, c=lambda: None): g Python 2.3/Win98, confirmed in current CVS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-06 11:38 Message: Logged In: YES user_id=6656 Ouch. Probably the best thing to do is check for "non-default argument follows default argument" *before* doing the symtable thing. The relavent code is confusing, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 From noreply@sourceforge.net Wed Aug 6 13:34:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 05:34:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-784075 ] Fatal Python error: unknown scope Message-ID: Bugs item #784075, was opened at 2003-08-06 11:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marel Baczynski (imbaczek) Assigned to: Jeremy Hylton (jhylton) Summary: Fatal Python error: unknown scope Initial Comment: The code: def g(a=None, b, c=lambda: None): g Python 2.3/Win98, confirmed in current CVS. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-06 13:34 Message: Logged In: YES user_id=6656 No, hang on, I meant to attach my fix before doing that. This code cannot possibly die soon enough. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-06 11:38 Message: Logged In: YES user_id=6656 Ouch. Probably the best thing to do is check for "non-default argument follows default argument" *before* doing the symtable thing. The relavent code is confusing, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784075&group_id=5470 From noreply@sourceforge.net Wed Aug 6 13:40:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 05:40:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-784115 ] compile error mod_python, 4Suite Tru64 Message-ID: Bugs item #784115, was opened at 2003-08-06 12:30 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784115&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Mueller (muellergm4t9) Assigned to: Nobody/Anonymous (nobody) Summary: compile error mod_python, 4Suite Tru64 Initial Comment: the compilation of both modules give me the same errors with use of python 2.3 (compilation with python 2.2 without errors) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-08-06 13:40 Message: Logged In: YES user_id=6656 I notice mod_python.h violates the documented rule that Python.h must be included before any system headers. This is probably something horrendous to do with large file support (the horrendous-ness isn't Python's fault, AFAIK). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784115&group_id=5470 From noreply@sourceforge.net Wed Aug 6 13:55:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 05:55:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-06 02:08 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) >Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply@sourceforge.net Wed Aug 6 14:31:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 06:31:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-784115 ] compile error mod_python, 4Suite Tru64 Message-ID: Bugs item #784115, was opened at 2003-08-06 13:30 Message generated for change (Settings changed) made by muellergm4t9 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784115&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Gottfried Mueller (muellergm4t9) Assigned to: Nobody/Anonymous (nobody) Summary: compile error mod_python, 4Suite Tru64 Initial Comment: the compilation of both modules give me the same errors with use of python 2.3 (compilation with python 2.2 without errors) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-08-06 14:40 Message: Logged In: YES user_id=6656 I notice mod_python.h violates the documented rule that Python.h must be included before any system headers. This is probably something horrendous to do with large file support (the horrendous-ness isn't Python's fault, AFAIK). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784115&group_id=5470 From noreply@sourceforge.net Wed Aug 6 14:39:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 06:39:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-784183 ] IDLE does not start for 2.3 on windows. Message-ID: Bugs item #784183, was opened at 2003-08-06 09: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=784183&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE does not start for 2.3 on windows. Initial Comment: For Python 2.3 installed on Windows (well, Windows 2000 anyway, I haven't tested others), a space in the pathname will create an shortcut to IDLE that does not work. To demonstrate the problem: get a fresh Windows 2000 system. Run the Python 2.3 installer. Select "C:/Program Files/Python23" as the install directory. Use default selections for all other installer options. After install, go to Programs menu, select "Python 2.3" > "IDLE (Python GUI)". It will launch a pythonw process, but nothing will appear on the screen. The problem appears to be the space in the pathname. If you create a shortcut with the path spelled out in full (long names not 8-char abreviations) and with quotes around the pathnames that contain spaces, that shortcut will work. I'm not sure what the fix is, but regretably lots of people have Windows and many of them put their applications in "Program Files". In addition to a patch, we should probably put this in a Known Bugs list somewhere where newbies will find it (where is that?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 From noreply@sourceforge.net Wed Aug 6 15:52:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 07:52:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-779973 ] Missing DEFS in Makefile.pre.in breakage Message-ID: Bugs item #779973, was opened at 2003-07-30 03:46 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779973&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Nobody/Anonymous (nobody) Summary: Missing DEFS in Makefile.pre.in breakage Initial Comment: DEFS= is missing from the top-level Makefile.pre.in in Python 2.3 final. This causes quite a few older distutils C extension packages that rely on the presence of DEFS to break, e.g. DCOracle2-1.1 or python-ldap 1.10alpha3. This is because they include @DEFS@ on the command-line, which causes gcc to barf with a message saying -c and -o are incompatible for multiple compilations. The following patch remedies this: *** Makefile.pre.in~ Sun Jul 13 03:10:42 2003 --- Makefile.pre.in Tue Jul 29 18:23:22 2003 *************** *** 55,60 **** --- 55,61 ---- # Compiler options OPT= @OPT@ BASECFLAGS= @BASECFLAGS@ + DEFS= $(BASECFLAGS) CFLAGS= $(BASECFLAGS) $(OPT) CPPFLAGS= -I. -I$(srcdir)/Include LDFLAGS= @LDFLAGS@ (I am not sure if BASECFLAGS is a strict equivalent for DEFS, though). Platform: Solaris 8 MU7 x/86 Compiler: gcc-2.95.3 ---------------------------------------------------------------------- Comment By: Michal Čihař (nijel) Date: 2003-08-06 16:52 Message: Logged In: YES user_id=192186 JFYI: patch #736417 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779973&group_id=5470 From noreply@sourceforge.net Wed Aug 6 16:17:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 08:17:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-783801 ] tell me again how to build statically linked modules? Message-ID: Bugs item #783801, was opened at 2003-08-05 22:31 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783801&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: tell me again how to build statically linked modules? Initial Comment: I need to statically link a C module into Python. I read this doc: http://www.python.org/doc/current/ext/compilation.html And followed the very simple instructions of editing Modules/Setup.local and running "make", but it didn't work. I know it didn't work, because first I ran "make" while the .c file was missing, and there was no complaint nor any mention of my module in the output, and then I ran make after the .c file had been cp'ed into place, and make seemed to exit without compiling anything. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-08-06 15:17 Message: Logged In: YES user_id=52562 Err-- there has clearly been some pilot error here. Because when I do this same experiment today I get different results. More in a minute, assuming sf.net stays up that long... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783801&group_id=5470 From noreply@sourceforge.net Wed Aug 6 17:24:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 09:24:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-783801 ] tell me again how to build statically linked modules? Message-ID: Bugs item #783801, was opened at 2003-08-05 22:31 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783801&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Deleted >Resolution: Works For Me Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: tell me again how to build statically linked modules? Initial Comment: I need to statically link a C module into Python. I read this doc: http://www.python.org/doc/current/ext/compilation.html And followed the very simple instructions of editing Modules/Setup.local and running "make", but it didn't work. I know it didn't work, because first I ran "make" while the .c file was missing, and there was no complaint nor any mention of my module in the output, and then I ran make after the .c file had been cp'ed into place, and make seemed to exit without compiling anything. ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-08-06 16:24 Message: Logged In: YES user_id=52562 Forget it. It works very nicely. I will now attempt to delete this bug tracker entry in order to hide the evidence of my error, but unfortunately sf.net will tell me that I don't have sufficient authorization to do so... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-08-06 15:17 Message: Logged In: YES user_id=52562 Err-- there has clearly been some pilot error here. Because when I do this same experiment today I get different results. More in a minute, assuming sf.net stays up that long... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783801&group_id=5470 From noreply@sourceforge.net Wed Aug 6 20:05:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 12:05:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-05 23:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-06 12:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply@sourceforge.net Wed Aug 6 20:09:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 12:09:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE Message-ID: Bugs item #783887, was opened at 2003-08-05 20:00 Message generated for change (Comment added) made by ahuibers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 2 Submitted By: Andy Huibers (ahuibers) Assigned to: Nobody/Anonymous (nobody) Summary: Tab / Space Configuration Does Not Work in IDLE Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- >Comment By: Andy Huibers (ahuibers) Date: 2003-08-06 12:09 Message: Logged In: YES user_id=838612 Mmm.. I re-installed the Windows Python-2.3 installer EXE on a fresh PC and I have the problem, even when I hit "Apply" and "OK". It is not a big deal of course, but would be nice if it worked.. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-05 22:17 Message: Logged In: YES user_id=80475 I cannot reproduce the problem. This may be a silly question, but did you click Apply after changing the setting? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply@sourceforge.net Wed Aug 6 20:33:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 06 Aug 2003 12:33:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-783348 ] UNIX-locale and repr() Message-ID: Bugs item #783348, was opened at 2003-08-05 09:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 Category: Python Library Group: Python 2.1.2 >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Joerg Linnenkohl (jolinnen) Assigned to: Nobody/Anonymous (nobody) Summary: UNIX-locale and repr() Initial Comment: Hi, please look at this code snippet: #!/usr/bin/python import sys import os import random import locale locale.setlocale(locale.LC_ALL, 'de_DE@euro') dp = locale.localeconv().get('decimal_point', '.') # print "--->",locale.localeconv() print "--->",dp a = random.random() b = repr(a) print b with this output : ---> , 0.24851180874790457 I expect that the output of b must be "0,24851180874790457" with a "," as a decimal point corresponding to the locale. But for floating point numbers repr() always delivers the "." as decimal point for the german locale. The real problem occurs in the email package (http://mimelib.sourceforge.net/) in the method : def _make_boundary(text=None): # Craft a random boundary. If text is given, ensure that the chosen # boundary doesn't appear in the text. dp = locale.localeconv().get('decimal_point', '.') boundary = ('=' * 15) + repr(random.random()).split(dp)[1] + '==' for the german locale (error 'listindex out of range') on repr(random.random()).split(dp)[1]. Kind regards Jörg Linnenkohl ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-08-06 21:33 Message: Logged In: YES user_id=21627 There is no bug whatsoever here. repr, %, and other "standard" number formatting operations always use the C locale. Use locale.{atof, str, atoi, format} for locale-aware formatting operations. ---------------------------------------------------------------------- Comment By: Joerg Linnenkohl (jolinnen) Date: 2003-08-06 08:50 Message: Logged In: YES user_id=837832 The problem is that we use the stuff together with Zope, therefore we have to use v.2.1.3. But I have a workaround so for me it's okay to close it. Thank you. Best regards Jörg ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 20:54 Message: Logged In: YES user_id=357491 This is a known issue. Python requires that LC_NUMERIC for locale settings *always* be set to the "C" locale. This is so that numeric values stored in .pyc files can be converted with no issue from their string representation to the proper Python object. This was all recently discussed on python-dev; see the python-dev Summary for July 2003 when it comes out (by the end of the week) for a summary of the issue and discussion. So the code in the email package is wrong for thinking repr will return anything that uses something other than a period for a decimal point. Since this is a 2.1.x issue (changed in 2.2.x branch) I am lowering the priority on this. Or should this just be closed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783348&group_id=5470 From noreply at sourceforge.net Wed Aug 6 16:51:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 18:51:18 2003 Subject: [Python-bugs-list] [ python-Bugs-784443 ] test_resource failure on m68k-linux Message-ID: Bugs item #784443, was opened at 2003-08-06 22:51 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=784443&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: test_resource failure on m68k-linux Initial Comment: there's one test failing on m68k-linux, which succeeds on all other (linux) archs: test_repr /home/doko/py/python2.3-2.3/Lib/test/test_repr.py:91: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up eq(r(i3), (""%id(i3))) test_resource test test_resource produced unexpected output: ********************************************************************** *** mismatch between line 2 of expected output and line 2 of actual output: - True + False ********************************************************************** ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784443&group_id=5470 From noreply at sourceforge.net Wed Aug 6 17:07:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 19:07:25 2003 Subject: [Python-bugs-list] [ python-Bugs-784449 ] obsolete or not installed config files in idlelib Message-ID: Bugs item #784449, was opened at 2003-08-06 23: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=784449&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: obsolete or not installed config files in idlelib Initial Comment: The files config-unix.txt config-win.txt config.txt in idlelib aren't installed anymore, but are still included in the distribution. Are they obsolete or not installed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784449&group_id=5470 From noreply at sourceforge.net Wed Aug 6 19:19:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 21:19:19 2003 Subject: [Python-bugs-list] [ python-Bugs-784509 ] interpret string argument as filename Message-ID: Bugs item #784509, was opened at 2003-08-06 18:19 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=784509&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784509&group_id=5470 From noreply at sourceforge.net Wed Aug 6 21:37:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 6 23:37:44 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 21:19 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Wed Aug 6 23:01:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 01:01:31 2003 Subject: [Python-bugs-list] [ python-Bugs-783887 ] Tab / Space Configuration Does Not Work in IDLE Message-ID: Bugs item #783887, was opened at 2003-08-05 22:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 2 Submitted By: Andy Huibers (ahuibers) >Assigned to: Kurt B. Kaiser (kbk) Summary: Tab / Space Configuration Does Not Work in IDLE Initial Comment: On Python 2.3/IDLE 1.0, when I go from the editor to: Options->Configure Idle->Font/Tabs And set it to "Tab key inserts tabs" what actually happens is that the tab key inserts spaces (4 spaces). ---------------------------------------------------------------------- Comment By: Andy Huibers (ahuibers) Date: 2003-08-06 14:09 Message: Logged In: YES user_id=838612 Mmm.. I re-installed the Windows Python-2.3 installer EXE on a fresh PC and I have the problem, even when I hit "Apply" and "OK". It is not a big deal of course, but would be nice if it worked.. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 00:17 Message: Logged In: YES user_id=80475 I cannot reproduce the problem. This may be a silly question, but did you click Apply after changing the setting? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783887&group_id=5470 From noreply at sourceforge.net Thu Aug 7 05:57:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 07:57:44 2003 Subject: [Python-bugs-list] [ python-Bugs-783312 ] Serious mem leak in socket module Message-ID: Bugs item #783312, was opened at 2003-08-05 08:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Martin v. L?wis (loewis) Summary: Serious mem leak in socket module Initial Comment: There are memory leaks in Python 2.3's socketmodule.c:getsockaddrarg function. In the AF_INET clause of that function's switch, the PyArg_ParseTuple format was changed from "si:getsockaddrarg" in 2.2 to "eti:getsockaddrarg" in 2.3; in the AF_INET6 clause, the format was changed from "si|ii" in 2.2 to "eti|ii" in 2.3. The memory leak occurs because the "s" extractor did not allocate any memory that needed to be manually freed, whereas "et" does, yet no provision was added to free the newly allocated memory. Looks like this bug was introduced in CVS revision 1.259: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/socketmodule.c.diff?r1=1.258&r2=1.259 I've attached a test program that demonstrates the leak, plus a patch to socketmodule.c in unified diff format. To me, this leak seems serious because it affects virtually every Python program that uses the socket module (getsockaddrarg is called by the socket.socket methods bind, connect, connect_ex, and sendto). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-07 13:57 Message: Logged In: YES user_id=21627 Thanks for the report. I have applied a similar patch, in socketmodule.c 1.273 and 1.271.6.2, NEWS 1.831.4.9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 07:56 Message: Logged In: YES user_id=80475 This was Martin's change (adding IDNA support). Assigning to him to approve your patch. ---------------------------------------------------------------------- Comment By: Gottfried Stauffenberg (gottfried) Date: 2003-08-05 22:35 Message: Logged In: YES user_id=838410 Since I have installed Python 2.3 Final (on Windows XP Professional) I have got a serious problem in my data uploading scripts to a SAP 7.4 Database on a different server. Python crashes with no traceback available and Windows notifies me of an serious program crash. The amount of data being send before the crash is variable, it can be anything between 100KB and 508KB of SQL INSERT statements (according to my application log file). I am not sure if the memory leak causes the program to crash, however this might be a possible explanation There had been no problems in 2.2.3. with about 300 MB of sql statements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 From noreply at sourceforge.net Thu Aug 7 06:02:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 08:02:32 2003 Subject: [Python-bugs-list] [ python-Bugs-784449 ] obsolete or not installed config files in idlelib Message-ID: Bugs item #784449, was opened at 2003-08-07 01:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784449&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: obsolete or not installed config files in idlelib Initial Comment: The files config-unix.txt config-win.txt config.txt in idlelib aren't installed anymore, but are still included in the distribution. Are they obsolete or not installed? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-07 14:02 Message: Logged In: YES user_id=21627 Where did you find these files? I can't find them anywhere in Python-2.3.tgz. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784449&group_id=5470 From noreply at sourceforge.net Thu Aug 7 06:03:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 08:03:42 2003 Subject: [Python-bugs-list] [ python-Bugs-784443 ] test_repr failure on m68k-linux Message-ID: Bugs item #784443, was opened at 2003-08-07 00:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784443&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) >Summary: test_repr failure on m68k-linux Initial Comment: there's one test failing on m68k-linux, which succeeds on all other (linux) archs: test_repr /home/doko/py/python2.3-2.3/Lib/test/test_repr.py:91: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up eq(r(i3), (""%id(i3))) test_resource test test_resource produced unexpected output: ********************************************************************** *** mismatch between line 2 of expected output and line 2 of actual output: - True + False ********************************************************************** ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-07 14:03 Message: Logged In: YES user_id=21627 Can you run the test separately, and report the two strings? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784443&group_id=5470 From noreply at sourceforge.net Thu Aug 7 08:01:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 10:01:51 2003 Subject: [Python-bugs-list] [ python-Bugs-784786 ] ImportError: cannot import name OptionParser Message-ID: Bugs item #784786, was opened at 2003-08-07 22:01 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=784786&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lu Jian Xiong (fdmulti) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: cannot import name OptionParser Initial Comment: E:\>optparse.py Traceback (most recent call last): File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py from optparse import OptionParser E:\>type optparse.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ****************************************** ********************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************** ********************** IDLE 1.0 >>> from optparse import OptionParser >>> # ok? why? >>> E:\> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 From noreply at sourceforge.net Thu Aug 7 08:22:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 10:22:36 2003 Subject: [Python-bugs-list] [ python-Bugs-784786 ] ImportError: cannot import name OptionParser Message-ID: Bugs item #784786, was opened at 2003-08-07 10:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 >Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lu Jian Xiong (fdmulti) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: cannot import name OptionParser Initial Comment: E:\>optparse.py Traceback (most recent call last): File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py from optparse import OptionParser E:\>type optparse.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ****************************************** ********************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************** ********************** IDLE 1.0 >>> from optparse import OptionParser >>> # ok? why? >>> E:\> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 10:22 Message: Logged In: YES user_id=33168 Do you have have multiple versions of Python installed on your machine? Could the first example be using the wrong version? What if you do this before trying to import optparse? import sys; print sys.version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 From noreply at sourceforge.net Thu Aug 7 15:30:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 17:30:40 2003 Subject: [Python-bugs-list] [ python-Bugs-785031 ] MacPython installer fails on UFS filesystem Message-ID: Bugs item #785031, was opened at 2003-08-07 23:30 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=785031&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: MacPython installer fails on UFS filesystem Initial Comment: If you use the binary installer to install to a UFS filesystem in stead of an HFS+ filesystem the applets will not work. The reason is that the #! lines refer to "python" in stead of "Python". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785031&group_id=5470 From noreply at sourceforge.net Thu Aug 7 16:33:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 18:34:02 2003 Subject: [Python-bugs-list] [ python-Bugs-784449 ] obsolete or not installed config files in idlelib Message-ID: Bugs item #784449, was opened at 2003-08-06 23:07 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784449&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: obsolete or not installed config files in idlelib Initial Comment: The files config-unix.txt config-win.txt config.txt in idlelib aren't installed anymore, but are still included in the distribution. Are they obsolete or not installed? ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-08-07 22:33 Message: Logged In: YES user_id=60903 oops, my (packaging) mistake ... closed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-07 12:02 Message: Logged In: YES user_id=21627 Where did you find these files? I can't find them anywhere in Python-2.3.tgz. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784449&group_id=5470 From noreply at sourceforge.net Thu Aug 7 19:14:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 21:14:45 2003 Subject: [Python-bugs-list] [ python-Bugs-785113 ] Incorrect docstring on _strptime/LocaleTime Message-ID: Bugs item #785113, was opened at 2003-08-07 21: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=785113&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect docstring on _strptime/LocaleTime Initial Comment: In library file _strptime.py, class LocaleTime, the docstring is wrong for f_month and a_month. (1) They are full and abbreviated *month* names, not weekday names. (2) They are both lists, but require a length-12 object in the constructor. (Documentation says 13 and 14 item lists.) Change f_month -- full weekday names (14-item list; dummy value in [0], which is added by code) a_month -- abbreviated weekday names (13-item list, dummy value in [0], which is added by code) To f_month -- full month names (13-item list; but dummy value in [0], is added by code) a_month -- abbreviated weekday names (13-item list, but dummy value in [0], is added by code) Technically, this is a 2.2.1 candidate, but as a documentation only fix, I selected 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785113&group_id=5470 From noreply at sourceforge.net Thu Aug 7 19:39:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 21:39:26 2003 Subject: [Python-bugs-list] [ python-Bugs-785113 ] Incorrect docstring on _strptime/LocaleTime Message-ID: Bugs item #785113, was opened at 2003-08-07 21:14 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785113&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Brett Cannon (bcannon) Summary: Incorrect docstring on _strptime/LocaleTime Initial Comment: In library file _strptime.py, class LocaleTime, the docstring is wrong for f_month and a_month. (1) They are full and abbreviated *month* names, not weekday names. (2) They are both lists, but require a length-12 object in the constructor. (Documentation says 13 and 14 item lists.) Change f_month -- full weekday names (14-item list; dummy value in [0], which is added by code) a_month -- abbreviated weekday names (13-item list, dummy value in [0], which is added by code) To f_month -- full month names (13-item list; but dummy value in [0], is added by code) a_month -- abbreviated weekday names (13-item list, but dummy value in [0], is added by code) Technically, this is a 2.2.1 candidate, but as a documentation only fix, I selected 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785113&group_id=5470 From noreply at sourceforge.net Thu Aug 7 19:47:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 21:47:33 2003 Subject: [Python-bugs-list] [ python-Bugs-784786 ] ImportError: cannot import name OptionParser Message-ID: Bugs item #784786, was opened at 2003-08-07 22:01 Message generated for change (Comment added) made by fdmulti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lu Jian Xiong (fdmulti) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: cannot import name OptionParser Initial Comment: E:\>optparse.py Traceback (most recent call last): File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py from optparse import OptionParser E:\>type optparse.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ****************************************** ********************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************** ********************** IDLE 1.0 >>> from optparse import OptionParser >>> # ok? why? >>> E:\> ---------------------------------------------------------------------- >Comment By: Lu Jian Xiong (fdmulti) Date: 2003-08-08 09:47 Message: Logged In: YES user_id=751249 E:\>optparse.py 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] Traceback (most recent call last): File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py import sys print sys.version from optparse import OptionParser E:\>type test1.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> import sys >>> from optparse import OptionParser >>> # ok! E:\>type test2.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 ==== No Subprocess ==== >>> import sys >>> print sys.version 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] >>> from optparse import OptionParser Traceback (most recent call last): File "", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser >>> E:\> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 22:22 Message: Logged In: YES user_id=33168 Do you have have multiple versions of Python installed on your machine? Could the first example be using the wrong version? What if you do this before trying to import optparse? import sys; print sys.version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 From noreply at sourceforge.net Thu Aug 7 19:53:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 21:53:22 2003 Subject: [Python-bugs-list] [ python-Bugs-784786 ] ImportError: cannot import name OptionParser Message-ID: Bugs item #784786, was opened at 2003-08-07 22:01 Message generated for change (Settings changed) made by fdmulti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lu Jian Xiong (fdmulti) >Assigned to: Neal Norwitz (nnorwitz) Summary: ImportError: cannot import name OptionParser Initial Comment: E:\>optparse.py Traceback (most recent call last): File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py from optparse import OptionParser E:\>type optparse.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ****************************************** ********************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************** ********************** IDLE 1.0 >>> from optparse import OptionParser >>> # ok? why? >>> E:\> ---------------------------------------------------------------------- Comment By: Lu Jian Xiong (fdmulti) Date: 2003-08-08 09:47 Message: Logged In: YES user_id=751249 E:\>optparse.py 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] Traceback (most recent call last): File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py import sys print sys.version from optparse import OptionParser E:\>type test1.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> import sys >>> from optparse import OptionParser >>> # ok! E:\>type test2.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 ==== No Subprocess ==== >>> import sys >>> print sys.version 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] >>> from optparse import OptionParser Traceback (most recent call last): File "", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser >>> E:\> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 22:22 Message: Logged In: YES user_id=33168 Do you have have multiple versions of Python installed on your machine? Could the first example be using the wrong version? What if you do this before trying to import optparse? import sys; print sys.version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 From noreply at sourceforge.net Thu Aug 7 19:56:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 21:56:12 2003 Subject: [Python-bugs-list] [ python-Bugs-785113 ] Incorrect docstring on _strptime/LocaleTime Message-ID: Bugs item #785113, was opened at 2003-08-07 18:14 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785113&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Brett Cannon (bcannon) Summary: Incorrect docstring on _strptime/LocaleTime Initial Comment: In library file _strptime.py, class LocaleTime, the docstring is wrong for f_month and a_month. (1) They are full and abbreviated *month* names, not weekday names. (2) They are both lists, but require a length-12 object in the constructor. (Documentation says 13 and 14 item lists.) Change f_month -- full weekday names (14-item list; dummy value in [0], which is added by code) a_month -- abbreviated weekday names (13-item list, dummy value in [0], which is added by code) To f_month -- full month names (13-item list; but dummy value in [0], is added by code) a_month -- abbreviated weekday names (13-item list, but dummy value in [0], is added by code) Technically, this is a 2.2.1 candidate, but as a documentation only fix, I selected 2.3 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-07 18:55 Message: Logged In: YES user_id=357491 No need to worry about 2.2.x since _strptime did not exist in that release. But it has now been fixed in both 2.3.x and 2.4. Thanks, Jim. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785113&group_id=5470 From noreply at sourceforge.net Thu Aug 7 20:01:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 22:02:08 2003 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1, 200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 05:17 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Malte John (drmalte) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-07 19:01 Message: Logged In: YES user_id=357491 OK, the caching has been backported to 2.3.1 so the performance should be close to what 2.4 has. Closing this bug report. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 11:22 Message: Logged In: YES user_id=357491 That sounds reasonable considering you are having to go through the C API for the strings and I am using regexes instead of simple split-on-whitespace/compare parsing like strptime in C pushes for (perk is that Python's strptime can parse %Y%m%d since the separation of whitespace for items is not required). Now I just need to see if I should backport to 2.3.1 . ---------------------------------------------------------------------- Comment By: Malte John (drmalte) Date: 2003-08-05 06:46 Message: Logged In: YES user_id=834648 Hi, I pulled out the brand new version 1.24 wih reintroduced caching. Speedup is is about 400 times :) so it is only three times slower than the system strptime in my testloop ( ~6000 lines/s vs. 16200 lines/s ) Thanks a lot! Malte ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-04 09:36 Message: Logged In: YES user_id=357491 Raymond is talking about version 1.21 . That was the last version with caching. I realize that strptime is no longer a speed demon for those platforms that have a C version, but now everyone has a version that is consistent which I think is worth the slowdown. But there still might be hope for a speedup. There is a chance that I will be allowed to reintroduce the caching code for 2.3.1 . If that happens performance will pick up significantly. If not you will have to wait until 2.4 . ---------------------------------------------------------------------- Comment By: Malte John (drmalte) Date: 2003-08-03 10:45 Message: Logged In: YES user_id=834648 Thanks for the hint! I pulled out _strptimy.py Version 1.23 which is identical to the version in the Python-2.3.tgz I used. :( Here is the output of tar -ztvf ... -rw-rw-r-- barry/barry 20933 2003-07-24 22:02:28 Python-2.3/Lib/_strptime.py ... Regards Malte ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-02 01:53 Message: Logged In: YES user_id=80475 It would be interesting for you to pull down the CVS version from two weeks ago and re-run your timings. The caching code was removed at the end because it was a temporary suspect on a bug-hunt just days before the release. Note, the whole purpose of the pure python version was to avoid the non-portable differences between strptime() implementations on various target systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply at sourceforge.net Thu Aug 7 20:28:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 22:28:36 2003 Subject: [Python-bugs-list] [ python-Bugs-780461 ] MacOS.Error for platform.mac_ver under OS X Message-ID: Bugs item #780461, was opened at 2003-07-30 13:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: M.-A. Lemburg (lemburg) Summary: MacOS.Error for platform.mac_ver under OS X Initial Comment: >>> platform.mac_ver() Traceback (most recent call last): File "", line 1, in ? File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 563, in mac_ver sysv,sysu,sysa = _mac_ver_lookup(('sysv','sysu','sysa')) File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 532, in _mac_ver_lookup append(gestalt(selector)) MacOS.Error: (-5551, 'undefined selector was passed to Gestalt') This is on an OS X 10.2.6 system. Any chance this is because I compiled with --enable- unicode=ucs4 ? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-07 19:28 Message: Logged In: YES user_id=357491 I have no clue how to get the info but I can help test anything. I think Jack is going to have to be the big helper in terms of how to patch this one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-01 04:40 Message: Logged In: YES user_id=38388 Catching MacOS.Error doesn't help much: if 'sysu' is not available on MacOSX, then I need the system information from somewhere else. Any hints ? (don't have a MacOSX to test on, so it's up to you to provide the necessary information or patch :-) Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 02:40 Message: Logged In: YES user_id=45365 The problem is not with your ucs4 build, this call always fails under MacOSX. The problem is that the 'sysu' gestalt selector isn't available under OSX. The code in _mac_ver_lookup does a try/except on RuntimeError around the call to gestalt, but I don't remember MacOS.Error ever being a subclass of RuntimeError. Currently MacOS.Error is in a class by itself, it should probably be an OSError subclass, but that still won't fix this. I suggest doing the try/except on MacOS.Error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 From noreply at sourceforge.net Thu Aug 7 20:57:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 22:57:25 2003 Subject: [Python-bugs-list] [ python-Bugs-784786 ] ImportError: cannot import name OptionParser Message-ID: Bugs item #784786, was opened at 2003-08-07 10:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lu Jian Xiong (fdmulti) Assigned to: Neal Norwitz (nnorwitz) Summary: ImportError: cannot import name OptionParser Initial Comment: E:\>optparse.py Traceback (most recent call last): File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py from optparse import OptionParser E:\>type optparse.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ****************************************** ********************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************** ********************** IDLE 1.0 >>> from optparse import OptionParser >>> # ok? why? >>> E:\> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 22:57 Message: Logged In: YES user_id=33168 I think I just realized what's happening. You are using a file named optparse.py which you are also trying to import within the file. Try renaming your optparse.py to a different name. If that doesn't work, there's more questions below which I started to ask before I realized this. How about printing sys.path? Are they different between IDLE and python? If you do this, do you get the same results? python optparse.py Also print the current directory: import os.path, os print os.path.abspath(os.curdir) My current guess is that sys.path is different. ---------------------------------------------------------------------- Comment By: Lu Jian Xiong (fdmulti) Date: 2003-08-07 21:47 Message: Logged In: YES user_id=751249 E:\>optparse.py 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] Traceback (most recent call last): File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py import sys print sys.version from optparse import OptionParser E:\>type test1.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> import sys >>> from optparse import OptionParser >>> # ok! E:\>type test2.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 ==== No Subprocess ==== >>> import sys >>> print sys.version 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] >>> from optparse import OptionParser Traceback (most recent call last): File "", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser >>> E:\> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 10:22 Message: Logged In: YES user_id=33168 Do you have have multiple versions of Python installed on your machine? Could the first example be using the wrong version? What if you do this before trying to import optparse? import sys; print sys.version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 From noreply at sourceforge.net Thu Aug 7 21:13:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 7 23:14:11 2003 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 05:35 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-07 20:13 Message: Logged In: YES user_id=357491 It's that time again! =) Patch #762934 has another patch to test; the one called "configure.in.patch.kbk". Please give it a shot and respond with what OS you used and a pass or failure. Remember you need to run autoreconf before you run 'configure'. The main test is to see if time.tzset exists after compilation. ---------------------------------------------------------------------- Comment By: The LinuxDuck (thelinuxduck) Date: 2003-07-31 09:41 Message: Logged In: YES user_id=490655 Sorry to pollute here, but just an FYI: Setting line 103 to: environ['TZ'] = 'Australia/Victoria' and changing lines 106- 107 to: self.failUnless(time.tzname[0] == 'EST', str(time.tzname[0])) self.failUnless(time.tzname[1] == 'EST', str(time.tzname[1])) all subsequent tests pass just fine, and the module test completes successfully. Granted, I don't know what the difference between EST and EDT is, but it works. (= With line 103, setting environ['TZ'] as the var 'victoria' and setting line 107 to AEST, that test passes, but as I mentioned before, the time.daylight test fails. ---------------------------------------------------------------------- Comment By: The LinuxDuck (thelinuxduck) Date: 2003-07-31 09:30 Message: Logged In: YES user_id=490655 Just a comment.. I was experimenting with ways to make the test pass (slack 8.1, glib 2.1.3, gcc 3.0.2), and by telling it to test tzname[1] with "AEST" it will pass (though I'm sure this violates whatever the test is for in the first place), but it fails on the time.daylight test (daylight = 0 when should = 1). Interestingly enough, if I change: test_time.py:103: environ['TZ'] = victoria to test_time.py:103: environ['TZ'] = 'Australia/Victoria' (as per the 'time' module documentation) it fails the same way, except the tztime[0,1] = EST,EST instead of AEST,*AEST (*as is the cause for the failed test in the first place). Bear in mind I know jack diddly about how the timezone stuff works, so I'm just playing, and thought I'd share my results.. (= ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 20:38 Message: Logged In: YES user_id=12800 I'm not sure there's anything we can do about this for Python 2.3 final. Lowering the priority, although I will add a note in known bugs.html page. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-27 16:04 Message: Logged In: YES user_id=827666 Hi. I just thought I'd mention that I got the same results with 2.3c2. Tim ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-21 20:09 Message: Logged In: YES user_id=827666 Hello. I just downloaded 2.3c1. I failed test_time as well. I was going to submit a new bug, but then I saw this thread. I hope this is the right place. test_time test test_time failed -- Traceback (most recent call last): File "/home/tim/Download/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/tim/Download/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 227 tests OK. 1 test failed: test_time 27 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. make: *** [test] Error 1 For what it's worth, time seems to work... $ ./python -c 'import time; print time.tzname' ('EST', 'EDT') $ cat /proc/version Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3 20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002 Tim ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 19:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 10:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 00:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 21:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 11:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 10:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 19:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 10:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 08:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply at sourceforge.net Fri Aug 8 01:35:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 03:35:40 2003 Subject: [Python-bugs-list] [ python-Bugs-785222 ] zlib monotonic test -- false assumptions or bug in zlib.lib Message-ID: Bugs item #785222, was opened at 2003-08-08 09: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=785222&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: zlib monotonic test -- false assumptions or bug in zlib.lib Initial Comment: Hi, This bug was observed for Python 2.3c1, but probably is the same in Python 2.3 final. I have discovered (by accident) that the assumption in test_zlib.py, class CompressTestCase, test_monotonic() or build on a false assumption ("higher compression levels should not expand compressed size"), or the zlib version 1.1.4 contains a bug. The test fails when the hamlet_scene sample is modified. Try to remove the empty line from the very beginning of the sample. Then the results for level 2 is better that for level 3 and the result for the level 4 is better than for level 5. The compressed sizes are: level=0, length=245801 level=1, length=5325 level=2, length=4946 level=3, length=6052 level=4, length=2750 level=5, length=2769 level=6, length=2751 level=7, length=2388 level=8, length=2388 level=9, length=2388 Petr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785222&group_id=5470 From noreply at sourceforge.net Fri Aug 8 05:08:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 07:09:01 2003 Subject: [Python-bugs-list] [ python-Bugs-775836 ] change 0, 1 to False, True in dict.has_key doc Message-ID: Bugs item #775836, was opened at 2003-07-22 14:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Raymond Hettinger (rhettinger) Summary: change 0,1 to False,True in dict.has_key doc Initial Comment: http://python.org/doc/2.3c1/lib/typesmapping.html says in the table a.has_key(k) | 1 if a has a key k, else 0 Under Python 2.3 this is True / False >>> {1:2}.has_key(1) True >>> {1:2}.has_key(2) False >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-08 06:08 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libstdtypes.tex 1.130 and 1.129.8.1 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-22 16:04 Message: Logged In: YES user_id=80475 I'll fix it after Py2.3 is done. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-22 15:16 Message: Logged In: YES user_id=3066 It'll have to wait for 2.3.1/2.4. We've done (more than) enough at this point. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-22 15:13 Message: Logged In: YES user_id=33168 Fred, not sure if this should be fixed for 2.3 or wait. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 From noreply at sourceforge.net Fri Aug 8 06:23:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 08:23:26 2003 Subject: [Python-bugs-list] [ python-Bugs-770485 ] cStringIO does not set closed attr Message-ID: Bugs item #770485, was opened at 2003-07-13 06:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770485&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO does not set closed attr Initial Comment: All StringIO() instances have and set the "closed" attribute on close. The cStringIO() instances do not, but I see no reason why they should not have and set a "closed" attribute. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-08 07:23 Message: Logged In: YES user_id=80475 Fixed. See Modules/cStringIO.c 2.41 and 2.40.10.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770485&group_id=5470 From noreply at sourceforge.net Fri Aug 8 11:49:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 13:49:13 2003 Subject: [Python-bugs-list] [ python-Bugs-784183 ] IDLE does not start for 2.3 on windows. Message-ID: Bugs item #784183, was opened at 2003-08-06 08:39 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 Category: Installation Group: Python 2.3 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Michael Chermside (mcherm) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start for 2.3 on windows. Initial Comment: For Python 2.3 installed on Windows (well, Windows 2000 anyway, I haven't tested others), a space in the pathname will create an shortcut to IDLE that does not work. To demonstrate the problem: get a fresh Windows 2000 system. Run the Python 2.3 installer. Select "C:/Program Files/Python23" as the install directory. Use default selections for all other installer options. After install, go to Programs menu, select "Python 2.3" > "IDLE (Python GUI)". It will launch a pythonw process, but nothing will appear on the screen. The problem appears to be the space in the pathname. If you create a shortcut with the path spelled out in full (long names not 8-char abreviations) and with quotes around the pathnames that contain spaces, that shortcut will work. I'm not sure what the fix is, but regretably lots of people have Windows and many of them put their applications in "Program Files". In addition to a patch, we should probably put this in a Known Bugs list somewhere where newbies will find it (where is that?). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-08 12:49 Message: Logged In: YES user_id=149084 > If you create a shortcut with the path spelled out in full > (long names not 8-char abreviations) and with quotes > around the pathnames that contain spaces, that > shortcut will work. I haven't been able to make this work. Do you have a shortcut example involving "Program Files" that starts IDLE1.0 correctly? Duplicate of 780451 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 From noreply at sourceforge.net Fri Aug 8 12:14:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 14:14:31 2003 Subject: [Python-bugs-list] [ python-Bugs-785527 ] 2.3 build fails: Invalid Form Message-ID: Bugs item #785527, was opened at 2003-08-08 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=785527&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Gillogly (gillogly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 build fails: Invalid Form Initial Comment: Linux 2.4.12, Mandrake, gcc 3.2.1 Python-2.3.tgz downloaded 2003-08-08 I did a "configure" which completed. The file config.log ends with "configure: exit 0" "make" failed during the linking phase: $ make c++ -pthread -Xlinker -export-dynamic -o python \ Modules/python.o \ libpython2.3.a -lpthread -ldl -lutil -lm /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. libpython2.3.a(posixmodule.o): In function `posix_tmpnam': /b/jim/Tools/Python-2.3/Modules/posixmodule.c:5783: the use of `tmpnam_r' is dangerous, better use `mkstemp' libpython2.3.a(posixmodule.o): In function `posix_tempnam': /b/jim/Tools/Python-2.3/Modules/posixmodule.c:5738: the use of `tempnam' is dangerous, better use `mkstemp' collect2: ld returned 1 exit status make: *** [python] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785527&group_id=5470 From noreply at sourceforge.net Fri Aug 8 12:34:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 14:34:18 2003 Subject: [Python-bugs-list] [ python-Bugs-785527 ] 2.3 build fails: Invalid Form Message-ID: Bugs item #785527, was opened at 2003-08-08 14:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785527&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Gillogly (gillogly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 build fails: Invalid Form Initial Comment: Linux 2.4.12, Mandrake, gcc 3.2.1 Python-2.3.tgz downloaded 2003-08-08 I did a "configure" which completed. The file config.log ends with "configure: exit 0" "make" failed during the linking phase: $ make c++ -pthread -Xlinker -export-dynamic -o python \ Modules/python.o \ libpython2.3.a -lpthread -ldl -lutil -lm /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. libpython2.3.a(posixmodule.o): In function `posix_tmpnam': /b/jim/Tools/Python-2.3/Modules/posixmodule.c:5783: the use of `tmpnam_r' is dangerous, better use `mkstemp' libpython2.3.a(posixmodule.o): In function `posix_tempnam': /b/jim/Tools/Python-2.3/Modules/posixmodule.c:5738: the use of `tempnam' is dangerous, better use `mkstemp' collect2: ld returned 1 exit status make: *** [python] Error 1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-08 14:34 Message: Logged In: YES user_id=33168 Googling for this error finds: http://gcc.gnu.org/ml/gcc/2002-02/msg00965.html which says you need a newer binutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785527&group_id=5470 From noreply at sourceforge.net Fri Aug 8 13:59:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 15:59:33 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 19:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Fri Aug 8 14:14:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 16:14:54 2003 Subject: [Python-bugs-list] [ python-Bugs-785527 ] 2.3 build fails: Invalid Form Message-ID: Bugs item #785527, was opened at 2003-08-08 11:14 Message generated for change (Comment added) made by gillogly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785527&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Gillogly (gillogly) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 build fails: Invalid Form Initial Comment: Linux 2.4.12, Mandrake, gcc 3.2.1 Python-2.3.tgz downloaded 2003-08-08 I did a "configure" which completed. The file config.log ends with "configure: exit 0" "make" failed during the linking phase: $ make c++ -pthread -Xlinker -export-dynamic -o python \ Modules/python.o \ libpython2.3.a -lpthread -ldl -lutil -lm /usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 14. libpython2.3.a(posixmodule.o): In function `posix_tmpnam': /b/jim/Tools/Python-2.3/Modules/posixmodule.c:5783: the use of `tmpnam_r' is dangerous, better use `mkstemp' libpython2.3.a(posixmodule.o): In function `posix_tempnam': /b/jim/Tools/Python-2.3/Modules/posixmodule.c:5738: the use of `tempnam' is dangerous, better use `mkstemp' collect2: ld returned 1 exit status make: *** [python] Error 1 ---------------------------------------------------------------------- >Comment By: Jim Gillogly (gillogly) Date: 2003-08-08 13:14 Message: Logged In: YES user_id=840706 That does allow it to compile - thanks. However, more googling pointed out that it's also sufficient to pay attention to the warning shown -- that tmpnam is a security hole, and should be avoided. It's in the "Bugs" section of the tmpnam() man page on linux. In any case, upgrading binutils was sufficient to get Python compiled. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-08 11:34 Message: Logged In: YES user_id=33168 Googling for this error finds: http://gcc.gnu.org/ml/gcc/2002-02/msg00965.html which says you need a newer binutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785527&group_id=5470 From noreply at sourceforge.net Fri Aug 8 14:56:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 16:56:37 2003 Subject: [Python-bugs-list] [ python-Bugs-784786 ] ImportError: cannot import name OptionParser Message-ID: Bugs item #784786, was opened at 2003-08-07 10:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Lu Jian Xiong (fdmulti) Assigned to: Neal Norwitz (nnorwitz) Summary: ImportError: cannot import name OptionParser Initial Comment: E:\>optparse.py Traceback (most recent call last): File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser File "E:\Home\optparse.py", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py from optparse import OptionParser E:\>type optparse.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ****************************************** ********************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************** ********************** IDLE 1.0 >>> from optparse import OptionParser >>> # ok? why? >>> E:\> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-08 16:56 Message: Logged In: YES user_id=33168 I'm going to assume the problem was the filename, so close this bug. If you still have the problem, you can reopen or add a comment. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 22:57 Message: Logged In: YES user_id=33168 I think I just realized what's happening. You are using a file named optparse.py which you are also trying to import within the file. Try renaming your optparse.py to a different name. If that doesn't work, there's more questions below which I started to ask before I realized this. How about printing sys.path? Are they different between IDLE and python? If you do this, do you get the same results? python optparse.py Also print the current directory: import os.path, os print os.path.abspath(os.curdir) My current guess is that sys.path is different. ---------------------------------------------------------------------- Comment By: Lu Jian Xiong (fdmulti) Date: 2003-08-07 21:47 Message: Logged In: YES user_id=751249 E:\>optparse.py 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] Traceback (most recent call last): File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser File "E:\Home\Home\jxlu\optparse.py", line 3, in ? from optparse import OptionParser ImportError: cannot import name OptionParser E:\>type optparse.py import sys print sys.version from optparse import OptionParser E:\>type test1.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> import sys >>> from optparse import OptionParser >>> # ok! E:\>type test2.txt Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 ==== No Subprocess ==== >>> import sys >>> print sys.version 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] >>> from optparse import OptionParser Traceback (most recent call last): File "", line 1, in ? from optparse import OptionParser ImportError: cannot import name OptionParser >>> E:\> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-07 10:22 Message: Logged In: YES user_id=33168 Do you have have multiple versions of Python installed on your machine? Could the first example be using the wrong version? What if you do this before trying to import optparse? import sys; print sys.version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784786&group_id=5470 From noreply at sourceforge.net Fri Aug 8 14:57:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 16:57:36 2003 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-05 23:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-08 13:57 Message: Logged In: YES user_id=357491 OK, I think I found the problem in the code. I have a patch here that fixes the bug in strptime and adds a test for it. Can you try it out and let me know if the test now passes? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-06 12:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply at sourceforge.net Fri Aug 8 15:21:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 8 17:21:40 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 12:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-08 14:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Sat Aug 9 00:50:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 02:50:53 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 19:59 Message generated for change (Comment added) made by netytan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- >Comment By: mark lee smith (netytan) Date: 2003-08-09 06:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 21:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Sat Aug 9 01:42:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 03:42:07 2003 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-06 16:08 Message generated for change (Comment added) made by mckirdy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: john mckirdy (mckirdy) Date: 2003-08-09 17:42 Message: Logged In: YES user_id=838692 The system does support DST; time.daylight = 1 With the patch bad_tz_fix.diff applied get: $ ./python Lib/test/test_strptime.py ... ERROR: test_bad_timezone (__main__.StrptimeTests) -------------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 337, in test_bad_timezone _strptime._regex_cache.clear() AttributeError: 'module' object has no attribute '_regex_cache' ======================================= FAIL: test_timezone (__main__.StrptimeTests) ---------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 302, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File ".../Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 -------------------------------------- But: $ python -c 'import time;import _strptime; print _strptime.strptime(time.strftime("%Z"), "%Z")' (1900, 1, 1, 0, 0, 0, 0, 1, -1) suggests that strptime is fixed ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 06:57 Message: Logged In: YES user_id=357491 OK, I think I found the problem in the code. I have a patch here that fixes the bug in strptime and adds a test for it. Can you try it out and let me know if the test now passes? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-07 05:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply at sourceforge.net Sat Aug 9 02:03:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 04:03:47 2003 Subject: [Python-bugs-list] [ python-Feature Requests-419903 ] Non-contiguous indexing and slicing Message-ID: Feature Requests item #419903, was opened at 2001-04-28 21:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=419903&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: Rejected Priority: 5 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: Non-contiguous indexing and slicing Initial Comment: I don't know if this has been talked about, I couldn't find it in the PEPs, newsgroup or web site. I use PV-WAVE, a matrix manipulation language similar to MatLab and IDL. PV-WAVE and IDL have the same ancestry. Python, along with arrays from Numeric Python makes a pretty good substitute for PV-WAVE. Plus there are many simularities in syntax between Python and PV-WAVE. PV-WAVE code: PV-WAVE> a=[10,20,30,40,50,60,70,80,90] PV-WAVE> b=[0,4,5,7] PV-WAVE> c=a(b) PV-WAVE> print,c [10, 50, 60, 80] Non-contiguous indexing or is it non-contiguous slicing? Actually it should probably be called dicing. :-) Anyway, I would really like that for Python, so here goes... I find myself doing the following to replicate PV-WAVE's behavoir: >>> a=[10,20,30,40,50,60,70,80,90] >>> b=[0,4,5,7] >>> c=[] >>> for i in b: ... c.append(a[i]) ... >>> c [10, 50, 60, 80] First, just taking the idea from PV-WAVE, for example: >>> c=a[0,4,5,7] >>> c [10,50,60,80] Extending it to include ranges: >>> a[0:3,6:-1] [10,20,30,70,80] Maybe overlapping ranges and mix of indexing and slicing: >>> a[0:4,3:4,0:-1,-1] [10,20,30,40,40,10,20,30,40,50,60,70,80,90] There are some issues: The comma is used in Numerical Python to seperate the array coordinates, so a[0:3,6:-1] is already a legitimate Numerical Python statement. It isn't very pretty. Maybe have a 'dice()' function? >>> a=[10,20,30,40,50,60,70,80,90] >>> b=[0,4,5,7] >>> c=a.dice(b) # or c=dice(a,b) ? >>> c [10,50,60,80] Thanks for Python! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 03:03 Message: Logged In: YES user_id=80475 I agree with Brett. This one doesn't have a chance because of the clutter factor and because list comprehensions already handle the situation well. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 18:48 Message: Logged In: YES user_id=357491 I don't see this as worth cluttering up slice notation. I like gaul's suggestion of using a list comprehension to build your list. Heck, you can even simplify the list comp to ``[a[x] for x in b]``. Yes, it is not as short as ``a(b)``, but writing it out it looks like ``[10, 20, 30, 40, 50, 60, 70, 80, 90][[0, 4, 5, 7]]`` which just looks *really* cluttered to me. You also have the built-in 'slice' if you need real control over your slices. So you could do your ``a[0:4, 3:4, 0:-1, -1]`` example as ``[a[slice(*args)] for args in [(0,4), (3,4), (0,-1), (-1,)]]``. God I love list comps. =) ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2001-07-14 17:35 Message: Logged In: YES user_id=139865 Here's a function that gives one some of the functionality you suggested: >>> m=[10,20,30,40,50,60,70,80,90] >>> n=[0,4,5,7] >>> def dice(a, b): ... return [ a[x] for x in xrange(len(a)) if x in b ] ... >>> dice(m, n) [10, 50, 60, 80] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=419903&group_id=5470 From noreply at sourceforge.net Sat Aug 9 02:06:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 04:06:23 2003 Subject: [Python-bugs-list] [ python-Feature Requests-414059 ] Floating point second in date/time tuple Message-ID: Feature Requests item #414059, was opened at 2001-04-05 12:33 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470 Category: Python Library Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Tim Cera (timcera) Assigned to: Nobody/Anonymous (nobody) Summary: Floating point second in date/time tuple Initial Comment: Would like to have this: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0.6, 0, 1, 182, 1) Instead of: >>> time.localtime(1057035600.6) (2003, 7, 1, 1, 0, 0, 1, 182, 1) At a minimum the fractional seconds should be rounded instead of truncated. thanks tim cera ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 03:06 Message: Logged In: YES user_id=80475 Agree with Brett. Closing this one. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 17:55 Message: Logged In: YES user_id=357491 The problem is that the C library's localtime is used to do the conversion and that takes in a time_t argument. On almost all platforms this is a long int. Forcing the number to an integer prevent any unexpected warning about casting if the platform does support floats for some odd reason. The reason the argument is truncated is because the argument to PyArg_ParseTuple is 'd', which is integer. Python basically does what C would do which is truncate. You could round it up by taking the number as a Python object, calling Python's round function, and then extract the integer after the rounding. Trouble is that now your value accounts for time that you didn't even have. The plus side to truncating is your are not adding on time that did not occur; you are just losing some extra time you had. =). If you want to create a patch to rectify the situation you might get people to support the idea, but I don't view this as critical, especially when you can call round yourself before passing the value to localtime. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=414059&group_id=5470 From noreply at sourceforge.net Sat Aug 9 03:29:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 05:29:17 2003 Subject: [Python-bugs-list] [ python-Bugs-785808 ] strptime() VERY slow Message-ID: Bugs item #785808, was opened at 2003-08-09 11: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=785808&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() VERY slow Initial Comment: Recently, strptime() has become almost unacceptably slow. Performace in 2.3b2 was still ok, but has dropped dramatically in 2.3 final. My Draco web application framework does quite a few strptime() calls on each request. It used to be completely database bound, now it is strptime() bound. For a very simple request, 97% of the time is spent in strptime()! A hotshot trace is given below: >>> st.sort_stats('cumulative').print_stats(10) 9940 function calls (9612 primitive calls) in 11.499 CPU seconds Ordered by: cumulative time List reduced from 240 to 10 due to restriction <10> ncalls tottime percall cumtime percall filename:lineno(function) 1 0.001 0.001 11.499 11.499 /usr/local/lib/python2.3/site- packages/draco/dracohandler.py:398(_handler) 26 0.021 0.001 11.227 0.432 /usr/local/lib/python2.3/site- packages/draco/date.py:66(parse) 127 0.021 0.000 11.206 0.088 /usr/local/lib/python2.3/_strptime.py:401(strptime) 1 0.001 0.001 11.184 11.184 /home/www/kml/__handler__.py:41(index) 2 0.001 0.000 11.182 5.591 /home/www/kml/__lib__/kml/database.py:231 (query) 23/12 0.019 0.001 11.167 0.931 /home/www/kml/__lib__/kml/database.py:47 (loadData) 22/11 0.001 0.000 11.165 1.015 /home/www/kml/__lib__/kml/database.py:25 (__init__) 127 0.005 0.000 11.133 0.088 /usr/local/lib/python2.3/_strptime.py:396(compile) 272/85 0.021 0.000 11.123 0.131 /home/www/kml/__lib__/kml/database.py:64(load) 127 0.097 0.001 11.120 0.088 /usr/local/lib/python2.3/_strptime.py:374(pattern) You can see from this trace that 27 calls to strptime() are made, that take 11.2 seconds! When printing actual time, you can see that most time is spent in the calendar function: >>> st.sort_stats('time').print_stats(10) 9940 function calls (9612 primitive calls) in 11.499 CPU seconds Ordered by: internal time List reduced from 240 to 10 due to restriction <10> ncalls tottime percall cumtime percall filename:lineno(function) 728 6.104 0.008 6.104 0.008 /usr/local/lib/python2.3/calendar.py:47 (__getitem__) 1352 4.702 0.003 4.702 0.003 /usr/local/lib/python2.3/calendar.py:34 (__getitem__) 127 0.097 0.001 11.120 0.088 /usr/local/lib/python2.3/_strptime.py:374(pattern) 29 0.061 0.002 0.070 0.002 /usr/local/lib/python2.3/site- packages/MySQLdb/cursors.py:166(__do_query) 52 0.059 0.001 4.761 0.092 /usr/local/lib/python2.3/_strptime.py:211 (__calc_month) 859/755 0.047 0.000 10.997 0.015 /usr/local/lib/python2.3/_strptime.py:319 (__getitem__) 52 0.033 0.001 6.137 0.118 /usr/local/lib/python2.3/_strptime.py:201 (__calc_weekday) 1560 0.022 0.000 0.022 0.000 /usr/local/lib/python2.3/_strptime.py:346(sorter) 104 0.021 0.000 0.043 0.000 /usr/local/lib/python2.3/_strptime.py:344 (__seqToRE) 26 0.021 0.001 11.227 0.432 /usr/local/lib/python2.3/site- packages/draco/date.py:66(parse) Could this please be addressed. Currenlty, Python2.3 is a no-go for Draco and I have to stick with 2.2.3. Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785808&group_id=5470 From noreply at sourceforge.net Sat Aug 9 03:50:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 05:50:21 2003 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-23 02:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 11:50 Message: Logged In: YES user_id=21627 This should now be fixed in pythonrun.c 2.196 sysmodule.c 2.121 NEWS 1.831.4.11 pythonrun.c 2.195.6.1 sysmodule.c 2.120.6.1 As I can't reproduce the problem, I cannot verify whether the fix is effective. Please reopen if the problem persists. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-29 07:07 Message: Logged In: YES user_id=29957 woops. I accidently reset the priority (overlapping commit) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-29 06:49 Message: Logged In: YES user_id=29957 I can't reproduce this on Solaris 2.6 (x86 version). $ env LANG="" ./python Python 2.3 (#1, Jul 29 2003, 04:41:38) [GCC egcs-2.91.57 19980901 (egcs-1.1 release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> print "hello world" hello world >>> ^D $ uname -a SunOS star 5.6 Generic_105182-05 i86pc i386 i86pc I also tried unsetting LANG, setting it to the empty string, to a single space, and was unable to get any problems to show. It also doesn't show on Solaris 2.7 (sparc) - I no longer have any sparcs running 2.6. I'd say it's safe to lower the priority and miss this one for 2.3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 06:42 Message: Logged In: YES user_id=12800 I'm taking this to mean that there's nothing showstopping for Python 2.3 final here. If we want to implement the workaround for the Solaris bug in 2.3.1, then we can do that when we have some breathing room. Lowering the priority. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-29 06:35 Message: Logged In: YES user_id=21627 This is not reproducable on Linux. nl_langinfo(CODESET) will always give a non-empty string. If LANG is not set, the user thereby requests the "POSIX" locale, and its codeset is ANSI_X3.4-1968. So it *is* a bug in that Solaris version that it returns an empty string; the empty string is a valid return value only if the argument to nl_langinfo was invalid. Since the system does support querying the CODESET in principle, it should not be possible to ever get an empty string. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-29 06:08 Message: Logged In: YES user_id=72656 I think you have to unset LANG rather than set to "", but I'm not really understanding this one, so I defer to Mark. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 05:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-23 07:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-23 02:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply at sourceforge.net Sat Aug 9 03:54:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 05:54:47 2003 Subject: [Python-bugs-list] [ python-Bugs-777664 ] HIDDEN in Tkconstants.py Message-ID: Bugs item #777664, was opened at 2003-07-25 18:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777664&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Nobody/Anonymous (nobody) Summary: HIDDEN in Tkconstants.py Initial Comment: Python: 2.3rc2 HIDDEN = 'hidden' should be there in Tkconstants.py (it's used in the canvas). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-08-09 11:54 Message: Logged In: YES user_id=21627 Thanks for the report. This is now fixed in Tkconstants.py 1.9 and 1.8.42.1, NEWS 1.831.4.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777664&group_id=5470 From noreply at sourceforge.net Sat Aug 9 05:40:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 07:40:57 2003 Subject: [Python-bugs-list] [ python-Bugs-778964 ] bad seed in python 2.3 random Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 >Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) >Summary: bad seed in python 2.3 random Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-08-09 18:40 Message: Logged In: YES user_id=22406 Identified the problem in python 2.3 and have test script! It looks like the default seed in python2.3 is int(time()), which yields the same random numbers if a program is run twice in the same second. This is not true of python 2.2. Bill la Forge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 19:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply at sourceforge.net Sat Aug 9 09:29:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 11:30:05 2003 Subject: [Python-bugs-list] [ python-Bugs-778964 ] bad seed in python 2.3 random Message-ID: Bugs item #778964, was opened at 2003-07-28 10:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) >Assigned to: Raymond Hettinger (rhettinger) Summary: bad seed in python 2.3 random Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-09 11:29 Message: Logged In: YES user_id=31435 That is indeed a silent change in strategy. Assigned to Raymond for pondering. Making it act more like previous Pythons would involve changing Random.seed() to replace a when None with long (time.time() * 256) before calling super(Random, self).seed (a). This is much harder to do in C because getting fractional seconds is a cross-platform mess (Python's time.time() hides that mess); then random_seed() should probably insist on having a real argument. Alternatively, random_seed() could invoke Python's time.time() to get at fractional seconds datetimemodule.c's time_time() is one way to do that). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-09 07:40 Message: Logged In: YES user_id=22406 Identified the problem in python 2.3 and have test script! It looks like the default seed in python2.3 is int(time()), which yields the same random numbers if a program is run twice in the same second. This is not true of python 2.2. Bill la Forge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 08:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 06:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 06:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 05:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 05:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 03:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 00:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 00:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-28 23:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 11:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply at sourceforge.net Sat Aug 9 12:32:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 14:32:25 2003 Subject: [Python-bugs-list] [ python-Bugs-778964 ] bad seed in python 2.3 random Message-ID: Bugs item #778964, was opened at 2003-07-28 09:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Raymond Hettinger (rhettinger) Summary: bad seed in python 2.3 random Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 13:32 Message: Logged In: YES user_id=80475 Fixed using Tim's first listed approach. Avoided the second approach because datetime is an optional build component. See Lib/random.py 1.51.8.1 and 1.53. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-09 10:29 Message: Logged In: YES user_id=31435 That is indeed a silent change in strategy. Assigned to Raymond for pondering. Making it act more like previous Pythons would involve changing Random.seed() to replace a when None with long (time.time() * 256) before calling super(Random, self).seed (a). This is much harder to do in C because getting fractional seconds is a cross-platform mess (Python's time.time() hides that mess); then random_seed() should probably insist on having a real argument. Alternatively, random_seed() could invoke Python's time.time() to get at fractional seconds datetimemodule.c's time_time() is one way to do that). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-09 06:40 Message: Logged In: YES user_id=22406 Identified the problem in python 2.3 and have test script! It looks like the default seed in python2.3 is int(time()), which yields the same random numbers if a program is run twice in the same second. This is not true of python 2.2. Bill la Forge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 07:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 05:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 05:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 04:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 04:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 02:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-28 23:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-28 22:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 10:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply at sourceforge.net Sat Aug 9 12:34:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 14:34:26 2003 Subject: [Python-bugs-list] [ python-Bugs-785808 ] strptime() VERY slow Message-ID: Bugs item #785808, was opened at 2003-08-09 04:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785808&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: strptime() VERY slow Initial Comment: Recently, strptime() has become almost unacceptably slow. Performace in 2.3b2 was still ok, but has dropped dramatically in 2.3 final. My Draco web application framework does quite a few strptime() calls on each request. It used to be completely database bound, now it is strptime() bound. For a very simple request, 97% of the time is spent in strptime()! A hotshot trace is given below: >>> st.sort_stats('cumulative').print_stats(10) 9940 function calls (9612 primitive calls) in 11.499 CPU seconds Ordered by: cumulative time List reduced from 240 to 10 due to restriction <10> ncalls tottime percall cumtime percall filename:lineno(function) 1 0.001 0.001 11.499 11.499 /usr/local/lib/python2.3/site- packages/draco/dracohandler.py:398(_handler) 26 0.021 0.001 11.227 0.432 /usr/local/lib/python2.3/site- packages/draco/date.py:66(parse) 127 0.021 0.000 11.206 0.088 /usr/local/lib/python2.3/_strptime.py:401(strptime) 1 0.001 0.001 11.184 11.184 /home/www/kml/__handler__.py:41(index) 2 0.001 0.000 11.182 5.591 /home/www/kml/__lib__/kml/database.py:231 (query) 23/12 0.019 0.001 11.167 0.931 /home/www/kml/__lib__/kml/database.py:47 (loadData) 22/11 0.001 0.000 11.165 1.015 /home/www/kml/__lib__/kml/database.py:25 (__init__) 127 0.005 0.000 11.133 0.088 /usr/local/lib/python2.3/_strptime.py:396(compile) 272/85 0.021 0.000 11.123 0.131 /home/www/kml/__lib__/kml/database.py:64(load) 127 0.097 0.001 11.120 0.088 /usr/local/lib/python2.3/_strptime.py:374(pattern) You can see from this trace that 27 calls to strptime() are made, that take 11.2 seconds! When printing actual time, you can see that most time is spent in the calendar function: >>> st.sort_stats('time').print_stats(10) 9940 function calls (9612 primitive calls) in 11.499 CPU seconds Ordered by: internal time List reduced from 240 to 10 due to restriction <10> ncalls tottime percall cumtime percall filename:lineno(function) 728 6.104 0.008 6.104 0.008 /usr/local/lib/python2.3/calendar.py:47 (__getitem__) 1352 4.702 0.003 4.702 0.003 /usr/local/lib/python2.3/calendar.py:34 (__getitem__) 127 0.097 0.001 11.120 0.088 /usr/local/lib/python2.3/_strptime.py:374(pattern) 29 0.061 0.002 0.070 0.002 /usr/local/lib/python2.3/site- packages/MySQLdb/cursors.py:166(__do_query) 52 0.059 0.001 4.761 0.092 /usr/local/lib/python2.3/_strptime.py:211 (__calc_month) 859/755 0.047 0.000 10.997 0.015 /usr/local/lib/python2.3/_strptime.py:319 (__getitem__) 52 0.033 0.001 6.137 0.118 /usr/local/lib/python2.3/_strptime.py:201 (__calc_weekday) 1560 0.022 0.000 0.022 0.000 /usr/local/lib/python2.3/_strptime.py:346(sorter) 104 0.021 0.000 0.043 0.000 /usr/local/lib/python2.3/_strptime.py:344 (__seqToRE) 26 0.021 0.001 11.227 0.432 /usr/local/lib/python2.3/site- packages/draco/date.py:66(parse) Could this please be addressed. Currenlty, Python2.3 is a no-go for Draco and I have to stick with 2.2.3. Geert Jansen ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 13:34 Message: Logged In: YES user_id=80475 The caching code from 2.3c2 has already been re-installed. It will be out shortly for 2.3.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785808&group_id=5470 From noreply at sourceforge.net Sat Aug 9 13:03:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 15:03:58 2003 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 08:51 Message generated for change (Comment added) made by uselpa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 Category: Python Library >Group: None >Status: Closed Resolution: Invalid >Priority: 1 Submitted By: Patrick Useldinger (uselpa) Assigned to: Tim Peters (tim_one) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- >Comment By: Patrick Useldinger (uselpa) Date: 2003-08-09 19:03 Message: Logged In: YES user_id=835987 not a python issue, but a problem with my udf1.5 driver ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-04 21:08 Message: Logged In: YES user_id=835987 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 ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-04 21:08 Message: Logged In: YES user_id=835987 I have done a final test; my program is now either able to use shutil.copy2, or an external copy program, in exactly the same situation. shutil2.copy() fails xcopy.exe on Windows works ok Source code is attached; see module dfcProcCopy ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-02 20:22 Message: Logged In: YES user_id=835987 As already explained on c.l.python, a manual copy via Explorer *does* work. I've just repeated the same with a copy /b, and again that's OK. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-02 12:32 Message: Logged In: YES user_id=31435 Python has no idea how much space you have left. Write the code in raw C, and the same thing will happen (Python raises an exception because C's I/O returned an error code). It looks like you in fact don't have enough disk space to complete the write. That's why C is complaining. As someone already explained on comp.lang.python, filesystems have hidden overheads, and hoping you can fill it to the last byte with usable data is futile. Experiment: since you're on Windows, try making a copy of the file from a DOS box with "copy /b". That should fail too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply at sourceforge.net Sat Aug 9 13:07:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 15:07:11 2003 Subject: [Python-bugs-list] [ python-Bugs-781891 ] file.write() incorrectly tests remaining space Message-ID: Bugs item #781891, was opened at 2003-08-02 04:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 Category: Python Library >Group: 3rd Party Status: Closed >Resolution: Wont Fix Priority: 1 Submitted By: Patrick Useldinger (uselpa) Assigned to: Tim Peters (tim_one) Summary: file.write() incorrectly tests remaining space Initial Comment: It seems as if before writing each block, a check was done in order to verifiy that there is enough space left for the whole* file, not for the *remaining* data to be written. It happens both under 2.3 and 2.2.3. ===== Python 2.3 ====== I:\My Programs\dfc>b2 start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:21:48 Python 2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "I:\My Programs\dfc\dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "I:\My Programs\dfc\dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "I:\My Programs\dfc\dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "I:\My Programs\dfc\PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "I:\My Programs\dfc\dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "C:\Python23\lib\shutil.py", line 39, in copyfile copyfileobj(fsrc, fdst) File "C:\Python23\lib\shutil.py", line 24, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device I:\My Programs\dfc>dir f: Volume in drive F is Backup 01 Volume Serial Number is E2CB-1650 Directory of F:\ 18/05/2002 15:39 . 18/05/2002 15:39 .. 01/08/2003 00:25 299.630.592 dfcArchive cheetah 20030731-234648 F.zip 1 File(s) 299.630.592 bytes 2 Dir(s) 299.636.736 bytes free ===== Python 2.2.3 ======= I:\My Programs\dfc>i:\py222\python.exe dfc.py dfcCfgBackupCd start dfc.py [v.0.19.final (July 31st, 2003)] @ 2003-08-01 00:29:08 Python 2.2.3.final running on win32 reading configuration file dfcCfgBackupCd instantiating processor(s) . paths & includes/excludes taken from configuration file creating initial reference point i:\dfc\ref\dfcRefBackupCd.dfc ..copying i:\dfc\arc\dfcArchive cheetah 20030731-234648 F.zip to f:\dfcArchive cheetah 20030731-234648 F.zip Traceback (most recent call last): File "dfc.py", line 199, in ? dfc.doProcess(cfgFile.DFCProcTags) File "dfc.py", line 144, in doProcess newStat=self.newStat.get(fileName,None)) == None: File "dfc.py", line 129, in process return self.pubSub.publishMessage(self.pubSubProcess,kwargs,checkRet=True) File "PubSub.py", line 170, in publishMessage retVal.append(subscriber(**dict(args))) File "dfcProcCopy.py", line 20, in process shutil.copyfile(fileName,toFile) File "i:\py222\lib\shutil.py", line 30, in copyfile copyfileobj(fsrc, fdst) File "i:\py222\lib\shutil.py", line 20, in copyfileobj fdst.write(buf) IOError: [Errno 28] No space left on device ======================================================================== ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-09 15:07 Message: Logged In: YES user_id=31435 Wow! I'm glad you resolved it, while sympathizing with the pain of tracking it down. Re-closing as 3rdParty. ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-09 15:03 Message: Logged In: YES user_id=835987 not a python issue, but a problem with my udf1.5 driver ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-04 17:08 Message: Logged In: YES user_id=835987 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 ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-04 17:08 Message: Logged In: YES user_id=835987 I have done a final test; my program is now either able to use shutil.copy2, or an external copy program, in exactly the same situation. shutil2.copy() fails xcopy.exe on Windows works ok Source code is attached; see module dfcProcCopy ---------------------------------------------------------------------- Comment By: Patrick Useldinger (uselpa) Date: 2003-08-02 16:22 Message: Logged In: YES user_id=835987 As already explained on c.l.python, a manual copy via Explorer *does* work. I've just repeated the same with a copy /b, and again that's OK. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-02 08:32 Message: Logged In: YES user_id=31435 Python has no idea how much space you have left. Write the code in raw C, and the same thing will happen (Python raises an exception because C's I/O returned an error code). It looks like you in fact don't have enough disk space to complete the write. That's why C is complaining. As someone already explained on comp.lang.python, filesystems have hidden overheads, and hoping you can fill it to the last byte with usable data is futile. Experiment: since you're on Windows, try making a copy of the file from a DOS box with "copy /b". That should fail too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781891&group_id=5470 From noreply at sourceforge.net Sat Aug 9 14:25:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 16:25:45 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 12:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-09 13:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-08 23:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 14:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Sat Aug 9 14:26:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 16:26:27 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 12:59 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 >Category: Windows >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 13:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-08 23:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 14:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Sat Aug 9 14:30:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 16:30:18 2003 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-05 23:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-09 13:30 Message: Logged In: YES user_id=357491 I know the cause of the first error is the patch is against CVS and not Python 2.3; I adding a caching feature to up performance since 2.3 was released. If you could try the patch against a CVS checkout of the release23-maint branch that would be wonderful. If not don't sweat it. As for the last one, I will take a look. But yes, it looks like it is okay now from your informal test. ---------------------------------------------------------------------- Comment By: john mckirdy (mckirdy) Date: 2003-08-09 00:42 Message: Logged In: YES user_id=838692 The system does support DST; time.daylight = 1 With the patch bad_tz_fix.diff applied get: $ ./python Lib/test/test_strptime.py ... ERROR: test_bad_timezone (__main__.StrptimeTests) -------------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 337, in test_bad_timezone _strptime._regex_cache.clear() AttributeError: 'module' object has no attribute '_regex_cache' ======================================= FAIL: test_timezone (__main__.StrptimeTests) ---------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 302, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File ".../Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 -------------------------------------- But: $ python -c 'import time;import _strptime; print _strptime.strptime(time.strftime("%Z"), "%Z")' (1900, 1, 1, 0, 0, 0, 0, 1, -1) suggests that strptime is fixed ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 13:57 Message: Logged In: YES user_id=357491 OK, I think I found the problem in the code. I have a patch here that fixes the bug in strptime and adds a test for it. Can you try it out and let me know if the test now passes? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-06 12:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply at sourceforge.net Sat Aug 9 15:01:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 9 17:02:05 2003 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-05 23:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-09 14:01 Message: Logged In: YES user_id=357491 OK, I found out the problem with the second failure; it was the order of the elif statements in strptime. I have reordered them. I have created a new diff (bad_tz_fix2.diff) that not only has the correction but also contains all the patches in the 2.3.1 line so it will bring it up to date with CVS as well as with the proposed patch. If you can give this a shot, John, that would be great. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 13:30 Message: Logged In: YES user_id=357491 I know the cause of the first error is the patch is against CVS and not Python 2.3; I adding a caching feature to up performance since 2.3 was released. If you could try the patch against a CVS checkout of the release23-maint branch that would be wonderful. If not don't sweat it. As for the last one, I will take a look. But yes, it looks like it is okay now from your informal test. ---------------------------------------------------------------------- Comment By: john mckirdy (mckirdy) Date: 2003-08-09 00:42 Message: Logged In: YES user_id=838692 The system does support DST; time.daylight = 1 With the patch bad_tz_fix.diff applied get: $ ./python Lib/test/test_strptime.py ... ERROR: test_bad_timezone (__main__.StrptimeTests) -------------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 337, in test_bad_timezone _strptime._regex_cache.clear() AttributeError: 'module' object has no attribute '_regex_cache' ======================================= FAIL: test_timezone (__main__.StrptimeTests) ---------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 302, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File ".../Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 -------------------------------------- But: $ python -c 'import time;import _strptime; print _strptime.strptime(time.strftime("%Z"), "%Z")' (1900, 1, 1, 0, 0, 0, 0, 1, -1) suggests that strptime is fixed ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 13:57 Message: Logged In: YES user_id=357491 OK, I think I found the problem in the code. I have a patch here that fixes the bug in strptime and adds a test for it. Can you try it out and let me know if the test now passes? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-06 12:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply at sourceforge.net Sat Aug 9 22:46:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 00:46:24 2003 Subject: [Python-bugs-list] [ python-Bugs-778964 ] bad seed in python 2.3 random Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Raymond Hettinger (rhettinger) Summary: bad seed in python 2.3 random Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-08-10 11:46 Message: Logged In: YES user_id=22406 I'll note that this (released version 2.3) is a fairly substantial security flaw, as it makes it much easier to guess someone's seed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-10 01:32 Message: Logged In: YES user_id=80475 Fixed using Tim's first listed approach. Avoided the second approach because datetime is an optional build component. See Lib/random.py 1.51.8.1 and 1.53. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-09 22:29 Message: Logged In: YES user_id=31435 That is indeed a silent change in strategy. Assigned to Raymond for pondering. Making it act more like previous Pythons would involve changing Random.seed() to replace a when None with long (time.time() * 256) before calling super(Random, self).seed (a). This is much harder to do in C because getting fractional seconds is a cross-platform mess (Python's time.time() hides that mess); then random_seed() should probably insist on having a real argument. Alternatively, random_seed() could invoke Python's time.time() to get at fractional seconds datetimemodule.c's time_time() is one way to do that). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-09 18:40 Message: Logged In: YES user_id=22406 Identified the problem in python 2.3 and have test script! It looks like the default seed in python2.3 is int(time()), which yields the same random numbers if a program is run twice in the same second. This is not true of python 2.2. Bill la Forge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 19:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply at sourceforge.net Sun Aug 10 00:00:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 02:00:39 2003 Subject: [Python-bugs-list] [ python-Bugs-778964 ] bad seed in python 2.3 random Message-ID: Bugs item #778964, was opened at 2003-07-28 10:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Raymond Hettinger (rhettinger) Summary: bad seed in python 2.3 random Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-10 02:00 Message: Logged In: YES user_id=31435 Multiplying by 256 is a trivial improvement if you're a Security Geek. If you care about that, you'll need to tap a source of strong randomness to feed the seed. ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-10 00:46 Message: Logged In: YES user_id=22406 I'll note that this (released version 2.3) is a fairly substantial security flaw, as it makes it much easier to guess someone's seed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-09 14:32 Message: Logged In: YES user_id=80475 Fixed using Tim's first listed approach. Avoided the second approach because datetime is an optional build component. See Lib/random.py 1.51.8.1 and 1.53. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-09 11:29 Message: Logged In: YES user_id=31435 That is indeed a silent change in strategy. Assigned to Raymond for pondering. Making it act more like previous Pythons would involve changing Random.seed() to replace a when None with long (time.time() * 256) before calling super(Random, self).seed (a). This is much harder to do in C because getting fractional seconds is a cross-platform mess (Python's time.time() hides that mess); then random_seed() should probably insist on having a real argument. Alternatively, random_seed() could invoke Python's time.time() to get at fractional seconds datetimemodule.c's time_time() is one way to do that). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-09 07:40 Message: Logged In: YES user_id=22406 Identified the problem in python 2.3 and have test script! It looks like the default seed in python2.3 is int(time()), which yields the same random numbers if a program is run twice in the same second. This is not true of python 2.2. Bill la Forge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 08:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 06:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 06:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 05:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 05:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 03:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 00:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 00:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-28 23:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 11:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply at sourceforge.net Sun Aug 10 01:10:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 03:10:40 2003 Subject: [Python-bugs-list] [ python-Bugs-778964 ] bad seed in python 2.3 random Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Raymond Hettinger (rhettinger) Summary: bad seed in python 2.3 random Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-08-10 14:10 Message: Logged In: YES user_id=22406 OK, yes. Further, I'll admidt to using such code myself. b-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-10 13:00 Message: Logged In: YES user_id=31435 Multiplying by 256 is a trivial improvement if you're a Security Geek. If you care about that, you'll need to tap a source of strong randomness to feed the seed. ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-10 11:46 Message: Logged In: YES user_id=22406 I'll note that this (released version 2.3) is a fairly substantial security flaw, as it makes it much easier to guess someone's seed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-10 01:32 Message: Logged In: YES user_id=80475 Fixed using Tim's first listed approach. Avoided the second approach because datetime is an optional build component. See Lib/random.py 1.51.8.1 and 1.53. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-09 22:29 Message: Logged In: YES user_id=31435 That is indeed a silent change in strategy. Assigned to Raymond for pondering. Making it act more like previous Pythons would involve changing Random.seed() to replace a when None with long (time.time() * 256) before calling super(Random, self).seed (a). This is much harder to do in C because getting fractional seconds is a cross-platform mess (Python's time.time() hides that mess); then random_seed() should probably insist on having a real argument. Alternatively, random_seed() could invoke Python's time.time() to get at fractional seconds datetimemodule.c's time_time() is one way to do that). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-08-09 18:40 Message: Logged In: YES user_id=22406 Identified the problem in python 2.3 and have test script! It looks like the default seed in python2.3 is int(time()), which yields the same random numbers if a program is run twice in the same second. This is not true of python 2.2. Bill la Forge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 19:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply at sourceforge.net Sun Aug 10 03:34:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 05:34:26 2003 Subject: [Python-bugs-list] [ python-Bugs-786194 ] posixmodule uses utimes, which is broken in glibc-2.3.2 Message-ID: Bugs item #786194, was opened at 2003-08-10 09: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=786194&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule uses utimes, which is broken in glibc-2.3.2 Initial Comment: Maybe this is category 'Build' ... at least it results in '1970/01/01-01:00:01' timestamps on all files copied by distutils on glibc-2.3.2 based systems (2.3.1 seems to be ok). Disabling the detection of the utimes function in configure works around this. As this function is a wrapper around utime, why not use this one directly? Or check, if utimes correctly works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 From noreply at sourceforge.net Sun Aug 10 03:34:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 05:34:49 2003 Subject: [Python-bugs-list] [ python-Bugs-786194 ] posixmodule uses utimes, which is broken in glibc-2.3.2 Message-ID: Bugs item #786194, was opened at 2003-08-10 09:34 Message generated for change (Settings changed) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule uses utimes, which is broken in glibc-2.3.2 Initial Comment: Maybe this is category 'Build' ... at least it results in '1970/01/01-01:00:01' timestamps on all files copied by distutils on glibc-2.3.2 based systems (2.3.1 seems to be ok). Disabling the detection of the utimes function in configure works around this. As this function is a wrapper around utime, why not use this one directly? Or check, if utimes correctly works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 From noreply at sourceforge.net Sun Aug 10 04:54:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 06:54:24 2003 Subject: [Python-bugs-list] [ python-Bugs-786194 ] posixmodule uses utimes, which is broken in glibc-2.3.2 Message-ID: Bugs item #786194, was opened at 2003-08-10 09:34 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule uses utimes, which is broken in glibc-2.3.2 Initial Comment: Maybe this is category 'Build' ... at least it results in '1970/01/01-01:00:01' timestamps on all files copied by distutils on glibc-2.3.2 based systems (2.3.1 seems to be ok). Disabling the detection of the utimes function in configure works around this. As this function is a wrapper around utime, why not use this one directly? Or check, if utimes correctly works. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-08-10 10:54 Message: Logged In: YES user_id=60903 for an utimes check see http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00115.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786194&group_id=5470 From noreply at sourceforge.net Sun Aug 10 10:21:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 12:21:53 2003 Subject: [Python-bugs-list] [ python-Bugs-786314 ] Wrong class name after using import cStringIO as StringIO Message-ID: Bugs item #786314, was opened at 2003-08-10 18: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=786314&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong class name after using import cStringIO as StringIO Initial Comment: Try this: Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import cStringIO as StringIO >>> obj = StringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: 'cStringIO.StringO' object has no attribute 'spam' >>> Note that the module/class name in the error message misses an "I". In a unit test of one of my programs I got AttributeError: 'cStringIO.StringI' object has no attribute 'mode' Here, the trailing "O" is missing instead of the "I". Compare this with Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO as cStringIO >>> obj = cStringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: StringIO instance has no attribute 'spam' Surprisingly, the class name has all letters, but the module name isn't there, and the single quotation marks are missing. The bug isn't a bad problem, but perhaps it manifests in other places where it causes more harm. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 From noreply at sourceforge.net Sun Aug 10 13:40:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 10 15:41:20 2003 Subject: [Python-bugs-list] [ python-Bugs-782689 ] PyObject_Free unallocated memory read warning Message-ID: Bugs item #782689, was opened at 2003-08-04 03:38 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782689&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: PyObject_Free unallocated memory read warning Initial Comment: win2k, vc6sp5 ADDRESS_IN_RANGE(p, pool->arenaindex)) is too simple and may read unmanaged memory when "p" does not belong to selected pool and there is something allocated by python allocator and pool->arenaindex is smaller than narenas (random case). valgrind messages for PyObject_Free line 711: Conditional jump or move depends on uninitialised value(s) Use of uninitialised value of size 4 Invalid read of size 4 simple test: #include extern void *PyObject_Malloc(int size); extern void PyObject_Free(void *mem); void main() { void *p0; void *p; int i; p0 = PyObject_Malloc(100); for(i = 1; i < 512; i++ ){ p = PyObject_Malloc(i); PyObject_Free(p); } PyObject_Free(p0); } ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2003-08-10 14:40 Message: Logged In: YES user_id=2772 Please see: http://mail.python.org/pipermail/python-dev/2002-October/029712.html http://mail.python.org/pipermail/python-dev/2003-July/036740.html .. and possibly other past python-dev threads. It is believed that this UMR is safe (non-segfaulting) on systems with a few assumptions about memory allocation. When the first test erroneously passes for a block not from a pool, the next check still gets the right result. If the valgrind suppressions file isn't included in the Python distribution, perhaps it should be added. (how portable have these files been across valgrind versions?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782689&group_id=5470 From noreply at sourceforge.net Mon Aug 11 00:56:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 02:56:24 2003 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-06 16:08 Message generated for change (Comment added) made by mckirdy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: john mckirdy (mckirdy) Date: 2003-08-11 16:56 Message: Logged In: YES user_id=838692 I applied the patch bad_tz_fix2.diff to the python-2.3 release. test_strptime now passes without any problems. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-10 07:01 Message: Logged In: YES user_id=357491 OK, I found out the problem with the second failure; it was the order of the elif statements in strptime. I have reordered them. I have created a new diff (bad_tz_fix2.diff) that not only has the correction but also contains all the patches in the 2.3.1 line so it will bring it up to date with CVS as well as with the proposed patch. If you can give this a shot, John, that would be great. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-10 06:30 Message: Logged In: YES user_id=357491 I know the cause of the first error is the patch is against CVS and not Python 2.3; I adding a caching feature to up performance since 2.3 was released. If you could try the patch against a CVS checkout of the release23-maint branch that would be wonderful. If not don't sweat it. As for the last one, I will take a look. But yes, it looks like it is okay now from your informal test. ---------------------------------------------------------------------- Comment By: john mckirdy (mckirdy) Date: 2003-08-09 17:42 Message: Logged In: YES user_id=838692 The system does support DST; time.daylight = 1 With the patch bad_tz_fix.diff applied get: $ ./python Lib/test/test_strptime.py ... ERROR: test_bad_timezone (__main__.StrptimeTests) -------------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 337, in test_bad_timezone _strptime._regex_cache.clear() AttributeError: 'module' object has no attribute '_regex_cache' ======================================= FAIL: test_timezone (__main__.StrptimeTests) ---------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 302, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File ".../Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 -------------------------------------- But: $ python -c 'import time;import _strptime; print _strptime.strptime(time.strftime("%Z"), "%Z")' (1900, 1, 1, 0, 0, 0, 0, 1, -1) suggests that strptime is fixed ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 06:57 Message: Logged In: YES user_id=357491 OK, I think I found the problem in the code. I have a patch here that fixes the bug in strptime and adds a test for it. Can you try it out and let me know if the test now passes? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-07 05:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply at sourceforge.net Mon Aug 11 01:24:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 03:25:09 2003 Subject: [Python-bugs-list] [ python-Bugs-783952 ] test_strptime fails with duplicate DST timezone name Message-ID: Bugs item #783952, was opened at 2003-08-05 23:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: john mckirdy (mckirdy) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails with duplicate DST timezone name Initial Comment: On Solaris 8, SPARC, python-2.3 $ TZ=Australia/Tasmania $ python -c "import time;print time.tzname" ('EST', 'EST') $ python Lib/test/test_strptime.py ... FAIL: test_timezone (__main__.StrptimeTests) --------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 315, in test_timezone "LocaleTime().timezone has duplicate values and " File ".../lib/python2.3/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values and time.daylight but timezone value not set to -1 ------------------------------------ Note that the test passes with TZ=US/Central, and that Tasmania is currently on daylight savings time. See also bug 763047: test_strptime fails on Linux ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 00:24 Message: Logged In: YES user_id=357491 Great to hear, John! Thanks for you help. Closing this bug as fixed (in both the 2.4 tree and in 2.3.x). ---------------------------------------------------------------------- Comment By: john mckirdy (mckirdy) Date: 2003-08-10 23:56 Message: Logged In: YES user_id=838692 I applied the patch bad_tz_fix2.diff to the python-2.3 release. test_strptime now passes without any problems. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 14:01 Message: Logged In: YES user_id=357491 OK, I found out the problem with the second failure; it was the order of the elif statements in strptime. I have reordered them. I have created a new diff (bad_tz_fix2.diff) that not only has the correction but also contains all the patches in the 2.3.1 line so it will bring it up to date with CVS as well as with the proposed patch. If you can give this a shot, John, that would be great. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 13:30 Message: Logged In: YES user_id=357491 I know the cause of the first error is the patch is against CVS and not Python 2.3; I adding a caching feature to up performance since 2.3 was released. If you could try the patch against a CVS checkout of the release23-maint branch that would be wonderful. If not don't sweat it. As for the last one, I will take a look. But yes, it looks like it is okay now from your informal test. ---------------------------------------------------------------------- Comment By: john mckirdy (mckirdy) Date: 2003-08-09 00:42 Message: Logged In: YES user_id=838692 The system does support DST; time.daylight = 1 With the patch bad_tz_fix.diff applied get: $ ./python Lib/test/test_strptime.py ... ERROR: test_bad_timezone (__main__.StrptimeTests) -------------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 337, in test_bad_timezone _strptime._regex_cache.clear() AttributeError: 'module' object has no attribute '_regex_cache' ======================================= FAIL: test_timezone (__main__.StrptimeTests) ---------------------------------- Traceback (most recent call last): File "Lib/test/test_strptime.py", line 302, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File ".../Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 -------------------------------------- But: $ python -c 'import time;import _strptime; print _strptime.strptime(time.strftime("%Z"), "%Z")' (1900, 1, 1, 0, 0, 0, 0, 1, -1) suggests that strptime is fixed ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 13:57 Message: Logged In: YES user_id=357491 OK, I think I found the problem in the code. I have a patch here that fixes the bug in strptime and adds a test for it. Can you try it out and let me know if the test now passes? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-06 12:05 Message: Logged In: YES user_id=357491 John, what is time.daylight set to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783952&group_id=5470 From noreply at sourceforge.net Mon Aug 11 01:54:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 03:54:44 2003 Subject: [Python-bugs-list] [ python-Bugs-786314 ] Wrong class name after using import cStringIO as StringIO Message-ID: Bugs item #786314, was opened at 2003-08-10 09:21 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 >Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong class name after using import cStringIO as StringIO Initial Comment: Try this: Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import cStringIO as StringIO >>> obj = StringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: 'cStringIO.StringO' object has no attribute 'spam' >>> Note that the module/class name in the error message misses an "I". In a unit test of one of my programs I got AttributeError: 'cStringIO.StringI' object has no attribute 'mode' Here, the trailing "O" is missing instead of the "I". Compare this with Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO as cStringIO >>> obj = cStringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: StringIO instance has no attribute 'spam' Surprisingly, the class name has all letters, but the module name isn't there, and the single quotation marks are missing. The bug isn't a bad problem, but perhaps it manifests in other places where it causes more harm. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 00:54 Message: Logged In: YES user_id=357491 For the first issue, the use of StringO in Modules/cStringIO.c is mentioned in three places; the naming of the type, and twice in the docs for the code for the type. This is because the way it is implemented the modules uses two different types; cStringIO.StringO and cStringIO.StringI (the latter which seems to mostly be used for iterators). You just happen to be running into the implementation exposing itself. I honestly don't know if it should be changed. Since the StringO type seems to handle both input and output it would seem reasonable to change the type name. What do other people think? As for the second example. only the class name is showing up without the module name because StringIO is written in Python and thus does not have its name specified in a string as the cStringIO types do. The quotation marks are missing because the exception is not printing out a string like with the cStringIO instance; it is getting the name through inference. So the only thing to think of changing is the name of the cStringIO.StringO to "cStringIO.StringIO". The problem is that in the code there are structs named IOobject, Oobject, and Iobject. Guess which one StringO derives from? So changing the name might cause some confusion in the source code if it is not read carefully. So I am -0 on changing it. Anyone else have a comment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 From noreply at sourceforge.net Mon Aug 11 02:12:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 04:12:14 2003 Subject: [Python-bugs-list] [ python-Bugs-781285 ] 2.3 web page link to 'New style classes' changes to 2.2.2 Message-ID: Bugs item #781285, was opened at 2003-07-31 21:37 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781285&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 web page link to 'New style classes' changes to 2.2.2 Initial Comment: If you click the 'New style classes' link in the 2.3 web pages, you will be moved into the 2.2.2 web pages i.e. if you then click 'Index' you will go to the 2.2 home page rather than the 2.3 home page. Either this page should be duplicated for 2.3, or there should be an alias for it (not a redirection) in the 2.3 tree. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 01:12 Message: Logged In: YES user_id=357491 First, this is the wrong place for web issues; email webmaster@python.org . Second, the page states that the link sends you to 2.2.3 docs (this might be a change or this may have always been like this, I don't know). So I am closing this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781285&group_id=5470 From noreply at sourceforge.net Mon Aug 11 06:00:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 08:00:13 2003 Subject: [Python-bugs-list] [ python-Bugs-786314 ] Wrong class name after using import cStringIO as StringIO Message-ID: Bugs item #786314, was opened at 2003-08-10 18:21 Message generated for change (Comment added) made by sschwarzer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Stefan Schwarzer (sschwarzer) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong class name after using import cStringIO as StringIO Initial Comment: Try this: Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import cStringIO as StringIO >>> obj = StringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: 'cStringIO.StringO' object has no attribute 'spam' >>> Note that the module/class name in the error message misses an "I". In a unit test of one of my programs I got AttributeError: 'cStringIO.StringI' object has no attribute 'mode' Here, the trailing "O" is missing instead of the "I". Compare this with Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO as cStringIO >>> obj = cStringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: StringIO instance has no attribute 'spam' Surprisingly, the class name has all letters, but the module name isn't there, and the single quotation marks are missing. The bug isn't a bad problem, but perhaps it manifests in other places where it causes more harm. ---------------------------------------------------------------------- >Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-08-11 14:00 Message: Logged In: YES user_id=383516 I thought the bug would be related to some wrong string length calculation. If the reason is really obvious from the C-Code, as you describe, I can live with it. It's just a bit confusing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 09:54 Message: Logged In: YES user_id=357491 For the first issue, the use of StringO in Modules/cStringIO.c is mentioned in three places; the naming of the type, and twice in the docs for the code for the type. This is because the way it is implemented the modules uses two different types; cStringIO.StringO and cStringIO.StringI (the latter which seems to mostly be used for iterators). You just happen to be running into the implementation exposing itself. I honestly don't know if it should be changed. Since the StringO type seems to handle both input and output it would seem reasonable to change the type name. What do other people think? As for the second example. only the class name is showing up without the module name because StringIO is written in Python and thus does not have its name specified in a string as the cStringIO types do. The quotation marks are missing because the exception is not printing out a string like with the cStringIO instance; it is getting the name through inference. So the only thing to think of changing is the name of the cStringIO.StringO to "cStringIO.StringIO". The problem is that in the code there are structs named IOobject, Oobject, and Iobject. Guess which one StringO derives from? So changing the name might cause some confusion in the source code if it is not read carefully. So I am -0 on changing it. Anyone else have a comment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 From noreply at sourceforge.net Mon Aug 11 07:18:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 09:18:46 2003 Subject: [Python-bugs-list] [ python-Bugs-786314 ] Wrong class name after using import cStringIO as StringIO Message-ID: Bugs item #786314, was opened at 2003-08-10 11:21 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Stefan Schwarzer (sschwarzer) >Assigned to: Skip Montanaro (montanaro) Summary: Wrong class name after using import cStringIO as StringIO Initial Comment: Try this: Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import cStringIO as StringIO >>> obj = StringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: 'cStringIO.StringO' object has no attribute 'spam' >>> Note that the module/class name in the error message misses an "I". In a unit test of one of my programs I got AttributeError: 'cStringIO.StringI' object has no attribute 'mode' Here, the trailing "O" is missing instead of the "I". Compare this with Python 2.3 (#1, Aug 6 2003, 21:21:10) [GCC 3.2.2 [FreeBSD] 20030205 (release)] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import StringIO as cStringIO >>> obj = cStringIO.StringIO() >>> obj.spam Traceback (most recent call last): File "", line 1, in ? AttributeError: StringIO instance has no attribute 'spam' Surprisingly, the class name has all letters, but the module name isn't there, and the single quotation marks are missing. The bug isn't a bad problem, but perhaps it manifests in other places where it causes more harm. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-11 08:18 Message: Logged In: YES user_id=44345 I changed the tp_name for both StringI and StringO in v. 2.43. While the names exposed are technically correct, it's only going continue to be a mild confusion. I think the people intimately familiar with the source should be able to figure things out. (Ignore 2.42.) ---------------------------------------------------------------------- Comment By: Stefan Schwarzer (sschwarzer) Date: 2003-08-11 07:00 Message: Logged In: YES user_id=383516 I thought the bug would be related to some wrong string length calculation. If the reason is really obvious from the C-Code, as you describe, I can live with it. It's just a bit confusing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 02:54 Message: Logged In: YES user_id=357491 For the first issue, the use of StringO in Modules/cStringIO.c is mentioned in three places; the naming of the type, and twice in the docs for the code for the type. This is because the way it is implemented the modules uses two different types; cStringIO.StringO and cStringIO.StringI (the latter which seems to mostly be used for iterators). You just happen to be running into the implementation exposing itself. I honestly don't know if it should be changed. Since the StringO type seems to handle both input and output it would seem reasonable to change the type name. What do other people think? As for the second example. only the class name is showing up without the module name because StringIO is written in Python and thus does not have its name specified in a string as the cStringIO types do. The quotation marks are missing because the exception is not printing out a string like with the cStringIO instance; it is getting the name through inference. So the only thing to think of changing is the name of the cStringIO.StringO to "cStringIO.StringIO". The problem is that in the code there are structs named IOobject, Oobject, and Iobject. Guess which one StringO derives from? So changing the name might cause some confusion in the source code if it is not read carefully. So I am -0 on changing it. Anyone else have a comment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786314&group_id=5470 From noreply at sourceforge.net Mon Aug 11 07:49:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 09:49:22 2003 Subject: [Python-bugs-list] [ python-Bugs-618095 ] posixmodule.c fails on Solaris 2.6 Message-ID: Bugs item #618095, was opened at 2002-10-03 10:44 Message generated for change (Comment added) made by mattbehrens You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618095&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeff Bauer (jeffbauer) Assigned to: Nobody/Anonymous (nobody) Summary: posixmodule.c fails on Solaris 2.6 Initial Comment: gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include \ -DPy_BUILD_CORE -c ./Modules/posixmodule.c -o Modules/posixmodule.o In file included from /usr/include/sys/wait.h:24, from /usr/include/stdlib.h:22, from Include/Python.h:36, from ./Modules/posixmodule.c:16: /usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside parameter list /usr/include/sys/resource.h:148: warning: its scope is only this definition or declaration, which is probably not what you want. /usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside parameter list ./Modules/posixmodule.c: In function `posix_utime': ./Modules/posixmodule.c:1493: warning: implicit declaration of function `utimes' In file included from ./Modules/posixmodule.c:5117: /usr/include/sys/statvfs.h: At top level: /usr/include/sys/statvfs.h:93: warning: `struct statvfs64' declared inside parameter list /usr/include/sys/statvfs.h:94: warning: `struct statvfs64' declared inside parameter list ./Modules/posixmodule.c:5120: warning: `struct statvfs64' declared inside parameter list ./Modules/posixmodule.c:5120: parameter `st' has incomplete type ./Modules/posixmodule.c: In function `posix_fstatvfs': ./Modules/posixmodule.c:5166: storage size of `st' isn't known ./Modules/posixmodule.c:5176: type of formal parameter 1 is incomplete ./Modules/posixmodule.c:5166: warning: unused variable `st' ./Modules/posixmodule.c: In function `posix_statvfs': ./Modules/posixmodule.c:5193: storage size of `st' isn't known ./Modules/posixmodule.c:5202: type of formal parameter 1 is incomplete ./Modules/posixmodule.c:5193: warning: unused variable `st' make: *** [Modules/posixmodule.o] Error 1 ---------------------------------------------------------------------- Comment By: Matt Behrens (mattbehrens) Date: 2003-08-11 09:49 Message: Logged In: YES user_id=240525 I successfully compiled using CFLAGS="`getconf LFS_CFLAGS`" OPT="-g -O2 $CFLAGS" ./configure as detailed in http://www.python.org/doc/current/lib/posix-large-files.html gcc 2.95.3, Solaris 2.6. Am I setting myself up for future trouble? (This is with Zope, my database is currently under 2G, but I need LFS if it grows above...) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-04 06:23 Message: Logged In: YES user_id=21627 This is a bug caused by the Solaris/gcc combination. Solaris headers have a bug that only shows up if you use a non-system compiler. gcc 3.2 eliminates the problem by sufficiently emulating the system compiler, so the problem is only present in older gcc releases. I fixed this by disabling LFS in those cases; committed as configure 1.340; configure.in 1.351; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=618095&group_id=5470 From noreply at sourceforge.net Mon Aug 11 09:17:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 11:18:02 2003 Subject: [Python-bugs-list] [ python-Bugs-786737 ] patch for build with read-only $srcdir Message-ID: Bugs item #786737, was opened at 2003-08-11 15: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=786737&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Harald Koenig (hkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: patch for build with read-only $srcdir Initial Comment: trying to build with a read-only $srcdir tree and a tree of symlinks to $srcdir fails at two stages without the attached patch. the additional -IInclude is needed because of graminit.h which gets generated in Includes (since $srcdir/Includes is readonly!). the change from LDSHARED to BLDSHARED is necessary for AIX-4.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786737&group_id=5470 From noreply at sourceforge.net Mon Aug 11 09:21:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 11:21:23 2003 Subject: [Python-bugs-list] [ python-Bugs-786743 ] Solaris 2.5.1 _SC_PAGESIZE vs. _SC_PAGE_SIZE Message-ID: Bugs item #786743, was opened at 2003-08-11 15:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786743&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Harald Koenig (hkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 2.5.1 _SC_PAGESIZE vs. _SC_PAGE_SIZE Initial Comment: Modules/resource.c patch fixes a problem for Solaris 2.5.1 which doesn't define _SC_PAGE_SIZE but _SC_PAGESIZE in unistd.h. feel free to add a test to configure -- I won't touch configure myself (sorry:) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786743&group_id=5470 From noreply at sourceforge.net Mon Aug 11 10:58:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 12:58:50 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 11: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=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Mon Aug 11 13:08:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 15:08:20 2003 Subject: [Python-bugs-list] [ python-Bugs-786931 ] test_strptime traceback Message-ID: Bugs item #786931, was opened at 2003-08-11 14:08 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=786931&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: test_strptime traceback Initial Comment: I recently began seeing a test_strptime error on my Mac OS X system. This is against an up-to-date checkout from CVS. I'm on Central Daylight Time at the moment should that make any difference. ===================================== ================================= ERROR: test_bad_timezone (test.test_strptime.StrptimeTests) -------------------------------------------------------------------- -- Traceback (most recent call last): File "/Users/skip/src/python/head/dist/src/Lib/test/ test_strptime.py", line 28 8, in test_bad_timezone tz_value = _strptime.strptime("PDT", "%Z")[8] File "/Users/skip/src/python/head/dist/src/Lib/ _strptime.py", line 294, in str ptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=PDT fmt=%Z -------------------------------------------------------------------- -- Ran 38 tests in 2.233s FAILED (errors=1) test test_strptime failed -- Traceback (most recent call last): File "/Users/skip/src/python/head/dist/src/Lib/test/ test_strptime.py", line 28 8, in test_bad_timezone tz_value = _strptime.strptime("PDT", "%Z")[8] File "/Users/skip/src/python/head/dist/src/Lib/ _strptime.py", line 294, in str ptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=PDT fmt=%Z ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786931&group_id=5470 From noreply at sourceforge.net Mon Aug 11 13:21:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 15:21:57 2003 Subject: [Python-bugs-list] [ python-Bugs-786931 ] test_strptime traceback Message-ID: Bugs item #786931, was opened at 2003-08-11 12:08 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786931&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: test_strptime traceback Initial Comment: I recently began seeing a test_strptime error on my Mac OS X system. This is against an up-to-date checkout from CVS. I'm on Central Daylight Time at the moment should that make any difference. ===================================== ================================= ERROR: test_bad_timezone (test.test_strptime.StrptimeTests) -------------------------------------------------------------------- -- Traceback (most recent call last): File "/Users/skip/src/python/head/dist/src/Lib/test/ test_strptime.py", line 28 8, in test_bad_timezone tz_value = _strptime.strptime("PDT", "%Z")[8] File "/Users/skip/src/python/head/dist/src/Lib/ _strptime.py", line 294, in str ptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=PDT fmt=%Z -------------------------------------------------------------------- -- Ran 38 tests in 2.233s FAILED (errors=1) test test_strptime failed -- Traceback (most recent call last): File "/Users/skip/src/python/head/dist/src/Lib/test/ test_strptime.py", line 28 8, in test_bad_timezone tz_value = _strptime.strptime("PDT", "%Z")[8] File "/Users/skip/src/python/head/dist/src/Lib/ _strptime.py", line 294, in str ptime raise ValueError("time data did not match format: data=%s fmt=%s" % ValueError: time data did not match format: data=PDT fmt=%Z ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 12:21 Message: Logged In: YES user_id=357491 This was out of date before it was posted. =) Skip emailed me before creating this and I managed to fix it between then and now. Just need to remember that the world does not go by PDT time (although if they went by UTC my life would certainly be easier). Closed as out-of-date. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786931&group_id=5470 From noreply at sourceforge.net Mon Aug 11 14:21:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 16:21:48 2003 Subject: [Python-bugs-list] [ python-Bugs-786970 ] re doesn't like (^$)* Message-ID: Bugs item #786970, was opened at 2003-08-11 14: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=786970&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Fredrik Lundh (effbot) Summary: re doesn't like (^$)* Initial Comment: Nor, for that matter, does it like "(^)*" % python Python 2.3 (#1, Aug 3 2003, 02:47:49) [GCC 3.1 20020420 (prerelease)] on darwin >>> import re >>> re.compile("(^$)*").match("") Segmentation fault % It's trying real hard to match 0 characters an infinite number of time. :) The segfault is caused in part by the low stacksize limit on my OS X machine, % limit stacksize stacksize 512 kbytes % limit stacksize 2000kbytes % limit stacksize stacksize 2000 kbytes % python Python 2.3 (#1, Aug 3 2003, 02:47:49) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.compile("(^$)*").match("") Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> which suggests that the stack recursion limit test for the re library is not the same as the one used for the rest of Python. (def f(): f() gives me the expected recursion limit, and not a segfault) Seems like the bug could be in several places: - the compiler doesn't handle infinite loops of zero-character tests well (it could convert them to a finite-loop test) - the re matcher doesn't check that it's been in the same place several times without advancing any character positions - the re matcher doesn't use the same stack check used elsewhere in Python - the Mac stacksize default is too low for Python's BTW, checking pcre ... >>> import pre /usr/local/lib/python2.3/pre.py:94: DeprecationWarning: Please use the 're' module, not the 'pre' module DeprecationWarning) >>> pre.compile("(^$)*").match("") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/pre.py", line 251, in compile code=pcre_compile(pattern, flags, groupindex) pcre.error: ('operand of unlimited repeat could match the empty string', 4) >>> which is true, but the pattern I used should (IMHO) be allowed to match the empty string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786970&group_id=5470 From noreply at sourceforge.net Mon Aug 11 18:45:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 20:45:23 2003 Subject: [Python-bugs-list] [ python-Bugs-787077 ] copy_reg globals in cPickle Message-ID: Bugs item #787077, was opened at 2003-08-12 12:45 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=787077&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim McLennan (timmcl) Assigned to: Nobody/Anonymous (nobody) Summary: copy_reg globals in cPickle Initial Comment: I'm not sure if it's a bug as such, but the following behaviour can be rather annoying if you're playing around with copy_reg. On intialisation cPickle creates local copies of the 'dispatch_table', '_extension_registry', '_extension_cache', and '_inverted_registry' dictionaries from the copy_reg module. If that module is reloaded the dictionaries are reinitialised, and so out of sync with the copies in the cPickle modules, which one access from python. thus the following code results in an Unpicklable exception. import cPickle import copy_reg reload(copy_reg) import Numeric cPickle.dumps(Numeric.array([10,10,01]),1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=787077&group_id=5470 From noreply at sourceforge.net Mon Aug 11 18:49:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 20:49:57 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 20:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 19:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Mon Aug 11 18:52:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 20:52:52 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 17:52 Message: Logged In: YES user_id=357491 I'm with Raymond. "Explicit is better than implicit". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 17:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Mon Aug 11 19:36:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 21:36:44 2003 Subject: [Python-bugs-list] [ python-Feature Requests-778859 ] Make the generators working like Sather iterator Message-ID: Feature Requests item #778859, was opened at 2003-07-28 05:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 >Category: Parser/Compiler Group: None Status: Open Resolution: None >Priority: 2 Submitted By: Lionel Thiry (shasckaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make the generators working like Sather iterator Initial Comment: Primarly, it would only be a syntaxic sugar. But it can lead to some unexpected opitmisations. The feature would allow this: def upto(first, last): x=first while x<=last: yield x x=x+1 x=upto(1, 10) try: while 1: print x.next() except StopIteration: print "End of loop" To be written like in Sather or something near it: def upto(first, last): #same definition as above loop: print upto!(1, 10) finally: print "End of loop" As you can see, it's shorter, smarter, and more easy to understand. The '!' in upto!(1, 10) is important to emphasize its r?le as a generator. The creators of Sather tell that this technique can lead to a very high optimisation of loops. I hope that this request will be deeply studied because it is really worth of it. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 20:36 Message: Logged In: YES user_id=80475 For a change of this magnitude, you would need to write up a PEP that summarizes the idea, lists advantages, presents use cases, and discusses implementation issues. The first step is to introduce the idea on comp.lang.python to tease out the issues. The satheric approach does not fit well with existing python generators or with pythonic style. There would need to be a new LOOP statement that functions as: try: while 1: except StopIteration: pass There would also need to be a new keyword for turning regular iterators into satheric iterators, so that "sather(xrange (20))" would have the effect of 1) On the first pass, calling: it = iter(xrange(20)) 2) On each pass, calling and returning it.next() 3) Passing through the StopIteration on the last pass Besides the implementation demands, there are conflicts with python style programming. Controlling loops from the inside runs contrary to most current approaches to python programming -- a notable exception is the use of callback functions in GUI programming. Other considerations are: * do we want to have one more way of implementing iterators * does it fit with pythons goals for being easily readable and friendly to first time programmers -- I think the answer is no because I find your satheric loop example difficult to follow (and the same is doubly true for the sather tutorial's bubble sort example). Without some darned compelling use cases, I believe your feature request is doomed. ---------------------------------------------------------------------- Comment By: Lionel Thiry (shasckaw) Date: 2003-07-28 08:23 Message: Logged In: YES user_id=824691 My example was too simple, sorry. Here is a doc page about satheric iterators: http://www.gnu.org/software/sather/Doc/tutorial.html/iterators873.html And the next one is also pretty interesting. With the satheric way to write it, one would be able to do this: loop: a=range!(1,10) if test(a): b=range!(1,10) print "("+ a + "," + "b" + ")" My error is repaired now! :) The first iterator to stop stop the loop. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 07:22 Message: Logged In: YES user_id=12800 The Pythonic way to write the latter (after the def) is: for x in upto(1, 10): print x else: print 'end of loop' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 From noreply at sourceforge.net Mon Aug 11 20:25:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 11 22:25:44 2003 Subject: [Python-bugs-list] [ python-Bugs-787113 ] zipimport on meta_path fails with mutual importers Message-ID: Bugs item #787113, was opened at 2003-08-12 14: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=787113&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim McLennan (timmcl) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport on meta_path fails with mutual importers Initial Comment: If I create a simple package consisting of a package/__init__.py containing: print "Package: "+__name__ import module and a package/module.py containing: print "Module: "+__name__ import package and zip the directory resulting directory up, then it imports fine if I add the zip to sys.path However if Instead create a zipimporter object and add it to the meta_path then I get a whole heap of recursive imports resulting in output of the following form: Package: package Module: package.module Package: package.package Module: package.package.module Package: package.package.package Module: package.package.package.module Package: package.package.package.package Module: package.package.package.package.module Package: package.package.package.package.package .... before finally running into an exception: ValueError: Module name too long For reference my version string is '2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=787113&group_id=5470 From noreply at sourceforge.net Mon Aug 11 22:33:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 00:33:50 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 18:19 Message generated for change (Comment added) made by russt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Russ Thompson (russt) Date: 2003-08-11 21:33 Message: Logged In: YES user_id=760126 I appreciate the fact that others have different opinions than me. I am confused, however, at the logic behind the reasons given. 1) "Explicit is better than implicit" Isn't the point of a high level scripting language like python to bury the gory details of the program? Logically, explicit control over everything is provided much better by assembly language, not python. 2) "Supporting this everywhere would unnecessarily complicate the code" Absolutely! I'm not advocating some sort of global universal solution, but rather on a case by case basis where it makes sense. Allowing file specifications by string adds only a few lines of code in the implementation: def load(inputfile): if isinstance(inputfile, types.StringType): fname=inputfile inputfile=file(fname,'r') else: fname=None .... if fname!=None: inputfile.close() This hardly adds a significant level of complication to the code. And the goal behind a scripting language like python should be first to simplify the user's programs, and only secondarily to simplify the libraries. 3) "the current way supports and encourages explicit file closing" The implementation as in #2 doesn't explicitly open a file, and closing it is taken care of by the load() function. It's not possible to leave open files floating about. 4) "munging parameters unnecessarily confuses/complicates the API" All we're really talking about here is function overloading, where the function behaves slightly differently depending on the types of its arguments. This is a well established concept in object oriented programming, and highly useful. Can you imagine having to use a different '+' operator for floats than for integers? On a higher level, it seems to me that the choice here is between adding a few lines of code to the library, or adding a few lines of code to user's programs. Given that python is a language designed to make it easy to write simple powerful programs (as opposed to fast programs, or numerically precise programs), the obvious choice seems to me to add it once to the library rather than many times to user's programs. The functions load() and dump() are convenience functions anyway, which (implicitly) shield the user from creating and manipulating a pickling object. How can it hurt to make a convenience function more convenient? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 17:52 Message: Logged In: YES user_id=357491 I'm with Raymond. "Explicit is better than implicit". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 17:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Mon Aug 11 23:42:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 01:43:03 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 18:19 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 22:42 Message: Logged In: YES user_id=357491 My responses to Russ' response: 1) Yes it is supposed to help take programming to a higher level of abstraction, but not to the point of where you start to possibly question what you are using. Is it reasonable for Perl to have ``2+"3"`` equate to 5? Python has always gone the road of "make it obvious about what is happening as long as you don't make the programmer have to jump through *too* many hoops". I don't see this as a case of having too many hoops to jump through. 2)But changing it in only a few places does complicate the API. Now, where you knew the function would want a file, you have to check whether it accepts a string on top of of a file object. Usage becomes inconsistent in the library and that is no good. It also then requires someone to know the API when reading your code; otherwise they might not realize that you are implicitly having the function open a file behind the scenes. This can become important on read-only filesystems or where I/O is known to be very expensive. 3) But explicit closing is good. If you don't want it closed then you have that option. It also lets you keep track very easily how much file I/O you are doing. 4) See 2. I understand your motivation, Russ, but I just don't see it as Pythonic. This gets a -1 from me. ---------------------------------------------------------------------- Comment By: Russ Thompson (russt) Date: 2003-08-11 21:33 Message: Logged In: YES user_id=760126 I appreciate the fact that others have different opinions than me. I am confused, however, at the logic behind the reasons given. 1) "Explicit is better than implicit" Isn't the point of a high level scripting language like python to bury the gory details of the program? Logically, explicit control over everything is provided much better by assembly language, not python. 2) "Supporting this everywhere would unnecessarily complicate the code" Absolutely! I'm not advocating some sort of global universal solution, but rather on a case by case basis where it makes sense. Allowing file specifications by string adds only a few lines of code in the implementation: def load(inputfile): if isinstance(inputfile, types.StringType): fname=inputfile inputfile=file(fname,'r') else: fname=None .... if fname!=None: inputfile.close() This hardly adds a significant level of complication to the code. And the goal behind a scripting language like python should be first to simplify the user's programs, and only secondarily to simplify the libraries. 3) "the current way supports and encourages explicit file closing" The implementation as in #2 doesn't explicitly open a file, and closing it is taken care of by the load() function. It's not possible to leave open files floating about. 4) "munging parameters unnecessarily confuses/complicates the API" All we're really talking about here is function overloading, where the function behaves slightly differently depending on the types of its arguments. This is a well established concept in object oriented programming, and highly useful. Can you imagine having to use a different '+' operator for floats than for integers? On a higher level, it seems to me that the choice here is between adding a few lines of code to the library, or adding a few lines of code to user's programs. Given that python is a language designed to make it easy to write simple powerful programs (as opposed to fast programs, or numerically precise programs), the obvious choice seems to me to add it once to the library rather than many times to user's programs. The functions load() and dump() are convenience functions anyway, which (implicitly) shield the user from creating and manipulating a pickling object. How can it hurt to make a convenience function more convenient? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 17:52 Message: Logged In: YES user_id=357491 I'm with Raymond. "Explicit is better than implicit". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 17:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Mon Aug 11 23:46:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 01:47:05 2003 Subject: [Python-bugs-list] [ python-Feature Requests-759792 ] Make urllib2 more extensible (patch) Message-ID: Feature Requests item #759792, was opened at 2003-06-24 06:16 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2 more extensible (patch) Initial Comment: Problem with urllib2 as it stands: many things would be nice to implement as a handler rather than by overriding methods (and inevitably duplicating code and increasing fragility), but it's not always possible to do so. For example (all from HTTP), automatically adding Referer headers, handling 200 responses that should have been non-2xx errors if the server were sane, handling cookies, handling HTTP-EQUIV headers as if they were normal HTTP headers, automatically making responses seekable, and following Refresh headers. I've done all these things, but I had to duplicate code to do it, because I don't see how to do it with handlers. I've now rewritten this code by adding a 'processor' scheme to urllib2 (I'm *not* using 'scheme' in the technical URL sense here!). Processors work quite similarly to handlers, except that 1. They always *all* get run (rather than just the first to handle a request or response -- unlike handlers). 2. The methods that get called on processors are of the form _request and _response, and are called, respectively, immediately before and immediately after the normal OpenerDirector.open machinery. http_request, for example, gets called on all processors before, and pre-processes HTTP requests; http_response post-processes HTTP responses. 3. _request methods return request objects, and _response methods return response objects. 4. Even 200 responses get processed. You use it like this: # just pass processors to build_opener as if they were handlers opener = build_opener(FooHandler, BarProcessor, BazHandler) response = opener.open("http://www.example.com/") I've reimplemented all my stuff (the features listed in the first paragraph, above) in terms of this scheme, and it all seems to be working fine (but no unit tests yet). So, the scheme does achieve the extensibility it aims for. The patch I've attached here doesn't include most of those features -- the only new functionality it adds is an HTTPRefererProcessor. If this gets accepted, I intend to submit patches adding new processors for cookie handling etc. later. Two things I'd like to know: 1. will my solution break people's code 2. is there a better way? For 1., I *think* it shouldn't break code. For 2., the obvious problem with my solution (below) is that handlers are pretty similar to my processors already. The thing is, I can't see how to reimplement these things in terms of handlers. First, I need to *see* all requests (responses) -- I can do that using handlers by giving them low (high) .handler_order in Python 2.3 and returning None from http_open (http_error_xxx). However, 200 responses never get seen by http_error_xxx, so that doesn't work (and changing that would break old code). Second, I need to actually modify the requests and responses. Sometimes I'd much rather do that by making a new request or response than modifying the old one in-place (redirections, for example) -- and in general, even if I *am* just modifying in-place, I'd still prefer to explictly return the object than rely on side-effects. Perhaps just adding a couple of hooks to AbstractHTTPHandler might get these jobs done, but I think the increased simplicity of AbstractHTTPHandler.do_open and the various processors makes my approach worthwhile (assuming it actually works & is backwards-compat., of course...). Comments? A few notes: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. The current response object (httplib.HTTPResponse, wrapped with urllib.addinfourl) doesn't include response code or message (because code is always 200). The patch just assigns .code and .msg attributes (maybe they should be methods, for uniformity with the rest of the response interface). Backwards-compatibility notes: People who override AbstractHTTPHandler.do_open will do non-200 response handling there, which will break processors, but that's a forwards-compat. issue. I don't think the existence of overridden do_open methods in old code should be a problem for backwards-compatibility. Note that, though processors see all responses, the end user still only gets 200 responses returned. ErrorProcessor ensures that by passing non-200 responses on to the existing urllib2 error machinery. John ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 22:46 Message: Logged In: YES user_id=357491 Sounds kind of like Apache's filters. The idea seems fine, but perhaps this could instead be worked in with Guido's sio package in the CVS sandbox? Seems to be a similar idea. Perhaps there could some way of hooking that code into urllib2? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 15:15 Message: Logged In: YES user_id=31392 In principle, I'm in favor of this. I'd like to take some time to review the design and code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-08 08:13 Message: Logged In: YES user_id=261020 I just noticed the patch breaks on https. Trivially fixed by adding lines like https_request = http_request to the various processor classes. Also, another use case: gzip Content-encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 From noreply at sourceforge.net Tue Aug 12 00:12:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 02:12:13 2003 Subject: [Python-bugs-list] [ python-Feature Requests-739029 ] Constructor for counting things Message-ID: Feature Requests item #739029, was opened at 2003-05-16 19:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Albert Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: Constructor for counting things Initial Comment: Counting things is very common. May I suggest an alternate dictionary constructor that works like this: class BetterDictionary(dict): def bag(classobject, sequence): "Fast way to count things" b = classobject() for k in sequence: b[k] = b.get(k,0) + 1 return b bag = classmethod(bag) print BetterDictionary.bag("jack and jill went up a hill ...") A C implementation could do this very fast. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-11 23:12 Message: Logged In: YES user_id=357491 I don't know if it is *that* common. Besides, as your code shows, it isn't that complex. It strikes me as a little too specific to be made a built-in dict constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=739029&group_id=5470 From noreply at sourceforge.net Tue Aug 12 04:34:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 06:34:57 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-07 03:19 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-08-12 12:34 Message: Logged In: YES user_id=89016 A string argument for a function that requires a stream is ambiguous: Is this argument the file name or the file content? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 07:42 Message: Logged In: YES user_id=357491 My responses to Russ' response: 1) Yes it is supposed to help take programming to a higher level of abstraction, but not to the point of where you start to possibly question what you are using. Is it reasonable for Perl to have ``2+"3"`` equate to 5? Python has always gone the road of "make it obvious about what is happening as long as you don't make the programmer have to jump through *too* many hoops". I don't see this as a case of having too many hoops to jump through. 2)But changing it in only a few places does complicate the API. Now, where you knew the function would want a file, you have to check whether it accepts a string on top of of a file object. Usage becomes inconsistent in the library and that is no good. It also then requires someone to know the API when reading your code; otherwise they might not realize that you are implicitly having the function open a file behind the scenes. This can become important on read-only filesystems or where I/O is known to be very expensive. 3) But explicit closing is good. If you don't want it closed then you have that option. It also lets you keep track very easily how much file I/O you are doing. 4) See 2. I understand your motivation, Russ, but I just don't see it as Pythonic. This gets a -1 from me. ---------------------------------------------------------------------- Comment By: Russ Thompson (russt) Date: 2003-08-12 06:33 Message: Logged In: YES user_id=760126 I appreciate the fact that others have different opinions than me. I am confused, however, at the logic behind the reasons given. 1) "Explicit is better than implicit" Isn't the point of a high level scripting language like python to bury the gory details of the program? Logically, explicit control over everything is provided much better by assembly language, not python. 2) "Supporting this everywhere would unnecessarily complicate the code" Absolutely! I'm not advocating some sort of global universal solution, but rather on a case by case basis where it makes sense. Allowing file specifications by string adds only a few lines of code in the implementation: def load(inputfile): if isinstance(inputfile, types.StringType): fname=inputfile inputfile=file(fname,'r') else: fname=None .... if fname!=None: inputfile.close() This hardly adds a significant level of complication to the code. And the goal behind a scripting language like python should be first to simplify the user's programs, and only secondarily to simplify the libraries. 3) "the current way supports and encourages explicit file closing" The implementation as in #2 doesn't explicitly open a file, and closing it is taken care of by the load() function. It's not possible to leave open files floating about. 4) "munging parameters unnecessarily confuses/complicates the API" All we're really talking about here is function overloading, where the function behaves slightly differently depending on the types of its arguments. This is a well established concept in object oriented programming, and highly useful. Can you imagine having to use a different '+' operator for floats than for integers? On a higher level, it seems to me that the choice here is between adding a few lines of code to the library, or adding a few lines of code to user's programs. Given that python is a language designed to make it easy to write simple powerful programs (as opposed to fast programs, or numerically precise programs), the obvious choice seems to me to add it once to the library rather than many times to user's programs. The functions load() and dump() are convenience functions anyway, which (implicitly) shield the user from creating and manipulating a pickling object. How can it hurt to make a convenience function more convenient? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 02:52 Message: Logged In: YES user_id=357491 I'm with Raymond. "Explicit is better than implicit". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-12 02:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Tue Aug 12 05:39:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 07:42:39 2003 Subject: [Python-bugs-list] [ python-Feature Requests-759792 ] Make urllib2 more extensible (patch) Message-ID: Feature Requests item #759792, was opened at 2003-06-24 14:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2 more extensible (patch) Initial Comment: Problem with urllib2 as it stands: many things would be nice to implement as a handler rather than by overriding methods (and inevitably duplicating code and increasing fragility), but it's not always possible to do so. For example (all from HTTP), automatically adding Referer headers, handling 200 responses that should have been non-2xx errors if the server were sane, handling cookies, handling HTTP-EQUIV headers as if they were normal HTTP headers, automatically making responses seekable, and following Refresh headers. I've done all these things, but I had to duplicate code to do it, because I don't see how to do it with handlers. I've now rewritten this code by adding a 'processor' scheme to urllib2 (I'm *not* using 'scheme' in the technical URL sense here!). Processors work quite similarly to handlers, except that 1. They always *all* get run (rather than just the first to handle a request or response -- unlike handlers). 2. The methods that get called on processors are of the form _request and _response, and are called, respectively, immediately before and immediately after the normal OpenerDirector.open machinery. http_request, for example, gets called on all processors before, and pre-processes HTTP requests; http_response post-processes HTTP responses. 3. _request methods return request objects, and _response methods return response objects. 4. Even 200 responses get processed. You use it like this: # just pass processors to build_opener as if they were handlers opener = build_opener(FooHandler, BarProcessor, BazHandler) response = opener.open("http://www.example.com/") I've reimplemented all my stuff (the features listed in the first paragraph, above) in terms of this scheme, and it all seems to be working fine (but no unit tests yet). So, the scheme does achieve the extensibility it aims for. The patch I've attached here doesn't include most of those features -- the only new functionality it adds is an HTTPRefererProcessor. If this gets accepted, I intend to submit patches adding new processors for cookie handling etc. later. Two things I'd like to know: 1. will my solution break people's code 2. is there a better way? For 1., I *think* it shouldn't break code. For 2., the obvious problem with my solution (below) is that handlers are pretty similar to my processors already. The thing is, I can't see how to reimplement these things in terms of handlers. First, I need to *see* all requests (responses) -- I can do that using handlers by giving them low (high) .handler_order in Python 2.3 and returning None from http_open (http_error_xxx). However, 200 responses never get seen by http_error_xxx, so that doesn't work (and changing that would break old code). Second, I need to actually modify the requests and responses. Sometimes I'd much rather do that by making a new request or response than modifying the old one in-place (redirections, for example) -- and in general, even if I *am* just modifying in-place, I'd still prefer to explictly return the object than rely on side-effects. Perhaps just adding a couple of hooks to AbstractHTTPHandler might get these jobs done, but I think the increased simplicity of AbstractHTTPHandler.do_open and the various processors makes my approach worthwhile (assuming it actually works & is backwards-compat., of course...). Comments? A few notes: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. The current response object (httplib.HTTPResponse, wrapped with urllib.addinfourl) doesn't include response code or message (because code is always 200). The patch just assigns .code and .msg attributes (maybe they should be methods, for uniformity with the rest of the response interface). Backwards-compatibility notes: People who override AbstractHTTPHandler.do_open will do non-200 response handling there, which will break processors, but that's a forwards-compat. issue. I don't think the existence of overridden do_open methods in old code should be a problem for backwards-compatibility. Note that, though processors see all responses, the end user still only gets 200 responses returned. ErrorProcessor ensures that by passing non-200 responses on to the existing urllib2 error machinery. John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-08-12 12:39 Message: Logged In: YES user_id=261020 Possibly similar to Apache filters, but sio's filters seem to be for filtering stream data rather than request / response objects -- has no concept of headers, for example. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 06:46 Message: Logged In: YES user_id=357491 Sounds kind of like Apache's filters. The idea seems fine, but perhaps this could instead be worked in with Guido's sio package in the CVS sandbox? Seems to be a similar idea. Perhaps there could some way of hooking that code into urllib2? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 23:15 Message: Logged In: YES user_id=31392 In principle, I'm in favor of this. I'd like to take some time to review the design and code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-08 16:13 Message: Logged In: YES user_id=261020 I just noticed the patch breaks on https. Trivially fixed by adding lines like https_request = http_request to the various processor classes. Also, another use case: gzip Content-encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 From noreply at sourceforge.net Tue Aug 12 05:58:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 07:58:18 2003 Subject: [Python-bugs-list] [ python-Feature Requests-759792 ] Make urllib2 more extensible (patch) Message-ID: Feature Requests item #759792, was opened at 2003-06-24 14:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2 more extensible (patch) Initial Comment: Problem with urllib2 as it stands: many things would be nice to implement as a handler rather than by overriding methods (and inevitably duplicating code and increasing fragility), but it's not always possible to do so. For example (all from HTTP), automatically adding Referer headers, handling 200 responses that should have been non-2xx errors if the server were sane, handling cookies, handling HTTP-EQUIV headers as if they were normal HTTP headers, automatically making responses seekable, and following Refresh headers. I've done all these things, but I had to duplicate code to do it, because I don't see how to do it with handlers. I've now rewritten this code by adding a 'processor' scheme to urllib2 (I'm *not* using 'scheme' in the technical URL sense here!). Processors work quite similarly to handlers, except that 1. They always *all* get run (rather than just the first to handle a request or response -- unlike handlers). 2. The methods that get called on processors are of the form _request and _response, and are called, respectively, immediately before and immediately after the normal OpenerDirector.open machinery. http_request, for example, gets called on all processors before, and pre-processes HTTP requests; http_response post-processes HTTP responses. 3. _request methods return request objects, and _response methods return response objects. 4. Even 200 responses get processed. You use it like this: # just pass processors to build_opener as if they were handlers opener = build_opener(FooHandler, BarProcessor, BazHandler) response = opener.open("http://www.example.com/") I've reimplemented all my stuff (the features listed in the first paragraph, above) in terms of this scheme, and it all seems to be working fine (but no unit tests yet). So, the scheme does achieve the extensibility it aims for. The patch I've attached here doesn't include most of those features -- the only new functionality it adds is an HTTPRefererProcessor. If this gets accepted, I intend to submit patches adding new processors for cookie handling etc. later. Two things I'd like to know: 1. will my solution break people's code 2. is there a better way? For 1., I *think* it shouldn't break code. For 2., the obvious problem with my solution (below) is that handlers are pretty similar to my processors already. The thing is, I can't see how to reimplement these things in terms of handlers. First, I need to *see* all requests (responses) -- I can do that using handlers by giving them low (high) .handler_order in Python 2.3 and returning None from http_open (http_error_xxx). However, 200 responses never get seen by http_error_xxx, so that doesn't work (and changing that would break old code). Second, I need to actually modify the requests and responses. Sometimes I'd much rather do that by making a new request or response than modifying the old one in-place (redirections, for example) -- and in general, even if I *am* just modifying in-place, I'd still prefer to explictly return the object than rely on side-effects. Perhaps just adding a couple of hooks to AbstractHTTPHandler might get these jobs done, but I think the increased simplicity of AbstractHTTPHandler.do_open and the various processors makes my approach worthwhile (assuming it actually works & is backwards-compat., of course...). Comments? A few notes: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. The current response object (httplib.HTTPResponse, wrapped with urllib.addinfourl) doesn't include response code or message (because code is always 200). The patch just assigns .code and .msg attributes (maybe they should be methods, for uniformity with the rest of the response interface). Backwards-compatibility notes: People who override AbstractHTTPHandler.do_open will do non-200 response handling there, which will break processors, but that's a forwards-compat. issue. I don't think the existence of overridden do_open methods in old code should be a problem for backwards-compatibility. Note that, though processors see all responses, the end user still only gets 200 responses returned. ErrorProcessor ensures that by passing non-200 responses on to the existing urllib2 error machinery. John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-08-12 12:58 Message: Logged In: YES user_id=261020 If anybody wants to see some concrete examples of use of this patch, ask me & I'll mail them to you (actually, they use my urllib2 extension module rather than the patch, but the differences are trivial). BTW Jeremy, any guess about when in your Copious Free Time you're likely to get to this? I'm wondering whether to just release my code as-is, or wait for your comments. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 12:39 Message: Logged In: YES user_id=261020 Possibly similar to Apache filters, but sio's filters seem to be for filtering stream data rather than request / response objects -- has no concept of headers, for example. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 06:46 Message: Logged In: YES user_id=357491 Sounds kind of like Apache's filters. The idea seems fine, but perhaps this could instead be worked in with Guido's sio package in the CVS sandbox? Seems to be a similar idea. Perhaps there could some way of hooking that code into urllib2? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 23:15 Message: Logged In: YES user_id=31392 In principle, I'm in favor of this. I'd like to take some time to review the design and code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-08 16:13 Message: Logged In: YES user_id=261020 I just noticed the patch breaks on https. Trivially fixed by adding lines like https_request = http_request to the various processor classes. Also, another use case: gzip Content-encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 From noreply at sourceforge.net Tue Aug 12 08:28:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 10:28:54 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 18:19 Message generated for change (Comment added) made by russt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Russ Thompson (russt) Date: 2003-08-12 07:28 Message: Logged In: YES user_id=760126 Ok, I can see I'm outvoted. Best wishes to everyone and python is still a great language! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-12 03:34 Message: Logged In: YES user_id=89016 A string argument for a function that requires a stream is ambiguous: Is this argument the file name or the file content? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 22:42 Message: Logged In: YES user_id=357491 My responses to Russ' response: 1) Yes it is supposed to help take programming to a higher level of abstraction, but not to the point of where you start to possibly question what you are using. Is it reasonable for Perl to have ``2+"3"`` equate to 5? Python has always gone the road of "make it obvious about what is happening as long as you don't make the programmer have to jump through *too* many hoops". I don't see this as a case of having too many hoops to jump through. 2)But changing it in only a few places does complicate the API. Now, where you knew the function would want a file, you have to check whether it accepts a string on top of of a file object. Usage becomes inconsistent in the library and that is no good. It also then requires someone to know the API when reading your code; otherwise they might not realize that you are implicitly having the function open a file behind the scenes. This can become important on read-only filesystems or where I/O is known to be very expensive. 3) But explicit closing is good. If you don't want it closed then you have that option. It also lets you keep track very easily how much file I/O you are doing. 4) See 2. I understand your motivation, Russ, but I just don't see it as Pythonic. This gets a -1 from me. ---------------------------------------------------------------------- Comment By: Russ Thompson (russt) Date: 2003-08-11 21:33 Message: Logged In: YES user_id=760126 I appreciate the fact that others have different opinions than me. I am confused, however, at the logic behind the reasons given. 1) "Explicit is better than implicit" Isn't the point of a high level scripting language like python to bury the gory details of the program? Logically, explicit control over everything is provided much better by assembly language, not python. 2) "Supporting this everywhere would unnecessarily complicate the code" Absolutely! I'm not advocating some sort of global universal solution, but rather on a case by case basis where it makes sense. Allowing file specifications by string adds only a few lines of code in the implementation: def load(inputfile): if isinstance(inputfile, types.StringType): fname=inputfile inputfile=file(fname,'r') else: fname=None .... if fname!=None: inputfile.close() This hardly adds a significant level of complication to the code. And the goal behind a scripting language like python should be first to simplify the user's programs, and only secondarily to simplify the libraries. 3) "the current way supports and encourages explicit file closing" The implementation as in #2 doesn't explicitly open a file, and closing it is taken care of by the load() function. It's not possible to leave open files floating about. 4) "munging parameters unnecessarily confuses/complicates the API" All we're really talking about here is function overloading, where the function behaves slightly differently depending on the types of its arguments. This is a well established concept in object oriented programming, and highly useful. Can you imagine having to use a different '+' operator for floats than for integers? On a higher level, it seems to me that the choice here is between adding a few lines of code to the library, or adding a few lines of code to user's programs. Given that python is a language designed to make it easy to write simple powerful programs (as opposed to fast programs, or numerically precise programs), the obvious choice seems to me to add it once to the library rather than many times to user's programs. The functions load() and dump() are convenience functions anyway, which (implicitly) shield the user from creating and manipulating a pickling object. How can it hurt to make a convenience function more convenient? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 17:52 Message: Logged In: YES user_id=357491 I'm with Raymond. "Explicit is better than implicit". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 17:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Tue Aug 12 08:37:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 10:37:28 2003 Subject: [Python-bugs-list] [ python-Feature Requests-784509 ] interpret string argument as filename Message-ID: Feature Requests item #784509, was opened at 2003-08-06 18:19 Message generated for change (Comment added) made by russt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 Category: None Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Russ Thompson (russt) Assigned to: Nobody/Anonymous (nobody) Summary: interpret string argument as filename Initial Comment: I think it would be great if, in general, anywhere a python function asks for a file object, supplying a string would be interpreted as a filename. For example, one can do: cPickle.dump('mypicklefile', myobject) instead of: f=file('mypicklefile','w') cPickle.dump(f,myobject) f.close() Much faster in an interactive session! And very easy to implement. And similarly for cPickle.load() and lots of other functions. Pickling of multiple objects could still be accomplished through the long form above. Thanks, -Russ ---------------------------------------------------------------------- >Comment By: Russ Thompson (russt) Date: 2003-08-12 07:37 Message: Logged In: YES user_id=760126 Ok, I can see I'm outvoted. Best wishes to everyone and python is still a great language! ---------------------------------------------------------------------- Comment By: Russ Thompson (russt) Date: 2003-08-12 07:28 Message: Logged In: YES user_id=760126 Ok, I can see I'm outvoted. Best wishes to everyone and python is still a great language! ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-12 03:34 Message: Logged In: YES user_id=89016 A string argument for a function that requires a stream is ambiguous: Is this argument the file name or the file content? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 22:42 Message: Logged In: YES user_id=357491 My responses to Russ' response: 1) Yes it is supposed to help take programming to a higher level of abstraction, but not to the point of where you start to possibly question what you are using. Is it reasonable for Perl to have ``2+"3"`` equate to 5? Python has always gone the road of "make it obvious about what is happening as long as you don't make the programmer have to jump through *too* many hoops". I don't see this as a case of having too many hoops to jump through. 2)But changing it in only a few places does complicate the API. Now, where you knew the function would want a file, you have to check whether it accepts a string on top of of a file object. Usage becomes inconsistent in the library and that is no good. It also then requires someone to know the API when reading your code; otherwise they might not realize that you are implicitly having the function open a file behind the scenes. This can become important on read-only filesystems or where I/O is known to be very expensive. 3) But explicit closing is good. If you don't want it closed then you have that option. It also lets you keep track very easily how much file I/O you are doing. 4) See 2. I understand your motivation, Russ, but I just don't see it as Pythonic. This gets a -1 from me. ---------------------------------------------------------------------- Comment By: Russ Thompson (russt) Date: 2003-08-11 21:33 Message: Logged In: YES user_id=760126 I appreciate the fact that others have different opinions than me. I am confused, however, at the logic behind the reasons given. 1) "Explicit is better than implicit" Isn't the point of a high level scripting language like python to bury the gory details of the program? Logically, explicit control over everything is provided much better by assembly language, not python. 2) "Supporting this everywhere would unnecessarily complicate the code" Absolutely! I'm not advocating some sort of global universal solution, but rather on a case by case basis where it makes sense. Allowing file specifications by string adds only a few lines of code in the implementation: def load(inputfile): if isinstance(inputfile, types.StringType): fname=inputfile inputfile=file(fname,'r') else: fname=None .... if fname!=None: inputfile.close() This hardly adds a significant level of complication to the code. And the goal behind a scripting language like python should be first to simplify the user's programs, and only secondarily to simplify the libraries. 3) "the current way supports and encourages explicit file closing" The implementation as in #2 doesn't explicitly open a file, and closing it is taken care of by the load() function. It's not possible to leave open files floating about. 4) "munging parameters unnecessarily confuses/complicates the API" All we're really talking about here is function overloading, where the function behaves slightly differently depending on the types of its arguments. This is a well established concept in object oriented programming, and highly useful. Can you imagine having to use a different '+' operator for floats than for integers? On a higher level, it seems to me that the choice here is between adding a few lines of code to the library, or adding a few lines of code to user's programs. Given that python is a language designed to make it easy to write simple powerful programs (as opposed to fast programs, or numerically precise programs), the obvious choice seems to me to add it once to the library rather than many times to user's programs. The functions load() and dump() are convenience functions anyway, which (implicitly) shield the user from creating and manipulating a pickling object. How can it hurt to make a convenience function more convenient? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-11 17:52 Message: Logged In: YES user_id=357491 I'm with Raymond. "Explicit is better than implicit". ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-11 17:49 Message: Logged In: YES user_id=80475 I prefer leaving the functions as they are now because: * the current way supports and encourages explicit file closing * supporting this everywhere would unnecessarily complicate the code * munging parameters unnecessarily confuses/complicates the API ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=784509&group_id=5470 From noreply at sourceforge.net Tue Aug 12 09:19:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 11:20:00 2003 Subject: [Python-bugs-list] [ python-Feature Requests-759792 ] Make urllib2 more extensible (patch) Message-ID: Feature Requests item #759792, was opened at 2003-06-24 13:16 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2 more extensible (patch) Initial Comment: Problem with urllib2 as it stands: many things would be nice to implement as a handler rather than by overriding methods (and inevitably duplicating code and increasing fragility), but it's not always possible to do so. For example (all from HTTP), automatically adding Referer headers, handling 200 responses that should have been non-2xx errors if the server were sane, handling cookies, handling HTTP-EQUIV headers as if they were normal HTTP headers, automatically making responses seekable, and following Refresh headers. I've done all these things, but I had to duplicate code to do it, because I don't see how to do it with handlers. I've now rewritten this code by adding a 'processor' scheme to urllib2 (I'm *not* using 'scheme' in the technical URL sense here!). Processors work quite similarly to handlers, except that 1. They always *all* get run (rather than just the first to handle a request or response -- unlike handlers). 2. The methods that get called on processors are of the form _request and _response, and are called, respectively, immediately before and immediately after the normal OpenerDirector.open machinery. http_request, for example, gets called on all processors before, and pre-processes HTTP requests; http_response post-processes HTTP responses. 3. _request methods return request objects, and _response methods return response objects. 4. Even 200 responses get processed. You use it like this: # just pass processors to build_opener as if they were handlers opener = build_opener(FooHandler, BarProcessor, BazHandler) response = opener.open("http://www.example.com/") I've reimplemented all my stuff (the features listed in the first paragraph, above) in terms of this scheme, and it all seems to be working fine (but no unit tests yet). So, the scheme does achieve the extensibility it aims for. The patch I've attached here doesn't include most of those features -- the only new functionality it adds is an HTTPRefererProcessor. If this gets accepted, I intend to submit patches adding new processors for cookie handling etc. later. Two things I'd like to know: 1. will my solution break people's code 2. is there a better way? For 1., I *think* it shouldn't break code. For 2., the obvious problem with my solution (below) is that handlers are pretty similar to my processors already. The thing is, I can't see how to reimplement these things in terms of handlers. First, I need to *see* all requests (responses) -- I can do that using handlers by giving them low (high) .handler_order in Python 2.3 and returning None from http_open (http_error_xxx). However, 200 responses never get seen by http_error_xxx, so that doesn't work (and changing that would break old code). Second, I need to actually modify the requests and responses. Sometimes I'd much rather do that by making a new request or response than modifying the old one in-place (redirections, for example) -- and in general, even if I *am* just modifying in-place, I'd still prefer to explictly return the object than rely on side-effects. Perhaps just adding a couple of hooks to AbstractHTTPHandler might get these jobs done, but I think the increased simplicity of AbstractHTTPHandler.do_open and the various processors makes my approach worthwhile (assuming it actually works & is backwards-compat., of course...). Comments? A few notes: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. The current response object (httplib.HTTPResponse, wrapped with urllib.addinfourl) doesn't include response code or message (because code is always 200). The patch just assigns .code and .msg attributes (maybe they should be methods, for uniformity with the rest of the response interface). Backwards-compatibility notes: People who override AbstractHTTPHandler.do_open will do non-200 response handling there, which will break processors, but that's a forwards-compat. issue. I don't think the existence of overridden do_open methods in old code should be a problem for backwards-compatibility. Note that, though processors see all responses, the end user still only gets 200 responses returned. ErrorProcessor ensures that by passing non-200 responses on to the existing urllib2 error machinery. John ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-08-12 15:19 Message: Logged In: YES user_id=31392 Dont't wait more than a couple of weeks for me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 11:58 Message: Logged In: YES user_id=261020 If anybody wants to see some concrete examples of use of this patch, ask me & I'll mail them to you (actually, they use my urllib2 extension module rather than the patch, but the differences are trivial). BTW Jeremy, any guess about when in your Copious Free Time you're likely to get to this? I'm wondering whether to just release my code as-is, or wait for your comments. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 11:39 Message: Logged In: YES user_id=261020 Possibly similar to Apache filters, but sio's filters seem to be for filtering stream data rather than request / response objects -- has no concept of headers, for example. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 05:46 Message: Logged In: YES user_id=357491 Sounds kind of like Apache's filters. The idea seems fine, but perhaps this could instead be worked in with Guido's sio package in the CVS sandbox? Seems to be a similar idea. Perhaps there could some way of hooking that code into urllib2? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 22:15 Message: Logged In: YES user_id=31392 In principle, I'm in favor of this. I'd like to take some time to review the design and code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-08 15:13 Message: Logged In: YES user_id=261020 I just noticed the patch breaks on https. Trivially fixed by adding lines like https_request = http_request to the various processor classes. Also, another use case: gzip Content-encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 From noreply at sourceforge.net Tue Aug 12 17:53:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 12 19:53:13 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 19:59 Message generated for change (Comment added) made by netytan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- >Comment By: mark lee smith (netytan) Date: 2003-08-12 23:53 Message: Logged In: YES user_id=797196 Ok I've spent allot of my free time working on this now and I'm pretty sure it isn't in the urllib module. The same message is displayed when using smtplib and sendmail. Both modules use the socket module, but I am not sure about searching that for the message since it is writen in C (A lang' i've only brushed with a few times) plus i'm not sure if this has been changed since 2.2.. I could probably upgrade my version at home and see if i get the same message but i'm a little reluctant to do that. Sorry cannon, I don't know much about Macs or Mac OS :) Hope this helps, let me know what you think. Am not sure where to go next. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 20:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-09 06:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 21:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Wed Aug 13 05:54:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 07:54:14 2003 Subject: [Python-bugs-list] [ python-Bugs-787113 ] zipimport on meta_path fails with mutual importers Message-ID: Bugs item #787113, was opened at 2003-08-11 22:25 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=787113&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim McLennan (timmcl) >Assigned to: Just van Rossum (jvr) Summary: zipimport on meta_path fails with mutual importers Initial Comment: If I create a simple package consisting of a package/__init__.py containing: print "Package: "+__name__ import module and a package/module.py containing: print "Module: "+__name__ import package and zip the directory resulting directory up, then it imports fine if I add the zip to sys.path However if Instead create a zipimporter object and add it to the meta_path then I get a whole heap of recursive imports resulting in output of the following form: Package: package Module: package.module Package: package.package Module: package.package.module Package: package.package.package Module: package.package.package.module Package: package.package.package.package Module: package.package.package.package.module Package: package.package.package.package.package .... before finally running into an exception: ValueError: Module name too long For reference my version string is '2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)]' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=787113&group_id=5470 From noreply at sourceforge.net Wed Aug 13 06:28:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 08:28:03 2003 Subject: [Python-bugs-list] [ python-Bugs-788011 ] compiler.compileFile fails on csv.py Message-ID: Bugs item #788011, was opened at 2003-08-13 13: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=788011&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: compiler.compileFile fails on csv.py Initial Comment: When trying to compile the files in the standard library, I hit a problem compiling (using compiler.compileFile) the "csv.py" module. The following is the backtrace: >>> compileFile("Lib\csv.py") Traceback (most recent call last): File "", line 1, in ? File "C:\Apps\Python\lib\compiler\pycodegen.py", line 42, in compileFile mod.compile(display) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 112, in compile gen = ModuleCodeGenerator(tree) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 1149, in __init__ walk(tree, self) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 342, in visitModule self.scopes = self.parseSymbols(node) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 255, in parseSymbols walk(tree, s) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 207, in visitModule self.visit(node.node, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 258, in visitClass self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 220, in visitFunction self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 279, in visitFor self.visit(node.body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 354, in visitIf self.visit(body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 315, in visitAssign self.visit(node.expr, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 324, in visitSubscript self.visit(node.expr, scope, 0) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) TypeError: visitLambda() takes exactly 3 arguments (4 given) The script I was using was: import os from os.path import join from compiler import compileFile for root, dirs, files in os.walk("Lib"): for name in files: if name.endswith(".py"): print join(root, name) compileFile(join(root, name)) Is there a better way of compiling all Python source in a directory (and its subdirectories)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 From noreply at sourceforge.net Wed Aug 13 07:17:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 09:17:14 2003 Subject: [Python-bugs-list] [ python-Bugs-788035 ] missing universal newline support in os.popen & friends Message-ID: Bugs item #788035, was opened at 2003-08-13 15: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=788035&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Marek (shlomme) Assigned to: Nobody/Anonymous (nobody) Summary: missing universal newline support in os.popen & friends Initial Comment: In contrast to the documentation, os.popen and relatives do not support the "U" format character in their constructors. os.popen("some_nifty_command some_arg", "rU") throws OSError: [Errno 22] Invalid argument , while os.popen{2,3,4} just ignores "U". I noticed that behaviour while p-opening oggenc (the ogg vorbis encoder), which uses curses for output. The lines end with \r and not with \n (due to some ncurses internals, I suspect), so that the file objects readline() function cannot split the output. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788035&group_id=5470 From noreply at sourceforge.net Wed Aug 13 07:39:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 09:44:27 2003 Subject: [Python-bugs-list] [ python-Bugs-788011 ] compiler.compileFile fails on csv.py Message-ID: Bugs item #788011, was opened at 2003-08-13 08:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: compiler.compileFile fails on csv.py Initial Comment: When trying to compile the files in the standard library, I hit a problem compiling (using compiler.compileFile) the "csv.py" module. The following is the backtrace: >>> compileFile("Lib\csv.py") Traceback (most recent call last): File "", line 1, in ? File "C:\Apps\Python\lib\compiler\pycodegen.py", line 42, in compileFile mod.compile(display) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 112, in compile gen = ModuleCodeGenerator(tree) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 1149, in __init__ walk(tree, self) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 342, in visitModule self.scopes = self.parseSymbols(node) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 255, in parseSymbols walk(tree, s) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 207, in visitModule self.visit(node.node, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 258, in visitClass self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 220, in visitFunction self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 279, in visitFor self.visit(node.body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 354, in visitIf self.visit(body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 315, in visitAssign self.visit(node.expr, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 324, in visitSubscript self.visit(node.expr, scope, 0) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) TypeError: visitLambda() takes exactly 3 arguments (4 given) The script I was using was: import os from os.path import join from compiler import compileFile for root, dirs, files in os.walk("Lib"): for name in files: if name.endswith(".py"): print join(root, name) compileFile(join(root, name)) Is there a better way of compiling all Python source in a directory (and its subdirectories)? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 09:39 Message: Logged In: YES user_id=33168 Take a look at compileall.py in the std library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 From noreply at sourceforge.net Wed Aug 13 08:30:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 10:30:53 2003 Subject: [Python-bugs-list] [ python-Bugs-787113 ] zipimport on meta_path fails with mutual importers Message-ID: Bugs item #787113, was opened at 2003-08-12 04:25 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=787113&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim McLennan (timmcl) Assigned to: Just van Rossum (jvr) Summary: zipimport on meta_path fails with mutual importers Initial Comment: If I create a simple package consisting of a package/__init__.py containing: print "Package: "+__name__ import module and a package/module.py containing: print "Module: "+__name__ import package and zip the directory resulting directory up, then it imports fine if I add the zip to sys.path However if Instead create a zipimporter object and add it to the meta_path then I get a whole heap of recursive imports resulting in output of the following form: Package: package Module: package.module Package: package.package Module: package.package.module Package: package.package.package Module: package.package.package.module Package: package.package.package.package Module: package.package.package.package.module Package: package.package.package.package.package .... before finally running into an exception: ValueError: Module name too long For reference my version string is '2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)]' ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-08-13 16:30 Message: Logged In: YES user_id=92689 Hm, good catch! I don't see an obvious fix for this, and I worry that this is the result of a design flaw in the interaction between meta importers and path importers. For now, I think I should document that the zipimporter object is not suited for use on sys.meta_path. I need to do more thinking here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=787113&group_id=5470 From noreply at sourceforge.net Wed Aug 13 08:32:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 10:33:06 2003 Subject: [Python-bugs-list] [ python-Bugs-779825 ] plistlib and bundlebuilder not in the documentation Message-ID: Bugs item #779825, was opened at 2003-07-29 22:04 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Jack Jansen (jackjansen) Summary: plistlib and bundlebuilder not in the documentation Initial Comment: These two modules are not in the module reference (neither in the generic version, nor in the mac-specific version). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-08-13 16:32 Message: Logged In: YES user_id=92689 Assinging over to Jack to get advice what to do. Should I initially list them in undoc.tex? Feel free to assign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 From noreply at sourceforge.net Wed Aug 13 08:36:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 10:36:46 2003 Subject: [Python-bugs-list] [ python-Bugs-782686 ] IDE defaults to Mac linefeeds Message-ID: Bugs item #782686, was opened at 2003-08-04 10:34 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782686&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE defaults to Mac linefeeds Initial Comment: The IDE defaults to Mac linefeeds for new files, also in MacPython-OSX. In PyEdit.Editor.__init__ the logic for initializing self._eoln is fishy, and also incorrect. It should probably use "rU" for reading the files and use f.newlines to initialize it. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-08-13 16:36 Message: Logged In: YES user_id=92689 Can you elaborate on the "incorrect" bit? I agree with the need to switch to "rU". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782686&group_id=5470 From noreply at sourceforge.net Wed Aug 13 08:46:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 10:46:59 2003 Subject: [Python-bugs-list] [ python-Bugs-765456 ] test zipimport fails Message-ID: Bugs item #765456, was opened at 2003-07-03 18:42 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Robin Friedrich (robinf1) Assigned to: Just van Rossum (jvr) Summary: test zipimport fails Initial Comment: Python 2.3b2 build on AIX 4.3.3 Have no clue since zlib and other modules built/tested fine. ./python Lib/test/test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ========================================== ============================ ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ========================================== ============================ ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ------------------------------------------------------- --------------- Ran 24 tests in 0.692s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 196, in ? test_main() File "Lib/test/test_zipimport.py", line 192, in test_main CompressedZipImportTestCase File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 259, in run_unittest run_suite(suite, testclass) File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-08-13 16:46 Message: Logged In: YES user_id=92689 Robin, does this test still fail for you? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 09:32 Message: Logged In: YES user_id=92689 get_file() not existing might be a symptom of a module existing with a name as used in the test suite, eg. "ziptestmodule". Since the error occurs in a nested package this seems very unlikely. Maybe running test_zipimport.py with -v can help to debug the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 21:15 Message: Logged In: YES user_id=33168 The test passes for me on AIX. Robin, did you build from a clean directory? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 20:19 Message: Logged In: YES user_id=33168 Just, any ideas why get_file() doesn't exist? I'll start testing on the snake farm (AIX 4.3.1.0) and let you know if I find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 From noreply at sourceforge.net Wed Aug 13 10:14:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 12:14:06 2003 Subject: [Python-bugs-list] [ python-Bugs-788156 ] IDLE will not start in Windows98 Message-ID: Bugs item #788156, was opened at 2003-08-14 04: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=788156&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brendan DeTracey (detraceyb) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE will not start in Windows98 Initial Comment: IDLE started the first time, but now will not start. OS is Windows98 4.10 (Build 2222). Shows hour glass for a couple seconds, then nothing. Python 2.3 is installed in directory c:\python23. I have tried uninstalling and reinstalling to no effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788156&group_id=5470 From noreply at sourceforge.net Wed Aug 13 11:00:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 13:00:14 2003 Subject: [Python-bugs-list] [ python-Bugs-788183 ] build fails on Tru64 Unix (osf1V5) Message-ID: Bugs item #788183, was opened at 2003-08-13 11:00 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=788183&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: build fails on Tru64 Unix (osf1V5) Initial Comment: the build on an alpha (Tru64 Unix) machine fails when compiling Modules/posixModule.c; it complains about stat and lstat, which HP has defined as _F64_stat and _F64_lstat. HP claims that they automatically convert them to stat and lstat for portability but my guess is that the Python #define STAT code overrides this and so it fails. Changing it to expliciltly reference _F64_stat and _F64_lstat solves the problem. In the same module, plock() and unsetenv() are referenced but neither are found in the include files on the box. Setting the HAVE_PLOCk and HAVE_UNSETENV macros properly solves this problem (why didn't configure detect this?) Finally, once everything is done, distutils does not include -lpthread in the list of libraries needed for link. If you have any questions about these issues, let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788183&group_id=5470 From noreply at sourceforge.net Wed Aug 13 11:39:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 13:39:17 2003 Subject: [Python-bugs-list] [ python-Bugs-788156 ] IDLE will not start in Windows98 Message-ID: Bugs item #788156, was opened at 2003-08-14 04:14 Message generated for change (Comment added) made by detraceyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788156&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brendan DeTracey (detraceyb) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE will not start in Windows98 Initial Comment: IDLE started the first time, but now will not start. OS is Windows98 4.10 (Build 2222). Shows hour glass for a couple seconds, then nothing. Python 2.3 is installed in directory c:\python23. I have tried uninstalling and reinstalling to no effect. ---------------------------------------------------------------------- >Comment By: Brendan DeTracey (detraceyb) Date: 2003-08-14 05:39 Message: Logged In: YES user_id=621753 Solution................. Installing Ruby 1.80-10 and Python2.3 causes a conflict between the respective Tcl/Tk libraries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788156&group_id=5470 From noreply at sourceforge.net Wed Aug 13 12:21:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 14:21:44 2003 Subject: [Python-bugs-list] [ python-Bugs-788156 ] IDLE will not start in Windows98 - one solution Message-ID: Bugs item #788156, was opened at 2003-08-14 04:14 Message generated for change (Settings changed) made by detraceyb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788156&group_id=5470 Category: IDLE Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Brendan DeTracey (detraceyb) Assigned to: Nobody/Anonymous (nobody) >Summary: IDLE will not start in Windows98 - one solution Initial Comment: IDLE started the first time, but now will not start. OS is Windows98 4.10 (Build 2222). Shows hour glass for a couple seconds, then nothing. Python 2.3 is installed in directory c:\python23. I have tried uninstalling and reinstalling to no effect. ---------------------------------------------------------------------- Comment By: Brendan DeTracey (detraceyb) Date: 2003-08-14 05:39 Message: Logged In: YES user_id=621753 Solution................. Installing Ruby 1.80-10 and Python2.3 causes a conflict between the respective Tcl/Tk libraries. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788156&group_id=5470 From noreply at sourceforge.net Wed Aug 13 15:49:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 17:50:00 2003 Subject: [Python-bugs-list] [ python-Bugs-788378 ] Unsupported 'locale' setting causes Idle to crash on startup Message-ID: Bugs item #788378, was opened at 2003-08-13 21: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=788378&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andre Posumentov (aposumentov) Assigned to: Nobody/Anonymous (nobody) Summary: Unsupported 'locale' setting causes Idle to crash on startup Initial Comment: If the 'LANG' environment variable is set to an unsupported value, Idle crashes on startup. The error occurs in IOBinding.py, as follows: Traceback (most recent call last): File "Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "Resources/idle", line 4, in ? import idlelib.PyShell File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/PyShell.py", line 22, in ? from EditorWindow import EditorWindow, fixwordbreaks File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 39, in ? class EditorWindow: File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/IOBinding.py", line 31, in ? locale.setlocale(locale.LC_CTYPE, "") File "/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Here are the offending lines in IOBinding.py: try: import locale locale.setlocale(locale.LC_CTYPE, "") except ImportError: pass As it's not an 'ImportError'... The error is reproducible on Mac OS X 10.2.6, running MacPython-2.3. I have not been able to test on other operating systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 From noreply at sourceforge.net Wed Aug 13 16:37:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 18:38:03 2003 Subject: [Python-bugs-list] [ python-Bugs-788378 ] Unsupported 'locale' setting causes Idle to crash on startup Message-ID: Bugs item #788378, was opened at 2003-08-13 17:49 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andre Posumentov (aposumentov) >Assigned to: Kurt B. Kaiser (kbk) Summary: Unsupported 'locale' setting causes Idle to crash on startup Initial Comment: If the 'LANG' environment variable is set to an unsupported value, Idle crashes on startup. The error occurs in IOBinding.py, as follows: Traceback (most recent call last): File "Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "Resources/idle", line 4, in ? import idlelib.PyShell File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/PyShell.py", line 22, in ? from EditorWindow import EditorWindow, fixwordbreaks File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 39, in ? class EditorWindow: File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/IOBinding.py", line 31, in ? locale.setlocale(locale.LC_CTYPE, "") File "/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Here are the offending lines in IOBinding.py: try: import locale locale.setlocale(locale.LC_CTYPE, "") except ImportError: pass As it's not an 'ImportError'... The error is reproducible on Mac OS X 10.2.6, running MacPython-2.3. I have not been able to test on other operating systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 From noreply at sourceforge.net Wed Aug 13 16:38:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 18:39:09 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 12:58 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) >Assigned to: Jason Tishler (jlt63) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 18:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:21:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:21:25 2003 Subject: [Python-bugs-list] [ python-Bugs-788421 ] bsddb btree set_location() semantics changed Message-ID: Bugs item #788421, was opened at 2003-08-13 16: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=788421&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: bsddb btree set_location() semantics changed Initial Comment: In the old bsddb module a bsddb.btopen(..) database would return the next available key+value on a set_location(key) call when key did not exist in the database. In python 2.3 (pybsddb) it raises an exception and leaves the cursor at an unknown position in the database. [reported by Anthony McDonaly on comp.lang.python] >>> import os >>> import bsddb >>> os.chdir('/tmp') >>> my_data = bsddb.btopen('testing', 'c') >>> for i in range(10): ... if i == 5: ... pass ... else: ... my_data['%d'%i] = '%d'%(i*i) ... >>> my_data.keys() ['0', '1', '2', '3', '4', '6', '7', '8', '9'] >>> my_data.sync() >>> my_data.set_location('5') Traceback (most recent call last): File "", line 1, in ? File "/space/python-2.3/lib/python2.3/bsddb/__init__.py", line 117, in set_location return self.dbc.set(key) _bsddb.DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/data pair found') Correct behaviour would have been to return ('6', '36') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788421&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:26:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:26:13 2003 Subject: [Python-bugs-list] [ 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 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: 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 Wed Aug 13 17:27:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:27:50 2003 Subject: [Python-bugs-list] [ python-Bugs-701751 ] WINDOW in py_curses.h needs ncurses-devel Message-ID: Bugs item #701751, was opened at 2003-03-11 14:13 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701751&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Moshe Yudkowsky (myudkowsky) >Assigned to: A.M. Kuchling (akuchling) Summary: WINDOW in py_curses.h needs ncurses-devel Initial Comment: When trying to build 2.2.2 (Mandrake 9.1 Linux), I got errors when trying to compile _cursesmodule.c. This is because py_curses uses WINDOW. Ultimately, I traced this to my configuration: I had a curses.h file (from somewhere), I had ncurses 5.2 installed (part of the standard Mandrake RPM-based installation), but I didn't have libncurses-devel installed. I installed that RPM and the modules compiled (and tested) correctly. The "configure" program didn't catch this problem. Python compiled and ran anyway, but I would expect that the requirement for an obscure "devel" package ought to be flagged, either in the README or in the configure script. I'd submit a fix, but I don't know what the behavior is *supposed* to be. What I see from the output of "configure" is that configure *still* didn't find the "ncurses.h" file, even though the compiler caught it later. Logs of this compile on request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701751&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:30:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:30:33 2003 Subject: [Python-bugs-list] [ python-Bugs-665572 ] missing important curses calls Message-ID: Bugs item #665572, was opened at 2003-01-10 04:36 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665572&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: missing important curses calls Initial Comment: [ submitted to http://bugs.debian.org/175590 ] The curses library is missing two important calls: newterm() -- required to work with multiple terminals, or to find out if it is possible to work with this terminal delscreen() -- required to free up the memory after endwin() -- current implementations have memory leaks for programs that need to start and stop (those that handle terminal resizes, for instance) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-08-13 19:30 Message: Logged In: YES user_id=11375 Would anyone care to submit a patch to add the missing calls? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665572&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:31:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:31:40 2003 Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris Message-ID: Bugs item #700780, was opened at 2003-03-10 06:54 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Iain Morrison (iainmorrison) >Assigned to: A.M. Kuchling (akuchling) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 11:18 Message: Logged In: YES user_id=21627 What is the ncurses portion of running setup.py? ---------------------------------------------------------------------- Comment By: Iain Morrison (iainmorrison) Date: 2003-03-25 11:11 Message: Logged In: YES user_id=720523 Using setenv CPPFLAGS -I/usr/local/include/ncurses and running ./configure I get checking for ncurses.h... yes However the Makefile is identival to that produced without CPPFLAGS set. The curses test still fails 178 tests OK. 15 tests skipped: test_al test_bsddb test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_openpty test_winreg test_winsound ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2-test/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses diff configure-output ../Python-2.2.2/configure-output 39c39 < checking for ncurses.h... yes --- > checking for ncurses.h... no diff Makefile ../Python-2.2.2/Makefile Anything else I can try iain ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-15 08:44 Message: Logged In: YES user_id=21627 Did you expect to use ncurses, or did you mean to use curses? What is the ncurses portion of running setup.py? To eliminate setup.py problems, you can always edit Modules/Setup. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 10:45 Message: Logged In: YES user_id=11375 Your compiler may not be looking in /usr/local/ for headers and libraries. You shouldn't install ncurses over Solaris curses; locally-installed software belongs in /usr/local/, period. When you run the configure script, you can supply environment variables to add compiler flags; run configure --help to see a list. I'd suggest something like 'CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure', and see if it picks up ncurses.h then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:38:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:38:48 2003 Subject: [Python-bugs-list] [ python-Bugs-788011 ] compiler.compileFile fails on csv.py Message-ID: Bugs item #788011, was opened at 2003-08-13 08:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: compiler.compileFile fails on csv.py Initial Comment: When trying to compile the files in the standard library, I hit a problem compiling (using compiler.compileFile) the "csv.py" module. The following is the backtrace: >>> compileFile("Lib\csv.py") Traceback (most recent call last): File "", line 1, in ? File "C:\Apps\Python\lib\compiler\pycodegen.py", line 42, in compileFile mod.compile(display) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 112, in compile gen = ModuleCodeGenerator(tree) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 1149, in __init__ walk(tree, self) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 342, in visitModule self.scopes = self.parseSymbols(node) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 255, in parseSymbols walk(tree, s) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 207, in visitModule self.visit(node.node, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 258, in visitClass self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 220, in visitFunction self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 279, in visitFor self.visit(node.body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 354, in visitIf self.visit(body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 315, in visitAssign self.visit(node.expr, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 324, in visitSubscript self.visit(node.expr, scope, 0) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) TypeError: visitLambda() takes exactly 3 arguments (4 given) The script I was using was: import os from os.path import join from compiler import compileFile for root, dirs, files in os.walk("Lib"): for name in files: if name.endswith(".py"): print join(root, name) compileFile(join(root, name)) Is there a better way of compiling all Python source in a directory (and its subdirectories)? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-08-13 19:38 Message: Logged In: YES user_id=11375 The line of code that causes the problem is the following in csv.py: modes[char] = reduce(lambda a, b: (0, a[1] + b[1]), items)[1] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 09:39 Message: Logged In: YES user_id=33168 Take a look at compileall.py in the std library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:45:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:46:19 2003 Subject: [Python-bugs-list] [ python-Bugs-788011 ] compiler.compileFile fails on csv.py Message-ID: Bugs item #788011, was opened at 2003-08-13 08:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) >Assigned to: Jeremy Hylton (jhylton) Summary: compiler.compileFile fails on csv.py Initial Comment: When trying to compile the files in the standard library, I hit a problem compiling (using compiler.compileFile) the "csv.py" module. The following is the backtrace: >>> compileFile("Lib\csv.py") Traceback (most recent call last): File "", line 1, in ? File "C:\Apps\Python\lib\compiler\pycodegen.py", line 42, in compileFile mod.compile(display) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 112, in compile gen = ModuleCodeGenerator(tree) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 1149, in __init__ walk(tree, self) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 342, in visitModule self.scopes = self.parseSymbols(node) File "C:\Apps\Python\lib\compiler\pycodegen.py", line 255, in parseSymbols walk(tree, s) File "C:\Apps\Python\lib\compiler\visitor.py", line 106, in walk walker.preorder(tree, visitor) File "C:\Apps\Python\lib\compiler\visitor.py", line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 207, in visitModule self.visit(node.node, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 258, in visitClass self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 220, in visitFunction self.visit(node.code, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 279, in visitFor self.visit(node.body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 354, in visitIf self.visit(body, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 315, in visitAssign self.visit(node.expr, scope) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\symbols.py", line 324, in visitSubscript self.visit(node.expr, scope, 0) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 40, in default self.dispatch(child, *args) File "C:\Apps\Python\lib\compiler\visitor.py", line 57, in dispatch return meth(node, *args) TypeError: visitLambda() takes exactly 3 arguments (4 given) The script I was using was: import os from os.path import join from compiler import compileFile for root, dirs, files in os.walk("Lib"): for name in files: if name.endswith(".py"): print join(root, name) compileFile(join(root, name)) Is there a better way of compiling all Python source in a directory (and its subdirectories)? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-08-13 19:45 Message: Logged In: YES user_id=11375 Actually it can be boiled down yet further: f(lambda a, b: (0, 0))[1] Assigning to Jeremy, because it looks like a compiler/ package bug. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-08-13 19:38 Message: Logged In: YES user_id=11375 The line of code that causes the problem is the following in csv.py: modes[char] = reduce(lambda a, b: (0, a[1] + b[1]), items)[1] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 09:39 Message: Logged In: YES user_id=33168 Take a look at compileall.py in the std library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788011&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:46:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:46:38 2003 Subject: [Python-bugs-list] [ python-Bugs-754455 ] sigwinch crashes python with curses Message-ID: Bugs item #754455, was opened at 2003-06-14 06:51 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: sigwinch crashes python with curses Initial Comment: [forwarded from http://bugs.debian.org/178205] I'm not able to reproduce this bug in current 2.1/2.2. In 2.3 CVS 20030614, changing the window size of an xterm results in the crash The following code crashes. It does not occur when getkey () is not used. # Crash python import curses, signal, time, sys def sigwinch (signum, frame): return win = curses.initscr () signal.signal(signal.SIGWINCH, sigwinch) while 1: win.getkey () curses.endwin () Traceback (most recent call last): File "curs.py", line 9, in ? while 1: win.getkey () _curses.error: no input ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-14 09:43 Message: Logged In: YES user_id=21627 This is not a bug in Python. In _cursesmodule.c rev. 2.70, Patch #633635 from David M. Cooke was implemented, which makes the implementation match the documentation: getch([x, y]) Get a character. Note that the integer returned does not have to be in ASCII range: function keys, keypad keys and so on return numbers higher than 256. In no-delay mode, an exception is raised if there is no input. This exception is raised when the underlying wgetch returns ERR, so if there is a bug here, it might be in ncurses, for having wgetch return on window change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470 From noreply at sourceforge.net Wed Aug 13 17:59:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 19:59:35 2003 Subject: [Python-bugs-list] [ python-Bugs-780231 ] Bug in "Build and C API Changes" section of what's new doc? Message-ID: Bugs item #780231, was opened at 2003-07-30 09:58 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780231&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) >Assigned to: A.M. Kuchling (akuchling) Summary: Bug in "Build and C API Changes" section of what's new doc? Initial Comment: I think there is a bug in the "Build and C API Changes" section of the "what's new in 2.3" document: http://www.python.org/doc/2.3/whatsnew/node20.html It lists a set of changes to the garbage collection C API, but the changes mentioned look like the ones made in Python 2.2a3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780231&group_id=5470 From noreply at sourceforge.net Wed Aug 13 18:01:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 20:01:53 2003 Subject: [Python-bugs-list] [ python-Bugs-776542 ] urllib: open_https generates wrong Authorize header Message-ID: Bugs item #776542, was opened at 2003-07-23 17:40 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776542&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steffen Ries (sries) >Assigned to: A.M. Kuchling (akuchling) Summary: urllib: open_https generates wrong Authorize header Initial Comment: When opening an https page which requires authentication, the "Authorization" header is created incorrectly by open_https(). open_http() uses the correct method. The fix is a simple one line change: *** /usr/local/lib/python2.2/urllib.py Fri Oct 4 18:57:01 2002 --- urllib.py Wed Jul 23 17:23:41 2003 *************** *** 364,370 **** h.putheader('Content-length', '%d' % len(data)) else: h.putrequest('GET', selector) ! if auth: h.putheader('Authorization: Basic %s' % auth) if realhost: h.putheader('Host', realhost) for args in self.addheaders: apply(h.putheader, args) h.endheaders() --- 364,370 ---- h.putheader('Content-length', '%d' % len(data)) else: h.putrequest('GET', selector) ! if auth: h.putheader('Authorization', 'Basic %s' % auth) if realhost: h.putheader('Host', realhost) for args in self.addheaders: apply(h.putheader, args) h.endheaders() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776542&group_id=5470 From noreply at sourceforge.net Wed Aug 13 18:03:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 20:03:21 2003 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 08:52 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Stuart Bishop (zenzen) >Assigned to: A.M. Kuchling (akuchling) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 00:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 09:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply at sourceforge.net Wed Aug 13 19:07:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Aug 13 21:07:57 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-13 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=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Wed Aug 13 22:33:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 00:33:52 2003 Subject: [Python-bugs-list] [ python-Bugs-701936 ] getsockopt/setsockopt with SO_RCVTIMEO are inconsistent Message-ID: Bugs item #701936, was opened at 2003-03-12 02:54 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701936&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: getsockopt/setsockopt with SO_RCVTIMEO are inconsistent Initial Comment: The SO_RCVTIMEO option to getsockopt/setsockopt seems to vary it's parameter format when used under Linux. With setsockopt, the parameter seems to be a struct of {long seconds, long microseconds}, as you would expect since it's modelling a C "struct timeval". However, with getsockopt, the parameter format seems to be {long seconds, long milliseconds} --- ie. it uses milliseconds rather than microseconds. The attached python script demonstrates this problem. Am I doing something crucially wrong, or is this meant to happen, or ... ? What I'm using: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-08-14 04:33 Message: Logged In: YES user_id=693152 Yes, you're right - the same thing happens with C. Here's the output from sockopt.c on my system: base (len 8) - 12, 345670 default (len 8) - 0, 0 after setsockopt (len 8) - 12, 20 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-25 02:42 Message: Logged In: YES user_id=33168 I just tested this on my box (Redhat 9/Linux 2.4). I get similar results with a C program as Python. (Not sure why I didn't get exactly the same results, but I'm tired.) So I'm not sure Python has a problem, since it is just exposing what is happening in C. Take a look at the C example and try it on your box. What results do you get? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=701936&group_id=5470 From noreply at sourceforge.net Wed Aug 13 22:49:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 00:49:53 2003 Subject: [Python-bugs-list] [ python-Bugs-788378 ] Unsupported 'locale' setting causes Idle to crash on startup Message-ID: Bugs item #788378, was opened at 2003-08-13 16:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Andre Posumentov (aposumentov) >Assigned to: Martin v. L?wis (loewis) Summary: Unsupported 'locale' setting causes Idle to crash on startup Initial Comment: If the 'LANG' environment variable is set to an unsupported value, Idle crashes on startup. The error occurs in IOBinding.py, as follows: Traceback (most recent call last): File "Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "Resources/idle", line 4, in ? import idlelib.PyShell File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/PyShell.py", line 22, in ? from EditorWindow import EditorWindow, fixwordbreaks File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 39, in ? class EditorWindow: File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/IOBinding.py", line 31, in ? locale.setlocale(locale.LC_CTYPE, "") File "/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Here are the offending lines in IOBinding.py: try: import locale locale.setlocale(locale.LC_CTYPE, "") except ImportError: pass As it's not an 'ImportError'... The error is reproducible on Mac OS X 10.2.6, running MacPython-2.3. I have not been able to test on other operating systems. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-13 23:49 Message: Logged In: YES user_id=149084 I suppose the right thing to do here is except (ImportError, locale.Error): Is that correct? I'm going to be away for a few days.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 From noreply at sourceforge.net Wed Aug 13 22:57:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 00:57:50 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 04: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=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Wed Aug 13 22:58:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 00:59:31 2003 Subject: [Python-bugs-list] [ python-Bugs-780887 ] recent-files defaulted to strange place and bad permissions Message-ID: Bugs item #780887, was opened at 2003-07-31 09:48 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lloyd Hugh Allen (lha2) Assigned to: Nobody/Anonymous (nobody) Summary: recent-files defaulted to strange place and bad permissions Initial Comment: After a non-admin install of Python 2.3 with Python 2.2 admin-installed, I got: C:\Python23\Lib\idlelib>c:\python23\python idle.py Traceback (most recent call last): File "idle.py", line 23, in ? idlelib.PyShell.main() File "C:\Python23\lib\idlelib\PyShell.py", line 1277, in main flist.pyshell = PyShell(flist) File "C:\Python23\lib\idlelib\PyShell.py", line 721, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Python23\lib\idlelib\OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "C:\Python23\lib\idlelib\EditorWindow.py", line 181, in __init__ self.UpdateRecentFilesList() File "C:\Python23\lib\idlelib\EditorWindow.py", line 580, in UpdateRecentFilesList RFfile=open(self.recentFilesPath,'r') IOError: [Errno13] Permission denied: 'F:\.idlerc\recent- files.lst' ====== I have a login to a university server, and the F drive is the user drive. I don't recall specifying that anything should be kept on the F drive, and would prefer that recent files be kept on the local machine. Changing my own permissions to .idlerc to allow full permissions, and to apply these permissions to contents, worked and resolved the problem, except that multiple users use the same network drive and will now share recent files. Idle 1.0 under the brand-spanking-new Python2.3, with Windows XP Professional 5.1.2600 Service Pack 1 Build 2600. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-13 23:58 Message: Logged In: YES user_id=149084 What are the vaules of HOME HOMEDRIVE USERPROFILE on your machine? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-03 13:23 Message: Logged In: YES user_id=21627 IDLE first tries %HOME%, then %HOMEDRIVE%/%HOMEPATH% The latter is the system convention, so IDLE should follow it. So setting the HOME environment variable should fix this problem. Is this a sufficient solution? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780887&group_id=5470 From noreply at sourceforge.net Wed Aug 13 23:13:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 01:14:27 2003 Subject: [Python-bugs-list] [ python-Bugs-788526 ] Closing dbenv first bsddb doesn't release locks & segfaults Message-ID: Bugs item #788526, was opened at 2003-08-14 14: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=788526&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Nobody/Anonymous (nobody) Summary: Closing dbenv first bsddb doesn't release locks & segfaults Initial Comment: There is a test code named test_env_close in bsddb/test, but it doesn't test the case thoroughly. There seems to be a bug in closing the db environment first -- the lock is not released, and sometimes it seg-faults. Following is the code that shows this bug. import os from bsddb import db dir,dbname='test_dbenv','test_db' def getDbEnv(dir): try: os.mkdir(dir) except: pass dbenv = db.DBEnv() dbenv.open(dir, db.DB_INIT_CDB| db.DB_CREATE |db.DB_INIT_MPOOL) return dbenv def getDbHandler(db_env,db_name): d = db.DB(dbenv) d.open(db_name, db.DB_BTREE, db.DB_CREATE) return d dbenv=getDbEnv(dir) assert dbenv.lock_stat()['nlocks']==0 d=getDbHandler(dbenv,dbname) assert dbenv.lock_stat()['nlocks']==1 try: dbenv.close() except db.DBError: pass else: assert 0 del d import gc gc.collect() dbenv=getDbEnv(dir) assert dbenv.lock_stat()['nlocks']==0,'number of current locks should be 0' #this fails If you close dbenv before db handler, the lock is not released. Moreover, try this with dbshelve and it segfaults. >>> from bsddb import dbshelve >>> dbenv2=getDbEnv('test_dbenv2') >>> d2=dbshelve.open(dbname,dbenv=dbenv2) >>> try: ... dbenv2.close() ... except db.DBError: ... pass ... else: ... assert 0 ... >>> >>> Exception bsddb._db.DBError: (0, 'DBEnv object has been closed') in Segmentation fault Tested on: 1. linux with Python 2.3 final, Berkeley DB 4.1.25 2. windows xp with Python 2.3 final (with _bsddb that comes along) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788526&group_id=5470 From noreply at sourceforge.net Wed Aug 13 23:39:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 01:40:00 2003 Subject: [Python-bugs-list] [ python-Bugs-785222 ] zlib monotonic test -- false assumptions or bug in zlib.lib Message-ID: Bugs item #785222, was opened at 2003-08-08 09:35 Message generated for change (Comment added) made by prikryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785222&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Petr Prikryl (prikryl) Assigned to: Nobody/Anonymous (nobody) Summary: zlib monotonic test -- false assumptions or bug in zlib.lib Initial Comment: Hi, This bug was observed for Python 2.3c1, but probably is the same in Python 2.3 final. I have discovered (by accident) that the assumption in test_zlib.py, class CompressTestCase, test_monotonic() or build on a false assumption ("higher compression levels should not expand compressed size"), or the zlib version 1.1.4 contains a bug. The test fails when the hamlet_scene sample is modified. Try to remove the empty line from the very beginning of the sample. Then the results for level 2 is better that for level 3 and the result for the level 4 is better than for level 5. The compressed sizes are: level=0, length=245801 level=1, length=5325 level=2, length=4946 level=3, length=6052 level=4, length=2750 level=5, length=2769 level=6, length=2751 level=7, length=2388 level=8, length=2388 level=9, length=2388 Petr ---------------------------------------------------------------------- >Comment By: Petr Prikryl (prikryl) Date: 2003-08-14 07:39 Message: Logged In: YES user_id=771873 I did ask the authors of zlib. It seems that everything is fine except the assumption about "bigger is better" which seems natural at first ;-) The monotonic test should add some comment that it may fail. See below: On Wednesday, August 13, 2003, at 01:45 AM, Petr Prikryl wrote: > My question is: Are the assumptions about the monotonic > results correct? In other words, is the Python test correct, > or is the implementation of the Python wrapper correct > (i.e. of the enclosed C code), or is there a bug in the > implementation of deflate()? [and Mark Adler answered] It's a feature. There is no problem with deflate or with the Python wrapper. The compression results, especially on small files, are not necessarily monotonic with compression level. The compression level determines how hard deflate looks for longer matches. However slightly longer matches do not always improve the compression, since it takes more bits to encode the longer distances back those matches occur. mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785222&group_id=5470 From noreply at sourceforge.net Thu Aug 14 02:17:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 04:18:56 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-14 03:07 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-14 10:17 Message: Logged In: YES user_id=38388 The ASCII codec can't handle non-ASCII characters and that's perfectly normal. Please provide more context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Thu Aug 14 05:37:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 07:40:47 2003 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 11:21 Message generated for change (Comment added) made by mhertha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) Summary: Don't define _SGAPI on IRIX Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Maik Hertha (mhertha) Date: 2003-08-14 13:37 Message: Logged In: YES user_id=768223 I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m on a FUEL 600Mhz. The situation seems a little bit strange on this system. But I have luck and get it compiled. As the current implementation is not clean, my resolution also. Which should be changed to get it work. The manpage for gethostbyaddr_r says: #include #include #include #include So I included this in the __sgi-clause in socketmodule.c. Looking in the header-files shows, that some variables are defined if #define _NO_XOPEN4 1 #define _NO_XOPEN5 1 are set, before the includes. This defines some more variables, so that pyconfig.h should be changed. #define HAVE_ADDRINFO 1 #define HAVE_SOCKADDR_STORAGE 1 Sure there are warnings about the redefinition of the _(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests don't fail. Also my applications run without exception or coredump on FUEL, Octane, Octane 2. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-01 14:10 Message: Logged In: YES user_id=33168 Ralf, I will try to work on this, but it won't be for a week or two probably. Can you tell me which machines (by name) work and doesn't work. The only IRIX machine I seem to know about it rattler. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-01 09:34 Message: Logged In: YES user_id=71407 For the records: The Python2.3 (final) socket module still does not compile under IRIX 6.5.20. It only compiles under 6.5.10. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 20:07 Message: Logged In: YES user_id=31392 I applied a slight variant of Neal's patch and that seemed to fix things. It still seems wrong that we define _SGIAPI, but that will have to wait for 2.3.1. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:54 Message: Logged In: YES user_id=31392 I learned a little about inet_ntop() in the last few minutes. It looks like the size_t argument is an older spelling, and the current POSIX says it should be socklen_t. Regardless, it looks like we're using the new definition when IRIX is actually providing the older definition. Neal attached a patch that looks like it should clean up the problem. Have you tried it? I think a better solution would be to teach configure how to find inet_ntop() via netdb.h, but that's probably too hard to get done in the new couple of hours. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-17 15:42 Message: Logged In: YES user_id=31392 There seem to be two causes of worry. The actual compiler error in your build log and the use of _SGIAPI that Casavanti warns again. It looks like the compiler problems is because our inet_ntop() prototype is wrong. That is Python says the last argument is a socklen_t, but IRIX and Linux man pages both say size_t. Perhaps size_t and socklen_t are different sizes on IRIX, but not on Linux. What happens if you change it to size_t? The problematic code would appear to be these lines from socketmodule.c: #if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #define _SGIAPI 1 #include "netdb.h" #endif It's the only use the _SGIAPI symbol that Casavant says we shouldn't use. What happens if you remove the use _SGIAPI, i.e. just make it #if defined(__sgi) && _COMPILER_VERSION > 700 /* make sure that the reentrant (gethostbyaddr_r etc) functions are declared correctly if compiling with MIPSPro 7.x in ANSI C mode (default) */ #include "netdb.h" #endif ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-17 02:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 00:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" Subject: Re: IRIX & Python Ralf, I read through the sourceforge report. I don't have a sourceforge account so I didn't add there, but feel free to distribute my ramblings. First, they should be very careful about what version of the operating system they are using. Real IPv6 support was only added a few releases ago (6.5.20 I believe, though my memory is hazy). Some of the functions/macros corresponding to IPv6 were introduced prior to that point, but implementation may not have been complete. If they have to play tricks with #define values to get a symbol recongnized it most likely means that SGI didn't intend for that symbol to be used yet. I suspect the problems they are seeing are because they are using some version of IRIX 6.5.x that includes inet_ntoa() definitions under _SGIAPI, but for which real support was not yet complete. The namespace of symbols that begin with a single underscore and a capital letter is reserved for the OS vendors, and the fact that someone is trying to manually insert a definition of _SGIAPI into the source should be a big red warning flag. That said, there is a correct method to deal with the new capabilities of IRIX 6.5.x over time. This comes in two parts. A better explanation is in /usr/include/optional_sym.h First, when a new symbol is added to IRIX, the corresponding header file will always have the following line in it: #pragma optional some_new_symbol The presence of this #pragma will cause the linker to not complain if the symbol is missing when the executable is linked. If SGI neglects to do so it is a bug that should be reported to us. The second part is that calls to these "optional" symbols should be protected by a run-time check to see if the symbol is actually present. Just like this: #include #include . . . if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) { /* New function is present, use it */ qux = some_new_symbol(foo, bar, baz); } else { /* New function isn't present, do something else */ qux = builtin_some_new_symbol(foo, bar, baz); } This ensures that a single executable will be able to function properly (or at least degrade gracefully) on all version of IRIX 6.5.x. In other words you can compile on 6.5.20 and run on 6.5.8, or vice versa. In particular, this means that compile-time detection of features such as inet_ntoa() is incorrect for IRIX 6.5.x -- these decisions should be made at run-time instead. If the decision is made at compile time the executable may well not execute on an older version of IRIX 6.5.x. Unfortunately GNU configure is not equipped to utilize such advanced binary-compatability mechanisms, so there's no "easy" way to get GNU configure'd software to run across all IRIX 6.5.x releases, short of compiling only on the original non-upgraded version of IRIX 6.5. Hope that helps, Brent Casavant On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote: > We are developing a Python-based (www.python.org) application for > IRIX. Until now the Python IRIX port was fully supported, but the last > two beta releases of Python (2.3b1 and 2.3b2) make me increasingly > worried because the crucial socket module (TCP/IP sockets) fails to > build. A while ago I've filed a bug report, but the Python developers > appear to be stuck: > > https://sourceforge.net/tracker/? func=detail&aid=728330&group_id=5470&atid=105470 > > Is there a way to bring this to the attention of developers at SGI to > hopefully get some help? > > Thank you in advance! > Ralf > -- Brent Casavant Silicon Graphics, Inc. Where am I? And what am I IRIX O.S. Engineer http://www.sgi.com/ doing in this handbasket? bcasavan@sgi.com 44.8562N 93.1355W 860F -- Unknown ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-06-30 16:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-22 08:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 01:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 19:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 20:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 14:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply at sourceforge.net Thu Aug 14 05:48:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 07:50:12 2003 Subject: [Python-bugs-list] [ python-Bugs-788378 ] Unsupported 'locale' setting causes Idle to crash on startup Message-ID: Bugs item #788378, was opened at 2003-08-13 21:49 Message generated for change (Comment added) made by aposumentov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Andre Posumentov (aposumentov) Assigned to: Martin v. L?wis (loewis) Summary: Unsupported 'locale' setting causes Idle to crash on startup Initial Comment: If the 'LANG' environment variable is set to an unsupported value, Idle crashes on startup. The error occurs in IOBinding.py, as follows: Traceback (most recent call last): File "Resources/__argvemulator_idle", line 4, in ? execfile(os.path.join(os.path.split(__file__)[0], "idle")) File "Resources/idle", line 4, in ? import idlelib.PyShell File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/PyShell.py", line 22, in ? from EditorWindow import EditorWindow, fixwordbreaks File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 39, in ? class EditorWindow: File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/EditorWindow.py", line 43, in EditorWindow from IOBinding import IOBinding File "/Applications/MacPython-2.3/IDLE.app/ Contents/Resources/idlelib/IOBinding.py", line 31, in ? locale.setlocale(locale.LC_CTYPE, "") File "/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Here are the offending lines in IOBinding.py: try: import locale locale.setlocale(locale.LC_CTYPE, "") except ImportError: pass As it's not an 'ImportError'... The error is reproducible on Mac OS X 10.2.6, running MacPython-2.3. I have not been able to test on other operating systems. ---------------------------------------------------------------------- >Comment By: Andre Posumentov (aposumentov) Date: 2003-08-14 11:48 Message: Logged In: YES user_id=677286 >> except (ImportError, locale.Error): I've tested the change on my system, and it looks good. No crashing on startup, and everything else seems to function as it should. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 04:49 Message: Logged In: YES user_id=149084 I suppose the right thing to do here is except (ImportError, locale.Error): Is that correct? I'm going to be away for a few days.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788378&group_id=5470 From noreply at sourceforge.net Thu Aug 14 06:00:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 08:02:47 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 08:58 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-08-14 04:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 14:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 08:20:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 10:20:15 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 11:58 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 07:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 17:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 08:49:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 10:49:26 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 08:58 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-08-14 06:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 06:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 04:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 14:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 08:58:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 10:58:25 2003 Subject: [Python-bugs-list] [ python-Bugs-784183 ] IDLE does not start for 2.3 on windows. Message-ID: Bugs item #784183, was opened at 2003-08-06 08:39 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start for 2.3 on windows. Initial Comment: For Python 2.3 installed on Windows (well, Windows 2000 anyway, I haven't tested others), a space in the pathname will create an shortcut to IDLE that does not work. To demonstrate the problem: get a fresh Windows 2000 system. Run the Python 2.3 installer. Select "C:/Program Files/Python23" as the install directory. Use default selections for all other installer options. After install, go to Programs menu, select "Python 2.3" > "IDLE (Python GUI)". It will launch a pythonw process, but nothing will appear on the screen. The problem appears to be the space in the pathname. If you create a shortcut with the path spelled out in full (long names not 8-char abreviations) and with quotes around the pathnames that contain spaces, that shortcut will work. I'm not sure what the fix is, but regretably lots of people have Windows and many of them put their applications in "Program Files". In addition to a patch, we should probably put this in a Known Bugs list somewhere where newbies will find it (where is that?). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:58 Message: Logged In: YES user_id=149084 Now works with spaces in path. Fixed at PyShell.py Rev 1.82 Backported to release22-maint ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-08 12:49 Message: Logged In: YES user_id=149084 > If you create a shortcut with the path spelled out in full > (long names not 8-char abreviations) and with quotes > around the pathnames that contain spaces, that > shortcut will work. I haven't been able to make this work. Do you have a shortcut example involving "Program Files" that starts IDLE1.0 correctly? Duplicate of 780451 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 From noreply at sourceforge.net Thu Aug 14 08:59:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 10:59:05 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 00:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-14 10:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Thu Aug 14 09:02:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 11:02:53 2003 Subject: [Python-bugs-list] [ python-Bugs-784183 ] IDLE does not start for 2.3 on windows. Message-ID: Bugs item #784183, was opened at 2003-08-06 09:39 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 Category: Installation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start for 2.3 on windows. Initial Comment: For Python 2.3 installed on Windows (well, Windows 2000 anyway, I haven't tested others), a space in the pathname will create an shortcut to IDLE that does not work. To demonstrate the problem: get a fresh Windows 2000 system. Run the Python 2.3 installer. Select "C:/Program Files/Python23" as the install directory. Use default selections for all other installer options. After install, go to Programs menu, select "Python 2.3" > "IDLE (Python GUI)". It will launch a pythonw process, but nothing will appear on the screen. The problem appears to be the space in the pathname. If you create a shortcut with the path spelled out in full (long names not 8-char abreviations) and with quotes around the pathnames that contain spaces, that shortcut will work. I'm not sure what the fix is, but regretably lots of people have Windows and many of them put their applications in "Program Files". In addition to a patch, we should probably put this in a Known Bugs list somewhere where newbies will find it (where is that?). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-14 11:02 Message: Logged In: YES user_id=31435 Kurt, did you mean "Backported to release22-maint"? release23-maint is more important. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 10:58 Message: Logged In: YES user_id=149084 Now works with spaces in path. Fixed at PyShell.py Rev 1.82 Backported to release22-maint ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-08 13:49 Message: Logged In: YES user_id=149084 > If you create a shortcut with the path spelled out in full > (long names not 8-char abreviations) and with quotes > around the pathnames that contain spaces, that > shortcut will work. I haven't been able to make this work. Do you have a shortcut example involving "Program Files" that starts IDLE1.0 correctly? Duplicate of 780451 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 From noreply at sourceforge.net Thu Aug 14 09:03:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 11:03:27 2003 Subject: [Python-bugs-list] [ python-Bugs-784183 ] IDLE does not start for 2.3 on windows. Message-ID: Bugs item #784183, was opened at 2003-08-06 08:39 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 Category: Installation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Chermside (mcherm) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not start for 2.3 on windows. Initial Comment: For Python 2.3 installed on Windows (well, Windows 2000 anyway, I haven't tested others), a space in the pathname will create an shortcut to IDLE that does not work. To demonstrate the problem: get a fresh Windows 2000 system. Run the Python 2.3 installer. Select "C:/Program Files/Python23" as the install directory. Use default selections for all other installer options. After install, go to Programs menu, select "Python 2.3" > "IDLE (Python GUI)". It will launch a pythonw process, but nothing will appear on the screen. The problem appears to be the space in the pathname. If you create a shortcut with the path spelled out in full (long names not 8-char abreviations) and with quotes around the pathnames that contain spaces, that shortcut will work. I'm not sure what the fix is, but regretably lots of people have Windows and many of them put their applications in "Program Files". In addition to a patch, we should probably put this in a Known Bugs list somewhere where newbies will find it (where is that?). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 10:03 Message: Logged In: YES user_id=149084 um, release23-maint ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 10:02 Message: Logged In: YES user_id=31435 Kurt, did you mean "Backported to release22-maint"? release23-maint is more important. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:58 Message: Logged In: YES user_id=149084 Now works with spaces in path. Fixed at PyShell.py Rev 1.82 Backported to release22-maint ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-08 12:49 Message: Logged In: YES user_id=149084 > If you create a shortcut with the path spelled out in full > (long names not 8-char abreviations) and with quotes > around the pathnames that contain spaces, that > shortcut will work. I haven't been able to make this work. Do you have a shortcut example involving "Program Files" that starts IDLE1.0 correctly? Duplicate of 780451 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784183&group_id=5470 From noreply at sourceforge.net Thu Aug 14 09:21:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 11:21:09 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 11:58 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 10:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 09:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 07:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 17:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 10:06:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 12:06:52 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 08:58 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-08-14 08:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 07:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 06:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 06:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 04:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 14:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 10:39:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 12:39:11 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 11:58 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 11:39 Message: Logged In: YES user_id=149084 Oh, big differences: Without the -n switch, which makes IDLE act like the 2.2 version, IDLE starts up an execution server subprocess which then connects to the user's GUI. This subprocess is restarted every time the user does a Run/F5 or a Shell/Restart Shell. There are other major differences. The IDLE in 2.3 is the version developed on the IDLEfork project at Sourceforge. It sounds like you are getting farther than Duane Kaufman. I wonder if he was seeing the initial message in the shell window like you are. Do you see the menus? Well, gotta go :-) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 11:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 10:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 09:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 07:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 17:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 10:47:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 12:47:55 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 08:58 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-08-14 08:47 Message: Logged In: YES user_id=86216 > It sounds like you are getting farther than Duane > Kaufman. I don't think so. AFAICT, we are observing the same behavior. > I wonder if he was seeing the initial message in the > shell window like you are. My WAG is yes. Duane, please confirm. > Do you see the menus? No. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 08:39 Message: Logged In: YES user_id=149084 Oh, big differences: Without the -n switch, which makes IDLE act like the 2.2 version, IDLE starts up an execution server subprocess which then connects to the user's GUI. This subprocess is restarted every time the user does a Run/F5 or a Shell/Restart Shell. There are other major differences. The IDLE in 2.3 is the version developed on the IDLEfork project at Sourceforge. It sounds like you are getting farther than Duane Kaufman. I wonder if he was seeing the initial message in the shell window like you are. Do you see the menus? Well, gotta go :-) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 08:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 07:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 06:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 06:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 04:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 14:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 10:53:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 12:53:09 2003 Subject: [Python-bugs-list] [ python-Bugs-786827 ] IDLE starts with no menus (Cygwin build of python2.3) Message-ID: Bugs item #786827, was opened at 2003-08-11 11:58 Message generated for change (Comment added) made by duanekaufman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Duane Kaufman (duanekaufman) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE starts with no menus (Cygwin build of python2.3) Initial Comment: When started from a Cygwin window (duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py) The IDLE window has no menus. If started as: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ /usr/lib/python2.3/idlelib/idle.py -n (no subprocess) the menus are present. Starting Python: duane@USD22C821 /cygdrive/d/my_python/Cygwin_test $ python Python 2.3 (#1, Aug 1 2003, 15:01:23) [GCC 3.2 20020927 (prerelease)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> Win2k SP2 Duane Kaufman duane.kaufman@med.ge.com ---------------------------------------------------------------------- >Comment By: Duane Kaufman (duanekaufman) Date: 2003-08-14 11:53 Message: Logged In: YES user_id=574999 I am seeing the same behavior, and do _not_ see menus when started with a sub-process. Duane ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 11:47 Message: Logged In: YES user_id=86216 > It sounds like you are getting farther than Duane > Kaufman. I don't think so. AFAICT, we are observing the same behavior. > I wonder if he was seeing the initial message in the > shell window like you are. My WAG is yes. Duane, please confirm. > Do you see the menus? No. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 11:39 Message: Logged In: YES user_id=149084 Oh, big differences: Without the -n switch, which makes IDLE act like the 2.2 version, IDLE starts up an execution server subprocess which then connects to the user's GUI. This subprocess is restarted every time the user does a Run/F5 or a Shell/Restart Shell. There are other major differences. The IDLE in 2.3 is the version developed on the IDLEfork project at Sourceforge. It sounds like you are getting farther than Duane Kaufman. I wonder if he was seeing the initial message in the shell window like you are. Do you see the menus? Well, gotta go :-) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 11:06 Message: Logged In: YES user_id=86216 > what bug are you thinking of? Nothing in particular. However, experience has taught me to consider Cygwin bugs when porting to Cygwin... Anyway, I just found a difference between Python 2.2.3 and 2.3 after starting IDLE. Under 2.2.3: $ ps | fgrep python 3308 1400 3308 3092 0 19695 11:57:56 /home/jt/src/python-2.2.3-2/python Under 2.3: $ ps | fgrep python 2244 1400 2244 2864 0 19695 12:02:57 /usr/bin/python2.3 700 2244 2244 3592 0 19695 12:02:58 /usr/bin/python2.3 Note one python process under 2.2.3 and two under 2.3. This may explain why IDLE works under 2.2.3 and not. Were there major IDLE changes between 2.2.3 and 2.3? If so, what? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 10:21 Message: Logged In: YES user_id=149084 Well, that's peculiar. So the subprocess is starting up ok but the menus aren't posted. Now I'm thinking a TK problem -- what bug are you thinking of? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 09:49 Message: Logged In: YES user_id=86216 kbk> There are no error messages in the kbk> shell window? No, the shell window just looks like the following: Python 2.3 (#1, Aug 5 2003, 09:49:11) [GCC 3.2 20020927 (prerelease)] on cygwin Type "copyright", "credits" or "license()" for more information. ********************************************** ****************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ********************************************** ****************** IDLE 1.0 >>> And appears to work, until one types "^D", then it hangs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-08-14 09:20 Message: Logged In: YES user_id=149084 It appears that IDLE can't start its subprocess. I have a patch in process that will give proper error messages and timeouts under that condition, at least giving the user a notice about the failure. Then there is the question why the subprocess doesn't start under Cygwin. There are no error messages in the shell window? I'm going to be away for a few days myself. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-14 07:00 Message: Logged In: YES user_id=86216 I would like to assign this (at least temporarily) to Kurt for the following reasons: 1. I will be off-net for a while 2. I am not very familiar with Tkinter 3. I am not very familiar with IDLE 4. IDLE works fine under Python 2.2.3 with the identical underlying software (e.g, Cygwin, Tcl/Tk, etc.) However, IDLE under Python 2.3 could be tickling YA Cygwin bug... I will check in when I'm back... Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-13 17:38 Message: Logged In: YES user_id=33168 Jason, if you can't help can you assign to Kurt (kbk)? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=786827&group_id=5470 From noreply at sourceforge.net Thu Aug 14 14:31:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Aug 14 16:31:59 2003 Subject: [Python-bugs-list] [ python-Bugs-788931 ] resolving relative paths for external entities with xml.sax Message-ID: Bugs item #788931, was opened at 2003-08-14 22: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=788931&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bart Vanhaute (bartvh) Assigned to: Nobody/Anonymous (nobody) Summary: resolving relative paths for external entities with xml.sax Initial Comment: [This is a copy of a message posted on comp.lang.python for which I did not see any response. After some reflection, I began to see it as a bug in python, so here is the bug report.] I have a set of XML documents that use external entity definitions for which I am having problems parsing them using python and xml.sax. The problem is with the resolution of relative paths in these. An example: dir1/test.xml: &ent; dir2/test.dtd: dir2/test.inc: external entity test >From what I understand of XML specs, relative paths in external entities are relative to the location of the document *in which they are defined*. However, using xml.sax (which calls expat, I presume), the paths are resolved relative to the current working directory. So the parser can not find the test.inc when the current working directory is e.g. dir1. I do not see how creating an EntityResolver would help here: how do I know against what base path I have to resolve the entity? (the same thing can be read without problems with other xml parser, for instance in Java). Bart. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788931&group_id=5470 From noreply at sourceforge.net Fri Aug 15 04:39:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 06:39:16 2003 Subject: [Python-bugs-list] [ python-Bugs-789159 ] Minor floatobject.c bug Message-ID: Bugs item #789159, was opened at 2003-08-15 10: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=789159&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Minor floatobject.c bug Initial Comment: The following is a previously reported bug that got only half fixed. The bug was closed before I could respond that the fix was incomplete; here is a complete fix. The failure is when overflow checking is enabled on integers, as is good programming practice and permitted by the C standard. It could also cause wrong answers if overflow is mishandled (as is also permitted and can happen). *** ./Objects/floatobject.c.org Tue Jan 28 19:40:35 2003 --- ./Objects/floatobject.c Tue Jun 3 13:02:48 2003 *************** *** 659,667 **** to long may yield gibberish in either case. What really matters is whether converting back to double again reproduces what we started with. */ ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } --- 659,669 ---- to long may yield gibberish in either case. What really matters is whether converting back to double again reproduces what we started with. */ ! if (wholepart > LONG_MIN-1.0 && wholepart < LONG_MAX+1.0) { ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); ! } PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470 From noreply at sourceforge.net Fri Aug 15 06:44:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 08:45:22 2003 Subject: [Python-bugs-list] [ python-Bugs-789159 ] Minor floatobject.c bug Message-ID: Bugs item #789159, was opened at 2003-08-15 06:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Minor floatobject.c bug Initial Comment: The following is a previously reported bug that got only half fixed. The bug was closed before I could respond that the fix was incomplete; here is a complete fix. The failure is when overflow checking is enabled on integers, as is good programming practice and permitted by the C standard. It could also cause wrong answers if overflow is mishandled (as is also permitted and can happen). *** ./Objects/floatobject.c.org Tue Jan 28 19:40:35 2003 --- ./Objects/floatobject.c Tue Jun 3 13:02:48 2003 *************** *** 659,667 **** to long may yield gibberish in either case. What really matters is whether converting back to double again reproduces what we started with. */ ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } --- 659,669 ---- to long may yield gibberish in either case. What really matters is whether converting back to double again reproduces what we started with. */ ! if (wholepart > LONG_MIN-1.0 && wholepart < LONG_MAX+1.0) { ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); ! } PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 08:44 Message: Logged In: YES user_id=33168 Nick, if we do close a bug, you can still make comments and we'll see it. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470 From noreply at sourceforge.net Fri Aug 15 06:51:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 08:54:49 2003 Subject: [Python-bugs-list] [ python-Bugs-779825 ] plistlib and bundlebuilder not in the documentation Message-ID: Bugs item #779825, was opened at 2003-07-29 22:04 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Just van Rossum (jvr) Summary: plistlib and bundlebuilder not in the documentation Initial Comment: These two modules are not in the module reference (neither in the generic version, nor in the mac-specific version). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-15 14:51 Message: Logged In: YES user_id=45365 I would suggest actually documenting them. It isn't all *that* much work (the docstrings have most what is needed). If you're uncomfortable with the latex-mumbo-jumbo just write the flat text (but please structure it correctly), attach to this bug, reassign to me and I'll add the magic. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-08-13 16:32 Message: Logged In: YES user_id=92689 Assinging over to Jack to get advice what to do. Should I initially list them in undoc.tex? Feel free to assign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 From noreply at sourceforge.net Fri Aug 15 06:58:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 08:59:04 2003 Subject: [Python-bugs-list] [ python-Bugs-782686 ] IDE defaults to Mac linefeeds Message-ID: Bugs item #782686, was opened at 2003-08-04 10:34 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782686&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE defaults to Mac linefeeds Initial Comment: The IDE defaults to Mac linefeeds for new files, also in MacPython-OSX. In PyEdit.Editor.__init__ the logic for initializing self._eoln is fishy, and also incorrect. It should probably use "rU" for reading the files and use f.newlines to initialize it. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-15 14:58 Message: Logged In: YES user_id=45365 Look at where _eoln is set in __init__: in the "if not path" leg it's set to os.linesep, in the other leg of the if it isn't set. Then just below that it's overwritten in the if '\n' in text. I think the second block should go, and the else part of the if not path should use open("rU") and inspect f.newlines (defaulting to os.linesep if f.newlines is None or a tuple). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-08-13 16:36 Message: Logged In: YES user_id=92689 Can you elaborate on the "incorrect" bit? I agree with the need to switch to "rU". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=782686&group_id=5470 From noreply at sourceforge.net Fri Aug 15 08:18:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 10:18:30 2003 Subject: [Python-bugs-list] [ python-Bugs-789262 ] __getattr__ and metaclasses Message-ID: Bugs item #789262, was opened at 2003-08-15 14: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=789262&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gon?alo Rodrigues (grodr) Assigned to: Nobody/Anonymous (nobody) Summary: __getattr__ and metaclasses Initial Comment: This came out from a thread in comp.lang.python: Here?s the reference: http://groups.google.pt/groups?hl=pt-PT&lr=&ie=UTF- 8&threadm=md94jvccu02b9dv5890k34629rkot79roj% 404ax.com&rnum=6&prev=/groups%3Fq%3Dgon%25C3% 25A7alo%2Brodrigues%2Bgroup:comp.lang.python.*% 26hl%3Dpt-PT%26lr%3D%26ie%3DUTF-8%26group% 3Dcomp.lang.python.*%26selm% 3Dmd94jvccu02b9dv5890k34629rkot79roj% 25404ax.com%26rnum%3D6 Consider the following example (provided by M. Simionato) >>> class M(type): ... def __getattr__(self, name): ... if name == '__iter__': ... return lambda self: iter([]) ... >>> class C(object): ... __metaclass__ = M ... >>> C.__iter__ at 0x0110E8F0> >>> c = C() >>> iter(c) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence >>> This means that the iterator machinery does not check __getattr__ (or __getattribute__ for that matter ? I have made the test). The Language Reference says: ?A class can implement certain operations that are invoked by special syntax (such as arithmetic operations or subscripting and slicing) by defining methods with special names.? Which does not throw much light on the matter at hand. So there are two ways we can view the above: (A) It?s a bug. This is the one I favour ;-). Arguing by contradiction, not being considered a bug means that there is a very special distinction being made when it comes to attribute lookup of special names. I tend to follow the Gang of Four?s main injunction ?Prefer composition to inheritance?. Composition is great in Python precisely because of the __getattr__ hook. Not being able to use __getattr__ in metaclasses to trap special names surely hampers that role somewhat. (B) It?s not a bug. Then at least I think that the documentation should be worded more accurately. Quoting A. Martelli on the same thread ?__getattr__ is not a BINDING of the special method, though it may be considered a DEFINITION of it, which is why the current phrase in the Language Reference is not 100% correct and complete -- only 99.44%, and I agree that the remaining 0.56% _is_ a delicate defect in the documentation.? With my best regards, G. Rodrigues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789262&group_id=5470 From noreply at sourceforge.net Fri Aug 15 09:08:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 11:08:28 2003 Subject: [Python-bugs-list] [ python-Bugs-789159 ] Minor floatobject.c bug Message-ID: Bugs item #789159, was opened at 2003-08-15 10:39 Message generated for change (Comment added) made by nmm1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Minor floatobject.c bug Initial Comment: The following is a previously reported bug that got only half fixed. The bug was closed before I could respond that the fix was incomplete; here is a complete fix. The failure is when overflow checking is enabled on integers, as is good programming practice and permitted by the C standard. It could also cause wrong answers if overflow is mishandled (as is also permitted and can happen). *** ./Objects/floatobject.c.org Tue Jan 28 19:40:35 2003 --- ./Objects/floatobject.c Tue Jun 3 13:02:48 2003 *************** *** 659,667 **** to long may yield gibberish in either case. What really matters is whether converting back to double again reproduces what we started with. */ ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } --- 659,669 ---- to long may yield gibberish in either case. What really matters is whether converting back to double again reproduces what we started with. */ ! if (wholepart > LONG_MIN-1.0 && wholepart < LONG_MAX+1.0) { ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); ! } PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679 ---------------------------------------------------------------------- >Comment By: Nick Maclaren (nmm1) Date: 2003-08-15 15:08 Message: Logged In: YES user_id=652073 Thanks for the remark about closing. I tried to append, but Sourceforge wouldn't let me. It is all a while ago now, though. Heck. I remember the discussion. That has problems when rounding gets in the way. The following is an improved fix and SHOULD work on all machines, past, present and future that support standard C and used a power of two base floating-point (or base 10, actually): *** floatobject.c.org Tue Jan 28 19:40:35 2003 --- floatobject.c Fri Aug 15 15:22:48 2003 *************** *** 645,667 **** { double x = PyFloat_AsDouble(v); double wholepart; /* integral portion of x, rounded toward 0 */ ! long aslong; /* (long)wholepart */ (void)modf(x, &wholepart); - #ifdef RISCOS - /* conversion from floating to integral type would raise exception */ - if (wholepart>LONG_MAX || wholepart LONG_MIN/2 && wholepart < LONG_MAX/2) ! x = 0.0; ! else { ! k = (x >= 0.0); ! x = wholepart; ! for (i = (sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) { ! z = LONG_MAX; ! for (j = 0; j < i; ++j) z >>= 16; ! x -= (k ? 1.0 : -1.0)*ldexp(z&0xffff,16*i); ! } ! if (! k) x = (LONG_MAX+LONG_MIN)-x; ! } ! if (x <= 0.0) { ! aslong = (long)wholepart; ! if ((double)aslong == wholepart) ! return PyInt_FromLong(aslong); ! } PyErr_SetString(PyExc_OverflowError, "float too large to convert"); return NULL; } I have tested it, but don't know the internals well enough to test it exhaustively. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 12:44 Message: Logged In: YES user_id=33168 Nick, if we do close a bug, you can still make comments and we'll see it. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789159&group_id=5470 From noreply at sourceforge.net Fri Aug 15 09:15:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 11:16:04 2003 Subject: [Python-bugs-list] [ python-Bugs-789290 ] Minor FP bug in object.c Message-ID: Bugs item #789290, was opened at 2003-08-15 15:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Minor FP bug in object.c Initial Comment: This is closely related to the one I have reported in floatobject.c (789159). VERY closely. It is shown up by the following test on a machine with 64-bit longs and floating-point trapping turned on (though it might show up as bogus results even with no trapping): print int( 9223372036854775200.0) print int( 9223372036854775800.0) print int(-9223372036854776800.0) print int(-9223372036854777000.0) 958,959c958,959 < double intpart, fractpart; < int expo; --- > double intpart, fractpart, z; > int expo, i, j; 978c978,989 < if (intpart > LONG_MAX || -intpart > LONG_MAX) { --- > /* Remember that (double)LONG_MAX can round either way. */ > if (intpart > LONG_MIN/2 && intpart < LONG_MAX/2) > z = 0.0; > else { > z = (intpart >= 0.0 ? intpart : -intpart); > for (i = (sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) { > x = LONG_MAX; > for (j = 0; j < i; ++j) x >>= 16; > z -= ldexp(x&0xffff,16*i); > } > } > if (z > 0.0) { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470 From noreply at sourceforge.net Fri Aug 15 09:24:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 11:24:16 2003 Subject: [Python-bugs-list] [ python-Bugs-789294 ] Solaris Forte 7 &8 bug in test_long Message-ID: Bugs item #789294, was opened at 2003-08-15 15: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=789294&group_id=5470 Category: Python Interpreter Core Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nick Maclaren (nmm1) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris Forte 7 &8 bug in test_long Initial Comment: Python 2.2.3 This is for information. It is a bug in Sun's Forte 7 and 8 compiler suite, very unlikely to affect most people, and I am pursuing it at low priority with Sun. I am reporting it as it will cause the tests to fail if anyone switches floating-point trapping on. In PyFloat_FromString in floatobject.c, there is a call to strtod. In test_long, this is supplied with a huge argument. Sun have misunderstood C99 (puke) to state that the wording in Annex F requires strtod to raise an exception if it overflows, and have again misunderstood C99 to mean that implies SIGFPE if trapping is on. I don't blame them for getting confused, but their interpretation is wrong - or, at least that what was stated when C99 was in draft! Generically, we can expect to see more vendors get confused by C99, and especially by the horrible floating-point changes. Yuck. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789294&group_id=5470 From noreply at sourceforge.net Fri Aug 15 12:15:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 14:15:31 2003 Subject: [Python-bugs-list] [ python-Bugs-789397 ] webbrowser hangs finder on ftp links Message-ID: Bugs item #789397, was opened at 2003-08-15 11:15 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=789397&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: webbrowser hangs finder on ftp links Initial Comment: On MacOS X 10.2.6, running either unix python 2.2.2 or MacPython (aqua framework) 2.3, the following hangs my Finder. This seems to be a permanent hang; waiting 1/2 hour did nothing. pythonw >>>import webbrowser >>>url = "ftp://acct:@machine/dir/image.fits" >>>w.open(url) The first time I'm asked for where to download the file (by a Finder"Choose a Folder" dialog box) and a blank file is downloaded. My password is never asked for, but it's in the keychain so maybe that's why. The second time the Finder simply hangs. Even waiting 1/2 hour doesn't do anything. I have to force quit it. Adding ;type=i to the url makes no difference (I'd prefer to download it as an explicit binary, but tried the simpler url to see if that helped). I also have unix Python 2.2.2 installed. Same story. In neither case is my web browser ever opened. webbrowser.open works just fine on http: urls (except the known problem that the anchor specification, e.g. #..., is ignored). Also, anonymous ftp of text files does seem to work (again, using the finder and having it ask for the destination each time; I'd really like to make my web browser do the downloading as it has a much nicer download status window!). I'm happy to provide a working url, account and password to anybody trying to solve this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 From noreply at sourceforge.net Fri Aug 15 12:23:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 14:25:41 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 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=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Nobody/Anonymous (nobody) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Fri Aug 15 14:07:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 16:07:45 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 14:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: David Lambert (jdalambert) >Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 16:07 Message: Logged In: YES user_id=33168 Wow, it sure does leak! Checked in as: Objects/fileobject.c 2.180 Still needs a test. Leaving open until I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Fri Aug 15 15:16:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 17:16:41 2003 Subject: [Python-bugs-list] [ python-Bugs-789519 ] CSV reader does not parse Mac line endings Message-ID: Bugs item #789519, was opened at 2003-08-15 21: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=789519&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (lmeyn) Assigned to: Nobody/Anonymous (nobody) Summary: CSV reader does not parse Mac line endings Initial Comment: #Test code: import csv import traceback class excel_mac(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_mac", excel_mac) class excel_unix(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\n' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_unix", excel_unix) testdata = range(10) for dialect in ["excel","excel_unix","excel_mac"]: try: print '\n Testing dialect "%s"' % dialect test = file('test.csv','w') writer = csv.writer(test,dialect=dialect) for i in range(3): writer.writerow(testdata) test.close() test = file('test.csv','r') reader = csv.reader(test,dialect=dialect) for row in reader: print row except: traceback.print_exc() #Results """ Testing dialect "excel" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_unix" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_mac" Traceback (most recent call last): File "/Users/lmeyn/Desktop/testcsv.py", line 36, in ? print row Error: newline inside string """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 From noreply at sourceforge.net Fri Aug 15 15:57:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 17:57:58 2003 Subject: [Python-bugs-list] [ python-Bugs-789397 ] webbrowser hangs finder on ftp links Message-ID: Bugs item #789397, was opened at 2003-08-15 11:15 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: webbrowser hangs finder on ftp links Initial Comment: On MacOS X 10.2.6, running either unix python 2.2.2 or MacPython (aqua framework) 2.3, the following hangs my Finder. This seems to be a permanent hang; waiting 1/2 hour did nothing. pythonw >>>import webbrowser >>>url = "ftp://acct:@machine/dir/image.fits" >>>w.open(url) The first time I'm asked for where to download the file (by a Finder"Choose a Folder" dialog box) and a blank file is downloaded. My password is never asked for, but it's in the keychain so maybe that's why. The second time the Finder simply hangs. Even waiting 1/2 hour doesn't do anything. I have to force quit it. Adding ;type=i to the url makes no difference (I'd prefer to download it as an explicit binary, but tried the simpler url to see if that helped). I also have unix Python 2.2.2 installed. Same story. In neither case is my web browser ever opened. webbrowser.open works just fine on http: urls (except the known problem that the anchor specification, e.g. #..., is ignored). Also, anonymous ftp of text files does seem to work (again, using the finder and having it ask for the destination each time; I'd really like to make my web browser do the downloading as it has a much nicer download status window!). I'm happy to provide a working url, account and password to anybody trying to solve this problem. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-08-15 14:57 Message: Logged In: YES user_id=431773 Unfortunately, once again this proves to be a bug in Apple's code. The open command in terminal exhibits the same behavior. The important points are that the file must be password-protected and the url must not include the password (if one supplies the password then the download works fine). It's a pity that webbrowser is dependent on apple's horrible broken open command (or whatever underlies it), but I don't see any obvious alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 From noreply at sourceforge.net Fri Aug 15 16:07:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 18:07:29 2003 Subject: [Python-bugs-list] [ python-Bugs-789545 ] zappyfiles.py absent from MacPython binary Message-ID: Bugs item #789545, was opened at 2003-08-15 15: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=789545&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: zappyfiles.py absent from MacPython binary Initial Comment: zappyfiles.py and some other useful scripts are not included in the MacPython 2.3 installed by the binary installer. I some other mac-specific add-ons (in Mac/scripts and other Mac/... subdirectories) are worth installing, also, e.g. in a Mac-specific area of MacPython/Extras. In the case of zappyfiles.py, it should run fine as a command-line tool on any platform (though it only shows a folder dialog on MacOS X; somebody may eventually want to add that feature for other platforms but it doesn't have to be us). So it may be worth simply moving that into the main Tools/scripts folder, where everybody can see it and your Mac installer will presumably pick it up automatically. -- Russell ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789545&group_id=5470 From noreply at sourceforge.net Fri Aug 15 16:08:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 18:09:05 2003 Subject: [Python-bugs-list] [ python-Bugs-789397 ] webbrowser hangs finder on ftp links Message-ID: Bugs item #789397, was opened at 2003-08-15 11:15 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: webbrowser hangs finder on ftp links Initial Comment: On MacOS X 10.2.6, running either unix python 2.2.2 or MacPython (aqua framework) 2.3, the following hangs my Finder. This seems to be a permanent hang; waiting 1/2 hour did nothing. pythonw >>>import webbrowser >>>url = "ftp://acct:@machine/dir/image.fits" >>>w.open(url) The first time I'm asked for where to download the file (by a Finder"Choose a Folder" dialog box) and a blank file is downloaded. My password is never asked for, but it's in the keychain so maybe that's why. The second time the Finder simply hangs. Even waiting 1/2 hour doesn't do anything. I have to force quit it. Adding ;type=i to the url makes no difference (I'd prefer to download it as an explicit binary, but tried the simpler url to see if that helped). I also have unix Python 2.2.2 installed. Same story. In neither case is my web browser ever opened. webbrowser.open works just fine on http: urls (except the known problem that the anchor specification, e.g. #..., is ignored). Also, anonymous ftp of text files does seem to work (again, using the finder and having it ask for the destination each time; I'd really like to make my web browser do the downloading as it has a much nicer download status window!). I'm happy to provide a working url, account and password to anybody trying to solve this problem. ---------------------------------------------------------------------- >Comment By: Russell Owen (reowen) Date: 2003-08-15 15:08 Message: Logged In: YES user_id=431773 I did formally report the bug in open to Apple. Sorry I forgot to mention that last time. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-08-15 14:57 Message: Logged In: YES user_id=431773 Unfortunately, once again this proves to be a bug in Apple's code. The open command in terminal exhibits the same behavior. The important points are that the file must be password-protected and the url must not include the password (if one supplies the password then the download works fine). It's a pity that webbrowser is dependent on apple's horrible broken open command (or whatever underlies it), but I don't see any obvious alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 From noreply at sourceforge.net Fri Aug 15 16:08:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 18:09:26 2003 Subject: [Python-bugs-list] [ python-Bugs-789397 ] webbrowser hangs finder on ftp links Message-ID: Bugs item #789397, was opened at 2003-08-15 20:15 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: webbrowser hangs finder on ftp links Initial Comment: On MacOS X 10.2.6, running either unix python 2.2.2 or MacPython (aqua framework) 2.3, the following hangs my Finder. This seems to be a permanent hang; waiting 1/2 hour did nothing. pythonw >>>import webbrowser >>>url = "ftp://acct:@machine/dir/image.fits" >>>w.open(url) The first time I'm asked for where to download the file (by a Finder"Choose a Folder" dialog box) and a blank file is downloaded. My password is never asked for, but it's in the keychain so maybe that's why. The second time the Finder simply hangs. Even waiting 1/2 hour doesn't do anything. I have to force quit it. Adding ;type=i to the url makes no difference (I'd prefer to download it as an explicit binary, but tried the simpler url to see if that helped). I also have unix Python 2.2.2 installed. Same story. In neither case is my web browser ever opened. webbrowser.open works just fine on http: urls (except the known problem that the anchor specification, e.g. #..., is ignored). Also, anonymous ftp of text files does seem to work (again, using the finder and having it ask for the destination each time; I'd really like to make my web browser do the downloading as it has a much nicer download status window!). I'm happy to provide a working url, account and password to anybody trying to solve this problem. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-16 00:08 Message: Logged In: YES user_id=45365 I cannot repeat this, because on all my machines I've set the "ftp:" handler to be something else than the finder (either Interarchie or some webbrowser or something). And the reason I've done this is because the finder has consistently hung on me when I tried to open ftp: url's (with Python not involved). So I'm tempted to close this as a third-party bug (in the finder). But: maybe you should first ask on the pythonmac-sig about other people's experiences with this. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-08-16 00:08 Message: Logged In: YES user_id=431773 I did formally report the bug in open to Apple. Sorry I forgot to mention that last time. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-08-15 23:57 Message: Logged In: YES user_id=431773 Unfortunately, once again this proves to be a bug in Apple's code. The open command in terminal exhibits the same behavior. The important points are that the file must be password-protected and the url must not include the password (if one supplies the password then the download works fine). It's a pity that webbrowser is dependent on apple's horrible broken open command (or whatever underlies it), but I don't see any obvious alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 From noreply at sourceforge.net Fri Aug 15 16:10:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 18:11:08 2003 Subject: [Python-bugs-list] [ python-Bugs-789397 ] webbrowser hangs finder on ftp links Message-ID: Bugs item #789397, was opened at 2003-08-15 20:15 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 Category: Macintosh >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: webbrowser hangs finder on ftp links Initial Comment: On MacOS X 10.2.6, running either unix python 2.2.2 or MacPython (aqua framework) 2.3, the following hangs my Finder. This seems to be a permanent hang; waiting 1/2 hour did nothing. pythonw >>>import webbrowser >>>url = "ftp://acct:@machine/dir/image.fits" >>>w.open(url) The first time I'm asked for where to download the file (by a Finder"Choose a Folder" dialog box) and a blank file is downloaded. My password is never asked for, but it's in the keychain so maybe that's why. The second time the Finder simply hangs. Even waiting 1/2 hour doesn't do anything. I have to force quit it. Adding ;type=i to the url makes no difference (I'd prefer to download it as an explicit binary, but tried the simpler url to see if that helped). I also have unix Python 2.2.2 installed. Same story. In neither case is my web browser ever opened. webbrowser.open works just fine on http: urls (except the known problem that the anchor specification, e.g. #..., is ignored). Also, anonymous ftp of text files does seem to work (again, using the finder and having it ask for the destination each time; I'd really like to make my web browser do the downloading as it has a much nicer download status window!). I'm happy to provide a working url, account and password to anybody trying to solve this problem. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-16 00:10 Message: Logged In: YES user_id=45365 Oops, sorry, I missed your own followups before typing in mine. So: we agree, and I'm closing the bug. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-16 00:08 Message: Logged In: YES user_id=45365 I cannot repeat this, because on all my machines I've set the "ftp:" handler to be something else than the finder (either Interarchie or some webbrowser or something). And the reason I've done this is because the finder has consistently hung on me when I tried to open ftp: url's (with Python not involved). So I'm tempted to close this as a third-party bug (in the finder). But: maybe you should first ask on the pythonmac-sig about other people's experiences with this. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-08-16 00:08 Message: Logged In: YES user_id=431773 I did formally report the bug in open to Apple. Sorry I forgot to mention that last time. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-08-15 23:57 Message: Logged In: YES user_id=431773 Unfortunately, once again this proves to be a bug in Apple's code. The open command in terminal exhibits the same behavior. The important points are that the file must be password-protected and the url must not include the password (if one supplies the password then the download works fine). It's a pity that webbrowser is dependent on apple's horrible broken open command (or whatever underlies it), but I don't see any obvious alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789397&group_id=5470 From noreply at sourceforge.net Fri Aug 15 20:02:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 15 22:03:02 2003 Subject: [Python-bugs-list] [ python-Bugs-789519 ] CSV reader does not parse Mac line endings Message-ID: Bugs item #789519, was opened at 2003-08-15 16:16 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (lmeyn) >Assigned to: Skip Montanaro (montanaro) Summary: CSV reader does not parse Mac line endings Initial Comment: #Test code: import csv import traceback class excel_mac(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_mac", excel_mac) class excel_unix(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\n' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_unix", excel_unix) testdata = range(10) for dialect in ["excel","excel_unix","excel_mac"]: try: print '\n Testing dialect "%s"' % dialect test = file('test.csv','w') writer = csv.writer(test,dialect=dialect) for i in range(3): writer.writerow(testdata) test.close() test = file('test.csv','r') reader = csv.reader(test,dialect=dialect) for row in reader: print row except: traceback.print_exc() #Results """ Testing dialect "excel" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_unix" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_mac" Traceback (most recent call last): File "/Users/lmeyn/Desktop/testcsv.py", line 36, in ? print row Error: newline inside string """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 From noreply at sourceforge.net Sat Aug 16 02:29:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 16 04:29:40 2003 Subject: [Python-bugs-list] [ python-Bugs-789667 ] struct.calcsize("5BH") gives wrong result Message-ID: Bugs item #789667, was opened at 2003-08-16 11: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=789667&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sinitsyn Valentine (valentine) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize("5BH") gives wrong result Initial Comment: Consider the following program: import struct print struct.calcsize("5BH") print struct.calcsize("6BH") One could expect that the ouptut of this program will consist of two different numbers, 7 and 8. But this is not the case: the program prints 8 and 8. This prevents my Python 2.3 for Windows from unpacking strings using "5BH" format properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789667&group_id=5470 From noreply at sourceforge.net Sat Aug 16 08:11:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 16 10:11:39 2003 Subject: [Python-bugs-list] [ python-Bugs-789667 ] struct.calcsize("5BH") gives wrong result Message-ID: Bugs item #789667, was opened at 2003-08-16 10:29 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789667&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sinitsyn Valentine (valentine) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize("5BH") gives wrong result Initial Comment: Consider the following program: import struct print struct.calcsize("5BH") print struct.calcsize("6BH") One could expect that the ouptut of this program will consist of two different numbers, 7 and 8. But this is not the case: the program prints 8 and 8. This prevents my Python 2.3 for Windows from unpacking strings using "5BH" format properly. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-08-16 16:11 Message: Logged In: YES user_id=11105 Are you sure you didn't mean "=5BH" and "=7BH"? This should give the desired result 7 and 8... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789667&group_id=5470 From noreply at sourceforge.net Sat Aug 16 09:52:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 16 11:52:44 2003 Subject: [Python-bugs-list] [ python-Bugs-789667 ] struct.calcsize("5BH") gives wrong result Message-ID: Bugs item #789667, was opened at 2003-08-16 04:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789667&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Sinitsyn Valentine (valentine) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize("5BH") gives wrong result Initial Comment: Consider the following program: import struct print struct.calcsize("5BH") print struct.calcsize("6BH") One could expect that the ouptut of this program will consist of two different numbers, 7 and 8. But this is not the case: the program prints 8 and 8. This prevents my Python 2.3 for Windows from unpacking strings using "5BH" format properly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-16 11:52 Message: Logged In: YES user_id=31435 You need to read the docs for the struct module more carefully, paying attention to the difference between "native" size and alignment (the default) and "standard" size and alignment (which is probably what you want, but aren't asking for). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-08-16 10:11 Message: Logged In: YES user_id=11105 Are you sure you didn't mean "=5BH" and "=7BH"? This should give the desired result 7 and 8... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789667&group_id=5470 From noreply at sourceforge.net Sat Aug 16 16:53:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 16 18:53:32 2003 Subject: [Python-bugs-list] [ python-Bugs-789926 ] "SetFrontProcess failed, -606" error for Tkinter under OS X Message-ID: Bugs item #789926, was opened at 2003-08-16 15: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=789926&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: "SetFrontProcess failed,-606" error for Tkinter under OS X Initial Comment: Launching IDLE with the newest Aqua Tcl/Tk (8.4.4 with batteries included) leads to the error message "SetFrontProcess failed,-606" in the terminal window when I try to click on the IDLE window. Is this a Tcl/Tk issue or a Tkinter problem? I have tried to wipe as much of Tcl/Tk from my system and re-install and it still comes up (I could be having residual issues from my previous 8.3.3 which also had the same error). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 From noreply at sourceforge.net Sat Aug 16 17:09:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 16 19:09:54 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 13:23 Message generated for change (Comment added) made by jdalambert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- >Comment By: David Lambert (jdalambert) Date: 2003-08-16 18:09 Message: Logged In: YES user_id=845425 I think I may have a fix. Check out the attached file. It seems to work for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 15:07 Message: Logged In: YES user_id=33168 Wow, it sure does leak! Checked in as: Objects/fileobject.c 2.180 Still needs a test. Leaving open until I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Sun Aug 17 01:10:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 03:10:56 2003 Subject: [Python-bugs-list] [ python-Bugs-789995 ] access fails on Windows with Unicode file name Message-ID: Bugs item #789995, was opened at 2003-08-17 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=789995&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: M.-A. Lemburg (lemburg) Summary: access fails on Windows with Unicode file name Initial Comment: Using current CVS version of Python 2.4 on Windows 2000. The os.access function fails when the filename argument is a Unicode string: File "test_pep277.py", line 103, in test_directory os.access(filename,os.R_OK) UnicodeEncodeError: 'ascii' codec can't encode character '\udf' in position 0: ordinal not in range(128) I will upload a patch to fix this in the patch manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 From noreply at sourceforge.net Sun Aug 17 11:06:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 13:06:41 2003 Subject: [Python-bugs-list] [ python-Bugs-778804 ] CGIHTTPServer cannot manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 04:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) >Assigned to: Eric S. Raymond (esr) Summary: CGIHTTPServer cannot manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 12:06 Message: Logged In: YES user_id=80475 Eric, this was your change (2/9/2001). Will you take it from here? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply at sourceforge.net Sun Aug 17 11:09:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 13:09:21 2003 Subject: [Python-bugs-list] [ python-Bugs-777848 ] CGIHTTPServer and urls Message-ID: Bugs item #777848, was opened at 2003-07-25 17:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) >Assigned to: Guido van Rossum (gvanrossum) Summary: CGIHTTPServer and urls Initial Comment: If you have 2 differents CGI. On the both you ask to print the content of cgi.FieldStorage. You will see that URL paramters (after ? in the url) remains. For our example : 1) http://localhost:8080/cgi-bin/script1.py?action=test Will display the parameter name 'action' and his value 'test' BUT, now you ask the second url 2) http://localhost:8080/cgi-bin/script2.py you still see the previous parameter 'action' with the previous value 'test' I've resolve the problem by removing a test in the CGIHTTPServer.py script. line +- 149 - if query: - env['QUERY_STRING'] = query + env['QUERY_STRING'] = query Indeed, the os.environ.update(env) does not modify 'QUERY_STRING' if you are not givin a new value. But in this case empty is a new value, and must be take in account. I don't know if my resolution is the best one. But now it works like it should be. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 12:09 Message: Logged In: YES user_id=80475 Guido, is there a reason that you had excluded default setting when have_fork is true? ---------------------------------------------------------------------- Comment By: vincent delft (vincent_delft) Date: 2003-07-27 06:53 Message: Logged In: YES user_id=106404 I don't see the for-loop ? If you are talking about the following : if not self.have_fork: # Since we're setting the env in the parent, provide empty # values to override previously set values for k in ('QUERY_STRING', 'REMOTE_HOST', 'CONTENT_LENGTH', 'HTTP_USER_AGENT', 'HTTP_COOKIE'): env.setdefault(k, "") It's normal that he not used because I'm on Linux machine. So, I have fork capabilities. Honestly I don't understand this loop. Indeed, You set to default values that was defined just before. In general we set the default before. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 00:01 Message: Logged In: YES user_id=80475 Will take a closer look at this one. Initially, I was concerned that some CGI scripts check for the existence rather than the nullity of the QUERY_STRING key. Now, I'm perplexed by why this isn't being handled by the for-loop (a few lines down from the part you patched) which "provides empty values to override previously set values". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 From noreply at sourceforge.net Sun Aug 17 12:18:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 14:18:51 2003 Subject: [Python-bugs-list] [ python-Bugs-790162 ] a bug in IDLE on Python 2.3 i think Message-ID: Bugs item #790162, was opened at 2003-08-17 19: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=790162&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Nunes Cerqueira (caifas1800) Assigned to: Nobody/Anonymous (nobody) Summary: a bug in IDLE on Python 2.3 i think Initial Comment: Hi, my name is Ricardo and i think there is a bug in the new release of Python 2.3. When i open a .py file with IDLE(after opening IDLE i open another .py file with it) the second window does not close after clicking the respective button, only the first(when i click the first window of IDLE) that has no code inserted, after trying to close the group(2 windows) only the first (the first IDLE window with no code inserted) closes leaving the other with code inserted open. i'm using Python 2.3 on Windows XP under an Intel PIII 1000EB FC-PGA. What i described happens after i open Python win then i open IDLE and then i open a .py file with IDLE, and when i try to close the .py and i can't. thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790162&group_id=5470 From noreply at sourceforge.net Sun Aug 17 12:35:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 14:35:09 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 19:59 Message generated for change (Comment added) made by netytan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- >Comment By: mark lee smith (netytan) Date: 2003-08-17 18:35 Message: Logged In: YES user_id=797196 The problem can also been see when running IDLE (idle.py intead of the idle.pyw). When you close the program the "worker thread" message appears in the Python window before it closes. My conclusion is that this error is definatly to do with the socket module (The version of IDLE packaged in 2.3 uses sockets). What chages were made to the socket module in 2.3? Also has anyone else knoticed this error? Any help would be very appreciated, Thanks, Mark. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-12 23:53 Message: Logged In: YES user_id=797196 Ok I've spent allot of my free time working on this now and I'm pretty sure it isn't in the urllib module. The same message is displayed when using smtplib and sendmail. Both modules use the socket module, but I am not sure about searching that for the message since it is writen in C (A lang' i've only brushed with a few times) plus i'm not sure if this has been changed since 2.2.. I could probably upgrade my version at home and see if i get the same message but i'm a little reluctant to do that. Sorry cannon, I don't know much about Macs or Mac OS :) Hope this helps, let me know what you think. Am not sure where to go next. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 20:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-09 06:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 21:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Sun Aug 17 13:32:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 15:33:00 2003 Subject: [Python-bugs-list] [ python-Bugs-790162 ] a bug in IDLE on Python 2.3 i think Message-ID: Bugs item #790162, was opened at 2003-08-17 13:18 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790162&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ricardo Nunes Cerqueira (caifas1800) >Assigned to: Kurt B. Kaiser (kbk) Summary: a bug in IDLE on Python 2.3 i think Initial Comment: Hi, my name is Ricardo and i think there is a bug in the new release of Python 2.3. When i open a .py file with IDLE(after opening IDLE i open another .py file with it) the second window does not close after clicking the respective button, only the first(when i click the first window of IDLE) that has no code inserted, after trying to close the group(2 windows) only the first (the first IDLE window with no code inserted) closes leaving the other with code inserted open. i'm using Python 2.3 on Windows XP under an Intel PIII 1000EB FC-PGA. What i described happens after i open Python win then i open IDLE and then i open a .py file with IDLE, and when i try to close the .py and i can't. thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790162&group_id=5470 From noreply at sourceforge.net Sun Aug 17 14:30:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 16:30:26 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-13 23:57 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 15:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 09:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 14:35:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 16:35:41 2003 Subject: [Python-bugs-list] [ python-Bugs-732120 ] An extended definition of "non-overlapping" would save time. Message-ID: Bugs item #732120, was opened at 2003-05-04 04:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732120&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Philip J?genstedt (foolip) >Assigned to: Raymond Hettinger (rhettinger) Summary: An extended definition of "non-overlapping" would save time. Initial Comment: Hello. Yesterday I spent several hours trying to figure out why a (stupid) regex like "^|foo" didn't return ['', 'foo'] for findall("foo"). Like this: |f|o|o| 0 1 2 3 I figured the ^ would match 0-0 and then a 0-3 match for foo. I've learnt since that the reason this can't happen is because the regexp engine would get caught in an infinte loop. However, the two matches aren't really overlapping, and the docs state that all non-overlapping matches would be returned. I suggest therefor that it is clarified in the docs that non-overlapping doesn't apply to a zero-length match at the beginning of another potential match. This would apply to findall and finditer in doc/python2.2/html/lib/node99.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=732120&group_id=5470 From noreply at sourceforge.net Sun Aug 17 14:50:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 16:50:15 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 00:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-17 16:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 16:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 10:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 15:30:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 17:30:17 2003 Subject: [Python-bugs-list] [ python-Bugs-784031 ] Byte-order bug in socket-module getaddrinfo.c Message-ID: Bugs item #784031, was opened at 2003-08-06 04:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784031&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Tuomo Hyyrylainen (therry) Assigned to: Nobody/Anonymous (nobody) Summary: Byte-order bug in socket-module getaddrinfo.c Initial Comment: It seems to me that there is a byte-order bug in Modules/getaddrinfo.c, in function getaddrinfo. On line 415 inet_pton is called, and that is supposed to return IPv4 address in network byte order. So the code below in case block (AF_INET) does not work correctly on little-endian platforms. I would propose adding line v4a = ntohl(v4a); between current lines 423 and 424. -- Tuomo Hyyrylainen ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 16:30 Message: Logged In: YES user_id=80475 Applied as getaddrinfo.c 1.11.14.1 and 1.12. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=784031&group_id=5470 From noreply at sourceforge.net Sun Aug 17 20:55:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 22:55:55 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 04:57 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 02:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 20:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 20:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 14:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 21:22:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 23:22:31 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 00:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-17 23:22 Message: Logged In: YES user_id=31435 The primary point of a non-blocking call is never to block. That's the common meaning of "non-blocking" (in or out of Python). After all, a "non-blocking" call that *could* block is useless for apps that need not to block. If you're willing to block, use the blocking methods (which most apps do use, BTW -- using the non-blocking methods is unusual). The Full exception isn't raised incorrectly. "Full" is just 4 letters strung together, and is only meant to be suggestive and convenient -- its full meaning is explained in the docs, albeit somewhat cryptically. I don't think it would be a real improvement to, e.g., rename this exception to FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo WeSkippedThat . ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-17 22:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 16:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 16:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 10:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 21:53:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 17 23:53:50 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 04:57 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 03:53 Message: Logged In: YES user_id=693152 First up, you're right that non-blocking calls are unusual. This isn't exactly a critical matter for me :-) Okay, I have misunderstood the meaning of non-blocking calls - so it actually means "ensure we never under any circumstances block". Why then do we acquire mutex with a blocking call? I am not suggesting there's anything wrong with the naming of Full (amusing as your suggestion is :-). Of course you can't completely describe how an exception will be used in it's name. It just seems more intuitive for put's documentation to fully and unambiguously describe when an exception is raised, rather than to have part of the function documentation ("or locked") in the Exception documentation. More straightforward, etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 03:22 Message: Logged In: YES user_id=31435 The primary point of a non-blocking call is never to block. That's the common meaning of "non-blocking" (in or out of Python). After all, a "non-blocking" call that *could* block is useless for apps that need not to block. If you're willing to block, use the blocking methods (which most apps do use, BTW -- using the non-blocking methods is unusual). The Full exception isn't raised incorrectly. "Full" is just 4 letters strung together, and is only meant to be suggestive and convenient -- its full meaning is explained in the docs, albeit somewhat cryptically. I don't think it would be a real improvement to, e.g., rename this exception to FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo WeSkippedThat . ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 02:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 20:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 20:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 14:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 22:09:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 00:09:39 2003 Subject: [Python-bugs-list] [ python-Bugs-790356 ] curses.ascii.unctrl broken Message-ID: Bugs item #790356, was opened at 2003-08-18 00:09 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=790356&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Nobody/Anonymous (nobody) Summary: curses.ascii.unctrl broken Initial Comment: unctrl(c) Return a string representation of the ASCII character c. If c is printable, this string is the character itself. ... from curses.ascii import unctrl >>> unctrl('a') 'a' >>> unctrl('A') '^\x81' unctrl() is not working for the full printable charset. The Q&D fix is: def unctrl(c): + if isprint(c): + return c bits = _ctoi(c) if bits == 0x7f: This bug has been confirmed in python 2.3 and 2.2 as distributed in Debian Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790356&group_id=5470 From noreply at sourceforge.net Sun Aug 17 22:32:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 00:32:08 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 00:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-18 00:32 Message: Logged In: YES user_id=31435 We acquire a mutex with a blocking call because the use of a blocking call announces that the client is *willing* to block, and nothing about the state of a Queue can be changed without acquiring a lock first. So it wouldn't make sense not to acquire a lock in that case. I have no objection at all to improving the docs. They appear to be what they are now because the original version of the Queue module didn't have a non-blocking put() method, or a Full exception. I added those 7(!) years later, in 1999. Development was done by emailing changes to Guido at that time, though, and doc changes were often dropped on the floor. If you can work up a doc patch to supply words that would make better sense to you, that would be great. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-17 23:53 Message: Logged In: YES user_id=693152 First up, you're right that non-blocking calls are unusual. This isn't exactly a critical matter for me :-) Okay, I have misunderstood the meaning of non-blocking calls - so it actually means "ensure we never under any circumstances block". Why then do we acquire mutex with a blocking call? I am not suggesting there's anything wrong with the naming of Full (amusing as your suggestion is :-). Of course you can't completely describe how an exception will be used in it's name. It just seems more intuitive for put's documentation to fully and unambiguously describe when an exception is raised, rather than to have part of the function documentation ("or locked") in the Exception documentation. More straightforward, etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 23:22 Message: Logged In: YES user_id=31435 The primary point of a non-blocking call is never to block. That's the common meaning of "non-blocking" (in or out of Python). After all, a "non-blocking" call that *could* block is useless for apps that need not to block. If you're willing to block, use the blocking methods (which most apps do use, BTW -- using the non-blocking methods is unusual). The Full exception isn't raised incorrectly. "Full" is just 4 letters strung together, and is only meant to be suggestive and convenient -- its full meaning is explained in the docs, albeit somewhat cryptically. I don't think it would be a real improvement to, e.g., rename this exception to FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo WeSkippedThat . ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-17 22:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 16:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 16:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 10:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 22:52:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 00:52:59 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 04:57 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 04:52 Message: Logged In: YES user_id=693152 Whoops - let's try that question in a clearer way: When you do a non-blocking call to put(), why does it acquire mutex in a blocking way (ie. "put(block=False)" will call "mutex.acquire()", which could block whilst acquiring mutex). I thought the theory was that you *never* block anywhere. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 04:32 Message: Logged In: YES user_id=31435 We acquire a mutex with a blocking call because the use of a blocking call announces that the client is *willing* to block, and nothing about the state of a Queue can be changed without acquiring a lock first. So it wouldn't make sense not to acquire a lock in that case. I have no objection at all to improving the docs. They appear to be what they are now because the original version of the Queue module didn't have a non-blocking put() method, or a Full exception. I added those 7(!) years later, in 1999. Development was done by emailing changes to Guido at that time, though, and doc changes were often dropped on the floor. If you can work up a doc patch to supply words that would make better sense to you, that would be great. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 03:53 Message: Logged In: YES user_id=693152 First up, you're right that non-blocking calls are unusual. This isn't exactly a critical matter for me :-) Okay, I have misunderstood the meaning of non-blocking calls - so it actually means "ensure we never under any circumstances block". Why then do we acquire mutex with a blocking call? I am not suggesting there's anything wrong with the naming of Full (amusing as your suggestion is :-). Of course you can't completely describe how an exception will be used in it's name. It just seems more intuitive for put's documentation to fully and unambiguously describe when an exception is raised, rather than to have part of the function documentation ("or locked") in the Exception documentation. More straightforward, etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 03:22 Message: Logged In: YES user_id=31435 The primary point of a non-blocking call is never to block. That's the common meaning of "non-blocking" (in or out of Python). After all, a "non-blocking" call that *could* block is useless for apps that need not to block. If you're willing to block, use the blocking methods (which most apps do use, BTW -- using the non-blocking methods is unusual). The Full exception isn't raised incorrectly. "Full" is just 4 letters strung together, and is only meant to be suggestive and convenient -- its full meaning is explained in the docs, albeit somewhat cryptically. I don't think it would be a real improvement to, e.g., rename this exception to FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo WeSkippedThat . ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 02:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 20:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 20:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 14:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Sun Aug 17 23:41:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 01:41:59 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 00:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-18 01:41 Message: Logged In: YES user_id=31435 It depends on what you mean by "blocking" . If the thread implementation schedules fairly, it's impossible for self.mutex to be held for a "long" time by any thread -- unlike esema and fsema, self.mutex is used only for mutual exclusion over brief sections of code that don't wait for anything, and nothing Queue clients do can cause self.mutex to be held for an arbitrarily long time (a spectacularly bad OS implementation of thread scheduling could, but that's out of the user's-- and out of Python's --hands). The usual meaning of "blocking" is that clients *can* do something to get the system into a state where a call can take arbitrarily long to complete (while assuming fair thread scheduling). The obvious example here is that Queue.get() can take forever if the Queue is empty and the app stops adding anything to the Queue. There's nothing (sane) the app can do that can make Queue.get_nowait() take forever. BTW, I hope you're looking at the 2.3 code here! Queue is more complicated in 2.3 because these methods have also grown optional timeout arguments. If you're really worried about "spurious" Full exceptions, doing a blocking 2.3 Queue.put() call with a short timeout will try to grab fsema several times before giving up. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 00:52 Message: Logged In: YES user_id=693152 Whoops - let's try that question in a clearer way: When you do a non-blocking call to put(), why does it acquire mutex in a blocking way (ie. "put(block=False)" will call "mutex.acquire()", which could block whilst acquiring mutex). I thought the theory was that you *never* block anywhere. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 00:32 Message: Logged In: YES user_id=31435 We acquire a mutex with a blocking call because the use of a blocking call announces that the client is *willing* to block, and nothing about the state of a Queue can be changed without acquiring a lock first. So it wouldn't make sense not to acquire a lock in that case. I have no objection at all to improving the docs. They appear to be what they are now because the original version of the Queue module didn't have a non-blocking put() method, or a Full exception. I added those 7(!) years later, in 1999. Development was done by emailing changes to Guido at that time, though, and doc changes were often dropped on the floor. If you can work up a doc patch to supply words that would make better sense to you, that would be great. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-17 23:53 Message: Logged In: YES user_id=693152 First up, you're right that non-blocking calls are unusual. This isn't exactly a critical matter for me :-) Okay, I have misunderstood the meaning of non-blocking calls - so it actually means "ensure we never under any circumstances block". Why then do we acquire mutex with a blocking call? I am not suggesting there's anything wrong with the naming of Full (amusing as your suggestion is :-). Of course you can't completely describe how an exception will be used in it's name. It just seems more intuitive for put's documentation to fully and unambiguously describe when an exception is raised, rather than to have part of the function documentation ("or locked") in the Exception documentation. More straightforward, etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 23:22 Message: Logged In: YES user_id=31435 The primary point of a non-blocking call is never to block. That's the common meaning of "non-blocking" (in or out of Python). After all, a "non-blocking" call that *could* block is useless for apps that need not to block. If you're willing to block, use the blocking methods (which most apps do use, BTW -- using the non-blocking methods is unusual). The Full exception isn't raised incorrectly. "Full" is just 4 letters strung together, and is only meant to be suggestive and convenient -- its full meaning is explained in the docs, albeit somewhat cryptically. I don't think it would be a real improvement to, e.g., rename this exception to FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo WeSkippedThat . ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-17 22:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 16:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 16:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 10:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Mon Aug 18 01:35:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 03:35:37 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-14 04:07 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:35 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:34 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-14 11:17 Message: Logged In: YES user_id=38388 The ASCII codec can't handle non-ASCII characters and that's perfectly normal. Please provide more context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Mon Aug 18 01:34:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 03:38:08 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-14 04:07 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:34 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-14 11:17 Message: Logged In: YES user_id=38388 The ASCII codec can't handle non-ASCII characters and that's perfectly normal. Please provide more context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Mon Aug 18 01:39:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 03:39:31 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-14 04:07 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:39 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:35 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:34 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-14 11:17 Message: Logged In: YES user_id=38388 The ASCII codec can't handle non-ASCII characters and that's perfectly normal. Please provide more context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Mon Aug 18 01:41:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 03:41:46 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-14 04:07 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:41 Message: Logged In: YES user_id=539787 Forgive my multiple posting (SF reported an error), and substitute "Windows command line" for "Python command line" in the last paragraph. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:39 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:35 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 10:34 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-14 11:17 Message: Logged In: YES user_id=38388 The ASCII codec can't handle non-ASCII characters and that's perfectly normal. Please provide more context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Mon Aug 18 02:34:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 04:35:00 2003 Subject: [Python-bugs-list] [ python-Bugs-789926 ] "SetFrontProcess failed, -606" error for Tkinter under OS X Message-ID: Bugs item #789926, was opened at 2003-08-17 00:53 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: "SetFrontProcess failed,-606" error for Tkinter under OS X Initial Comment: Launching IDLE with the newest Aqua Tcl/Tk (8.4.4 with batteries included) leads to the error message "SetFrontProcess failed,-606" in the terminal window when I try to click on the IDLE window. Is this a Tcl/Tk issue or a Tkinter problem? I have tried to wipe as much of Tcl/Tk from my system and re-install and it still comes up (I could be having residual issues from my previous 8.3.3 which also had the same error). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-18 10:34 Message: Logged In: YES user_id=45365 Brett, I need a few more details. Did you use the existing IDLE from 2.3 installed via PackMan, or a privately-built one? Or did you run from the command line? If so, you did remember to use "pythonw", not "python"? If you can repeat this problem using pythonw from the command line I would like a transcript, please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 From noreply at sourceforge.net Mon Aug 18 05:01:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 07:01:28 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 22:59 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 14:01 Message: Logged In: YES user_id=539787 Perhaps this has to do only with your version of IDLE? In the current CVS, various greps for "orker", "recieved" etc did not show up with something relevant. If you are sure about the "Worker" spelling, try this script in your Millenium windows: ### code start import sys, os, itertools for dirname, dirnames, filenames in os.walk(sys.prefix): joiner = os.path.join.__get__(dirname) for filename in itertools.imap(joiner, filenames): data = file(filename, "rb").read() if "Worker" in data: print filename ### code end this searches your whole python installation directory, for /any/ file containing the string "Worker". A run on a 2.3b2 install showed these files: C:\PY.23\Lib\distutils\bcppcompiler.py C:\PY.23\Lib\distutils\ccompiler.py C:\PY.23\Lib\distutils\msvccompiler.py ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-17 21:35 Message: Logged In: YES user_id=797196 The problem can also been see when running IDLE (idle.py intead of the idle.pyw). When you close the program the "worker thread" message appears in the Python window before it closes. My conclusion is that this error is definatly to do with the socket module (The version of IDLE packaged in 2.3 uses sockets). What chages were made to the socket module in 2.3? Also has anyone else knoticed this error? Any help would be very appreciated, Thanks, Mark. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-13 02:53 Message: Logged In: YES user_id=797196 Ok I've spent allot of my free time working on this now and I'm pretty sure it isn't in the urllib module. The same message is displayed when using smtplib and sendmail. Both modules use the socket module, but I am not sure about searching that for the message since it is writen in C (A lang' i've only brushed with a few times) plus i'm not sure if this has been changed since 2.2.. I could probably upgrade my version at home and see if i get the same message but i'm a little reluctant to do that. Sorry cannon, I don't know much about Macs or Mac OS :) Hope this helps, let me know what you think. Am not sure where to go next. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 23:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-09 09:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 00:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Mon Aug 18 14:33:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 16:33:44 2003 Subject: [Python-bugs-list] [ python-Bugs-789926 ] "SetFrontProcess failed, -606" error for Tkinter under OS X Message-ID: Bugs item #789926, was opened at 2003-08-16 15:53 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: "SetFrontProcess failed,-606" error for Tkinter under OS X Initial Comment: Launching IDLE with the newest Aqua Tcl/Tk (8.4.4 with batteries included) leads to the error message "SetFrontProcess failed,-606" in the terminal window when I try to click on the IDLE window. Is this a Tcl/Tk issue or a Tkinter problem? I have tried to wipe as much of Tcl/Tk from my system and re-install and it still comes up (I could be having residual issues from my previous 8.3.3 which also had the same error). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-08-18 13:33 Message: Logged In: YES user_id=357491 This is a Darwin build built from CVS source (--with-pydebug -- prefix=$HOME/cvs_code --enable-ipv6 --enable-unicode=ucs4). There is no pythonw to run (I thought that was a Windows-only thing?) and I have never used (nor know how to use) PackMan. I executed from the command-line by passing the script "idle" in my bin directory to my installed copy of CVS Python. If this turns out to be because of the Unicode switch again I am going to go nuts. =) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-18 01:34 Message: Logged In: YES user_id=45365 Brett, I need a few more details. Did you use the existing IDLE from 2.3 installed via PackMan, or a privately-built one? Or did you run from the command line? If so, you did remember to use "pythonw", not "python"? If you can repeat this problem using pythonw from the command line I would like a transcript, please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 From noreply at sourceforge.net Mon Aug 18 17:12:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 19:12:30 2003 Subject: [Python-bugs-list] [ python-Bugs-790883 ] Wrong conversion from float to long Message-ID: Bugs item #790883, was opened at 2003-08-19 01:12 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=790883&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andr? Thieme (mitt) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong conversion from float to long Initial Comment: When doing some calculations I found a minor bug: atomsInUniverse = 1e+78 print atomsInUniverse print long(atomsInUniverse) # prints results: 1e+078 1000000000000000008493621433689702976148869924598760615894999102702796905906176 The last number should have been a One with 78 Zeros. This phenomenon starts at 1e+023 >>> print long(1e+021) 1000000000000000000000 >>> print long(1e+022) 10000000000000000000000 >>> print long(1e+023) 99999999999999991611392 >>> print long(1e+024) 999999999999999983222784 Andr? Thieme, Germany ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790883&group_id=5470 From noreply at sourceforge.net Mon Aug 18 17:21:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 19:21:26 2003 Subject: [Python-bugs-list] [ python-Bugs-790885 ] float precision when printing a tuple directly Message-ID: Bugs item #790885, was opened at 2003-08-19 01: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=790885&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andr? Thieme (mitt) Assigned to: Nobody/Anonymous (nobody) Summary: float precision when printing a tuple directly Initial Comment: When printing a from a function returned tuple that contains a float produces a wrong output: def foo1(): return 2.9 print foo1() #prints "2.9" as expected def foo2(): return (2.9, "Hello world") print foo2() #prints "(2.8999999999999999, 'Hello world')" #where "(2.9, 'Hello world')" was expected But: x, y = foo2() print x, y #or print "(" + str(x) + ", " + `y` + ")" #work Andr? Thieme, Germany ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790885&group_id=5470 From noreply at sourceforge.net Mon Aug 18 17:29:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 19:29:58 2003 Subject: [Python-bugs-list] [ python-Bugs-790885 ] float precision when printing a tuple directly Message-ID: Bugs item #790885, was opened at 2003-08-18 19:21 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790885&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andr? Thieme (mitt) Assigned to: Nobody/Anonymous (nobody) Summary: float precision when printing a tuple directly Initial Comment: When printing a from a function returned tuple that contains a float produces a wrong output: def foo1(): return 2.9 print foo1() #prints "2.9" as expected def foo2(): return (2.9, "Hello world") print foo2() #prints "(2.8999999999999999, 'Hello world')" #where "(2.9, 'Hello world')" was expected But: x, y = foo2() print x, y #or print "(" + str(x) + ", " + `y` + ")" #work Andr? Thieme, Germany ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 19:29 Message: Logged In: YES user_id=31435 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=790885&group_id=5470 From noreply at sourceforge.net Mon Aug 18 17:31:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 19:31:48 2003 Subject: [Python-bugs-list] [ python-Bugs-790885 ] float precision when printing a tuple directly Message-ID: Bugs item #790885, was opened at 2003-08-18 19:21 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790885&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Andr? Thieme (mitt) Assigned to: Nobody/Anonymous (nobody) Summary: float precision when printing a tuple directly Initial Comment: When printing a from a function returned tuple that contains a float produces a wrong output: def foo1(): return 2.9 print foo1() #prints "2.9" as expected def foo2(): return (2.9, "Hello world") print foo2() #prints "(2.8999999999999999, 'Hello world')" #where "(2.9, 'Hello world')" was expected But: x, y = foo2() print x, y #or print "(" + str(x) + ", " + `y` + ")" #work Andr? Thieme, Germany ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-18 19:31 Message: Logged In: YES user_id=31435 That was a canned response. The link it contains is still relevant, though: read about the difference between str (a_float) (which lies) and repr(a_float) (which lies less). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 19:29 Message: Logged In: YES user_id=31435 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=790885&group_id=5470 From noreply at sourceforge.net Mon Aug 18 17:34:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 19:34:07 2003 Subject: [Python-bugs-list] [ python-Bugs-790883 ] Wrong conversion from float to long Message-ID: Bugs item #790883, was opened at 2003-08-18 19:12 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790883&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Andr? Thieme (mitt) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong conversion from float to long Initial Comment: When doing some calculations I found a minor bug: atomsInUniverse = 1e+78 print atomsInUniverse print long(atomsInUniverse) # prints results: 1e+078 1000000000000000008493621433689702976148869924598760615894999102702796905906176 The last number should have been a One with 78 Zeros. This phenomenon starts at 1e+023 >>> print long(1e+021) 1000000000000000000000 >>> print long(1e+022) 10000000000000000000000 >>> print long(1e+023) 99999999999999991611392 >>> print long(1e+024) 999999999999999983222784 Andr? Thieme, Germany ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-08-18 19:34 Message: Logged In: YES user_id=31435 Read the Tutorial appendix on floating-point: http://www.python.org/doc/2.2.1/tut/node14.html The result you're getting is in fact the best possible result given that IEEE-754 double precision floats (which Python uses for its float type on most boxes) are limited to 53 bits of precision. The Tutorial explains it in more detail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790883&group_id=5470 From noreply at sourceforge.net Mon Aug 18 18:23:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 20:23:21 2003 Subject: [Python-bugs-list] [ python-Bugs-729103 ] Cannot retrieve name of super object Message-ID: Bugs item #729103, was opened at 2003-04-28 14:47 Message generated for change (Comment added) made by michele_s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Brett Cannon (bcannon) Summary: Cannot retrieve name of super object Initial Comment: I see that in Python 2.3b1 many problems of super have been fixed, but this one is still there: I cannot retrieve the __name__ of a super object. This generates problems with pydoc, for instance: >>> class C(B): ... sup=super(B) >>> help(C) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/site.py", line 293, in __call__ return pydoc.help(*args, **kwds) File "/usr/local/lib/python2.3/pydoc.py", line 1539, in __call__ self.help(request) File "/usr/local/lib/python2.3/pydoc.py", line 1575, in help else: doc(request, 'Help on %s:') File "/usr/local/lib/python2.3/pydoc.py", line 1368, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/usr/local/lib/python2.3/pydoc.py", line 279, in document if inspect.isclass(object): return self.docclass(*args) File "/usr/local/lib/python2.3/pydoc.py", line 1122, in docclass lambda t: t[1] == 'method') File "/usr/local/lib/python2.3/pydoc.py", line 1057, in spill name, mod, object)) File "/usr/local/lib/python2.3/pydoc.py", line 280, in document if inspect.isroutine(object): return self.docroutine(*args) File "/usr/local/lib/python2.3/pydoc.py", line 1145, in docroutine realname = object.__name__ AttributeError: 'super' object has no attribute '__name__' P.S. I seem to remember I already submitted this bug (or feature request, as you wish ;) but I don't find it in bugtracker and I had no feedback; maybe it wasn't sent at all due to some connection problem. If not, please accept my apologies. Michele Simionato ---------------------------------------------------------------------- >Comment By: Michele Simionato (michele_s) Date: 2003-08-18 20:23 Message: Logged In: YES user_id=583457 I've just checked today with Python 2.3 (pydoc revision 1.86): class B(object): pass class C(B): sup=super(B) help(C) still gives the same error! What happened? Did you forgot to add the patch to the standard distribution? The bug is not close! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-11 19:39 Message: Logged In: YES user_id=357491 Patched pydoc (revision 1.84) to try an object as "other" if what inspect identifies it as does not work based on its assumptions. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-10 19:44 Message: Logged In: YES user_id=357491 The issue is inspect.isroutine is saying that the instance is a callable object since it is also a non-data descriptor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=729103&group_id=5470 From noreply at sourceforge.net Mon Aug 18 18:50:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 20:50:59 2003 Subject: [Python-bugs-list] [ python-Bugs-788457 ] Cannot decode/encode anything! Message-ID: Bugs item #788457, was opened at 2003-08-13 18:07 Message generated for change (Comment added) made by zarxos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Joe Smith (zarxos) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot decode/encode anything! Initial Comment: Whenever I use any of the decode methods in the codecs package, or use a string's encode or decode method, I get the error: UnicodeDecodeError: 'ascii' codec can't decode byte 0x88 in position 0: ordinal not in range(128). That character it's referring to is a ? (e with circonflex if you can't see it for whatever reason). I don't know why this is happening, and I've tried a dozen different ways to try and get it to work. Please fix this horrible bug! I can't decode any files! ---------------------------------------------------------------------- >Comment By: Joe Smith (zarxos) Date: 2003-08-18 17:50 Message: Logged In: YES user_id=826905 Yes I am using Python command line. What else would I use? Anyway, your method works too, but someone told me to put u"?".encode('cp437') in my code and that works. Thank you anyway. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 00:41 Message: Logged In: YES user_id=539787 Forgive my multiple posting (SF reported an error), and substitute "Windows command line" for "Python command line" in the last paragraph. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 00:39 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 00:35 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 00:34 Message: Logged In: YES user_id=539787 Joe, does this code work for you? s = '\x88' u = s.decode('cp850') If it does work fine, then either you don't supply the argument to decode/encode, or you try to print the result; in either of these two cases, it's not a Python bug. PS Since e-circumflex is \x88 for you, I assume you run this in the Python command line. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-14 01:17 Message: Logged In: YES user_id=38388 The ASCII codec can't handle non-ASCII characters and that's perfectly normal. Please provide more context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788457&group_id=5470 From noreply at sourceforge.net Mon Aug 18 19:12:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Aug 18 21:12:15 2003 Subject: [Python-bugs-list] [ python-Bugs-790930 ] Tutorial 2.1, typo for ways to start Message-ID: Bugs item #790930, was opened at 2003-08-18 21:12 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=790930&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial 2.1, typo for ways to start Initial Comment: 2.1 in the tutorial says "A third way of starting ..." but it's only the second. (Yeah, I know, picky, picky.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790930&group_id=5470 From noreply at sourceforge.net Tue Aug 19 02:20:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 04:20:59 2003 Subject: [Python-bugs-list] [ python-Bugs-791067 ] Section 11.20: xmlrpclib Details Message-ID: Bugs item #791067, was opened at 2003-08-19 10: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=791067&group_id=5470 Category: Documentation Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: J?rgen Hermann (jhermann) Assigned to: Nobody/Anonymous (nobody) Summary: Section 11.20: xmlrpclib Details Initial Comment: An important detail is missing from the LaTeX library ref, namely how to get at the values of the special types (bool, date, binary); I had to inspect code to get at this (I think even the module docstrings don't reveal this). Naively (with str) you get the repr() values: , , ), To get at the underlying real values, you need: int(boolval) (or bool(boolval) for 2.3) dateval.value binary.data This should be documented on the relevant sections (11.20.2/3/4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791067&group_id=5470 From noreply at sourceforge.net Tue Aug 19 02:41:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 04:41:56 2003 Subject: [Python-bugs-list] [ python-Bugs-783789 ] SIGSEGV in _sre.c (IRIX 6.5.20) Message-ID: Bugs item #783789, was opened at 2003-08-06 00:59 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Fredrik Lundh (effbot) Summary: SIGSEGV in _sre.c (IRIX 6.5.20) Initial Comment: Under IRIX (6.5.20) Python 2.3 (final) crashes with a core dump while executing a SCons job (www.scons.org). I've recompiled Python with -g but the behavior is the same. Here is the beginning of the dbx stack trace: dbx version 7.3 MR 55458_Apr30_MR Apr 30 1999 13:44:41 dbx Warning: Unknown processor type 0xe, assuming this is not an R8000 Core from signal SIGSEGV: Segmentation violation (dbx) where > 0 mark_save(state = , lo = , hi = 0, mark_stack_base = (nil)) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":289, 0x10107bc4] 1 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 669) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":979, 0x10109d74] 2 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 668) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 3 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 667) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 4 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 666) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 5 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 665) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 6 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 664) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] The alternation of _sre.c:991, _sre.c:1263 continues to the end of the dbx output which stops at 99; the value of level is decreasing monotonously. To reproduce upload this file to an IRIX machine: http://cci.lbl.gov/cctbx_build/send_octet_stream.cgi? source=results/2003_08_04_2056/cctbx_python_23_ bundle.selfx In a new, empty directory enter the command: perl cctbx_python_23_bundle.selfx When prompted enter the number of available CPU's and wait for the Python 2.3 installation to finish (log is in the file py_install_log). The newly compiled Python is used to start a SCons build procedure. The crash occurs a few files into the process of compiling C++ sources. I've tried the exact same source code under Redhat 8.0. There it finishes without a crash. Therefore I am thinking you will need an IRIX machine to reproduce the crash. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-19 11:41 Message: Logged In: YES user_id=539787 Ralf: what machine are you working on? Origin? Please specify # of CPU's, IP##. This to help me reproduce the problem. Also, try somehow to discover the failing regular expression, and report that. _sre.c wizards: This stack overflow happens in SRE_MATCH, alternating between the SRE_OP_BRANCH (line 991) and SRE_OP_MIN_UNTIL (line 1263). ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-06 05:04 Message: Logged In: YES user_id=71407 An additional piece of information: I observe the crashes (reproducibly) only when using SCons' -j option for parallel builds, using multiple CPU's. I believe the -j option involves the threading module. If I run the build using only one CPU it finishes without a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 From noreply at sourceforge.net Tue Aug 19 04:08:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 06:08:46 2003 Subject: [Python-bugs-list] [ python-Bugs-789926 ] "SetFrontProcess failed, -606" error for Tkinter under OS X Message-ID: Bugs item #789926, was opened at 2003-08-17 00:53 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: "SetFrontProcess failed,-606" error for Tkinter under OS X Initial Comment: Launching IDLE with the newest Aqua Tcl/Tk (8.4.4 with batteries included) leads to the error message "SetFrontProcess failed,-606" in the terminal window when I try to click on the IDLE window. Is this a Tcl/Tk issue or a Tkinter problem? I have tried to wipe as much of Tcl/Tk from my system and re-install and it still comes up (I could be having residual issues from my previous 8.3.3 which also had the same error). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-08-19 12:08 Message: Logged In: YES user_id=45365 Brett, this is a known issue. On MacOSX you can only run GUI programs if they are embedded in a ".app" bundle. If you do a framework build of Python (see instructions in Mac/OSX/README) then in addition to the "python" executable you will also get "pythonw" which runs your script in such a .app bundle. With a normal unix build this is conceivably doable, but you are on your own. An alternative (but I wouldn't recommend it) is to use X11-Tk: as this isn't an Aqua program it doesn't suffer from the .app problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-18 22:33 Message: Logged In: YES user_id=357491 This is a Darwin build built from CVS source (--with-pydebug -- prefix=$HOME/cvs_code --enable-ipv6 --enable-unicode=ucs4). There is no pythonw to run (I thought that was a Windows-only thing?) and I have never used (nor know how to use) PackMan. I executed from the command-line by passing the script "idle" in my bin directory to my installed copy of CVS Python. If this turns out to be because of the Unicode switch again I am going to go nuts. =) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-18 10:34 Message: Logged In: YES user_id=45365 Brett, I need a few more details. Did you use the existing IDLE from 2.3 installed via PackMan, or a privately-built one? Or did you run from the command line? If so, you did remember to use "pythonw", not "python"? If you can repeat this problem using pythonw from the command line I would like a transcript, please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789926&group_id=5470 From noreply at sourceforge.net Tue Aug 19 06:17:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 08:17:21 2003 Subject: [Python-bugs-list] [ python-Bugs-774546 ] popen does not like filenames with spaces Message-ID: Bugs item #774546, was opened at 2003-07-20 04:29 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-19 04:17 Message: Logged In: YES user_id=139865 Yes, it works. This is also the same behaviour as os.system. os.popen2 allows one to pass either a quoted string or a sequence of strings (pfremy's suggested behaviour). It would be nice to have consistent functionality, and using a sequence would be easier when providing a list of files to be operated on. I am willing to provide a patch if this is the desired functionality. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 15:03 Message: Logged In: YES user_id=80475 Does it work for you if the filename is quoted: "thrill seeker.txt" ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 From noreply at sourceforge.net Tue Aug 19 07:52:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 09:53:07 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 13:23 Message generated for change (Comment added) made by jdalambert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- >Comment By: David Lambert (jdalambert) Date: 2003-08-19 08:52 Message: Logged In: YES user_id=845425 Over the weekend and through Monday I ran my system 24/7 with the previously attached code. There do not seem to be any problems, but I am waiting for your "blessing" before considering it a fix. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-16 18:09 Message: Logged In: YES user_id=845425 I think I may have a fix. Check out the attached file. It seems to work for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 15:07 Message: Logged In: YES user_id=33168 Wow, it sure does leak! Checked in as: Objects/fileobject.c 2.180 Still needs a test. Leaving open until I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Tue Aug 19 07:58:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 09:59:05 2003 Subject: [Python-bugs-list] [ python-Bugs-783789 ] SIGSEGV in _sre.c (IRIX 6.5.20) Message-ID: Bugs item #783789, was opened at 2003-08-05 14:59 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Fredrik Lundh (effbot) Summary: SIGSEGV in _sre.c (IRIX 6.5.20) Initial Comment: Under IRIX (6.5.20) Python 2.3 (final) crashes with a core dump while executing a SCons job (www.scons.org). I've recompiled Python with -g but the behavior is the same. Here is the beginning of the dbx stack trace: dbx version 7.3 MR 55458_Apr30_MR Apr 30 1999 13:44:41 dbx Warning: Unknown processor type 0xe, assuming this is not an R8000 Core from signal SIGSEGV: Segmentation violation (dbx) where > 0 mark_save(state = , lo = , hi = 0, mark_stack_base = (nil)) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":289, 0x10107bc4] 1 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 669) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":979, 0x10109d74] 2 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 668) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 3 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 667) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 4 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 666) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] 5 sre_match(state = 0x10840c78, pattern = 0x10207ef0, level = 665) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":991, 0x10109ea0] 6 sre_match(state = 0x10840c78, pattern = 0x10207f10, level = 664) ["/txusr/rwgrosse/selfx/Python- 2.3/Modules/_sre.c":1263, 0x1010ad24] The alternation of _sre.c:991, _sre.c:1263 continues to the end of the dbx output which stops at 99; the value of level is decreasing monotonously. To reproduce upload this file to an IRIX machine: http://cci.lbl.gov/cctbx_build/send_octet_stream.cgi? source=results/2003_08_04_2056/cctbx_python_23_ bundle.selfx In a new, empty directory enter the command: perl cctbx_python_23_bundle.selfx When prompted enter the number of available CPU's and wait for the Python 2.3 installation to finish (log is in the file py_install_log). The newly compiled Python is used to start a SCons build procedure. The crash occurs a few files into the process of compiling C++ sources. I've tried the exact same source code under Redhat 8.0. There it finishes without a crash. Therefore I am thinking you will need an IRIX machine to reproduce the crash. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-19 06:58 Message: Logged In: YES user_id=71407 Below is the output of hinv. I have no clue how to find the regular expression without having a traceback. Is there some place in _sre.c where I could insert a print statement? 16 400 MHZ IP27 Processors CPU: MIPS R12000 Processor Chip Revision: 3.5 FPU: MIPS R12010 Floating Point Chip Revision: 3.5 Main memory size: 4096 Mbytes Instruction cache size: 32 Kbytes Data cache size: 32 Kbytes Secondary unified instruction/data cache size: 8 Mbytes Integral SCSI controller 12: Version Fibre Channel AIC- 1160, revision 2 RAID controller: unit 0 on SCSI controller 12 RAID lun: unit 0, lun 3 on SCSI controller 12 RAID lun: unit 0, lun 4 on SCSI controller 12 RAID lun: unit 0, lun 5 on SCSI controller 12 Integral SCSI controller 6: Version Fibre Channel AIC- 1160, revision 2 RAID controller: unit 0 on SCSI controller 6 RAID lun: unit 0, lun 0 on SCSI controller 6 RAID lun: unit 0, lun 1 on SCSI controller 6 RAID lun: unit 0, lun 2 on SCSI controller 6 Integral SCSI controller 14: Version Fibre Channel AIC- 1160, revision 2 Integral SCSI controller 2: Version QL1040B (rev. 2), single ended Integral SCSI controller 3: Version QL1040B (rev. 2), differential Integral SCSI controller 4: Version QL1040B (rev. 2), differential Integral SCSI controller 5: Version QL1040B (rev. 2), differential Integral SCSI controller 9: Version Fibre Channel QL2200 RAID controller: unit 0 on SCSI controller 9 RAID lun: unit 0, lun 7 on SCSI controller 9 Integral SCSI controller 1: Version QL1040B (rev. 2), single ended Tape drive: unit 5 on SCSI controller 1: DAT Integral SCSI controller 0: Version QL1040B (rev. 2), single ended Disk drive: unit 1 on SCSI controller 0 Disk drive: unit 2 on SCSI controller 0 Disk drive: unit 3 on SCSI controller 0 CDROM: unit 6 on SCSI controller 0 Integral SCSI controller 10: Version QL1040B (rev. 2), single ended CDROM: unit 6 on SCSI controller 10 Integral SCSI controller 11: Version QL1040B (rev. 2), single ended Integral SCSI controller 13: Version Fibre Channel AIC- 1160, revision 2 Integral SCSI controller 7: Version Fibre Channel AIC- 1160, revision 2 Integral SCSI controller 8: Version Fibre Channel QL2200 RAID controller: unit 0 on SCSI controller 8 RAID lun: unit 0, lun 0 on SCSI controller 8 RAID lun: unit 0, lun 2 on SCSI controller 8 Integral SCSI controller 15: Version Fibre Channel AIC- 1160, revision 2 IOC3/IOC4 serial port: tty1 IOC3/IOC4 serial port: tty3 IOC3/IOC4 serial port: tty2 IOC3/IOC4 serial port: tty4 Fast Ethernet: ef1, version 1, module 2, slot io1, pci 2 Integral Fast Ethernet: ef0, version 1, module 1, slot io1, pci 2 Gigabit Ethernet: eg0, module 2, XIO slot io3, firmware version 12.4.10 ATM PCA-200E OC-3: module 1, xio_slot 2, pci_slot 0, unit 0 Origin PCI XIO board, module 1 slot 2: Revision 4 Origin FIBRE CHANNEL board, module 2 slot 6: Revision 4 Origin FIBRE CHANNEL board, module 1 slot 7: Revision 4 Origin MSCSI board, module 1 slot 8: Revision 4 Origin FIBRE CHANNEL board, module 2 slot 10: Revision 4 Origin BASEIO board, module 1 slot 1: Revision 4 Origin BASEIO board, module 2 slot 1: Revision 4 IOC3/IOC4 external interrupts: 2 IOC3/IOC4 external interrupts: 1 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-19 01:41 Message: Logged In: YES user_id=539787 Ralf: what machine are you working on? Origin? Please specify # of CPU's, IP##. This to help me reproduce the problem. Also, try somehow to discover the failing regular expression, and report that. _sre.c wizards: This stack overflow happens in SRE_MATCH, alternating between the SRE_OP_BRANCH (line 991) and SRE_OP_MIN_UNTIL (line 1263). ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-08-05 19:04 Message: Logged In: YES user_id=71407 An additional piece of information: I observe the crashes (reproducibly) only when using SCons' -j option for parallel builds, using multiple CPU's. I believe the -j option involves the threading module. If I run the build using only one CPU it finishes without a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783789&group_id=5470 From noreply at sourceforge.net Tue Aug 19 09:02:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 11:02:57 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 19:59 Message generated for change (Comment added) made by netytan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- >Comment By: mark lee smith (netytan) Date: 2003-08-19 15:02 Message: Logged In: YES user_id=797196 I get the same results as you. I have no idea where this error is coming form then, and I?m only getting these results from this box, I tested it on XP and it worked fine. No sign of the elusive worker thread anywhere. Comfused but since this doesn't appear to be a problem with Python and more with ME I can live with it :) Thanks for all your help guys, Have fun, Mark. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 11:01 Message: Logged In: YES user_id=539787 Perhaps this has to do only with your version of IDLE? In the current CVS, various greps for "orker", "recieved" etc did not show up with something relevant. If you are sure about the "Worker" spelling, try this script in your Millenium windows: ### code start import sys, os, itertools for dirname, dirnames, filenames in os.walk(sys.prefix): joiner = os.path.join.__get__(dirname) for filename in itertools.imap(joiner, filenames): data = file(filename, "rb").read() if "Worker" in data: print filename ### code end this searches your whole python installation directory, for /any/ file containing the string "Worker". A run on a 2.3b2 install showed these files: C:\PY.23\Lib\distutils\bcppcompiler.py C:\PY.23\Lib\distutils\ccompiler.py C:\PY.23\Lib\distutils\msvccompiler.py ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-17 18:35 Message: Logged In: YES user_id=797196 The problem can also been see when running IDLE (idle.py intead of the idle.pyw). When you close the program the "worker thread" message appears in the Python window before it closes. My conclusion is that this error is definatly to do with the socket module (The version of IDLE packaged in 2.3 uses sockets). What chages were made to the socket module in 2.3? Also has anyone else knoticed this error? Any help would be very appreciated, Thanks, Mark. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-12 23:53 Message: Logged In: YES user_id=797196 Ok I've spent allot of my free time working on this now and I'm pretty sure it isn't in the urllib module. The same message is displayed when using smtplib and sendmail. Both modules use the socket module, but I am not sure about searching that for the message since it is writen in C (A lang' i've only brushed with a few times) plus i'm not sure if this has been changed since 2.2.. I could probably upgrade my version at home and see if i get the same message but i'm a little reluctant to do that. Sorry cannon, I don't know much about Macs or Mac OS :) Hope this helps, let me know what you think. Am not sure where to go next. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 20:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-09 06:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 21:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Tue Aug 19 09:05:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Aug 19 11:05:25 2003 Subject: [Python-bugs-list] [ python-Bugs-785584 ] urllib output: Worker thread.. Message-ID: Bugs item #785584, was opened at 2003-08-08 19:59 Message generated for change (Settings changed) made by netytan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: mark lee smith (netytan) Assigned to: Nobody/Anonymous (nobody) Summary: urllib output: Worker thread.. Initial Comment: Hi all, I've used urlib many times before and have never got anything like this.. therefore i'm assuming this is a new thing in 2.3. because i've only been seeing this since I upgraded my Python version. Anyway At the end of a program that uses urllib.urlopen() this line appears Worker thread [ 4291533751 ] : recieved quit event And even if the program doesn't output anything it still appears, it's not really a big problem but it is very anoying! If somone could explain it I would much appreciate it. I've attach a sample program (i've tested it with a few smaller programs and get the same output) Mark. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-19 15:02 Message: Logged In: YES user_id=797196 I get the same results as you. I have no idea where this error is coming form then, and I?m only getting these results from this box, I tested it on XP and it worked fine. No sign of the elusive worker thread anywhere. Comfused but since this doesn't appear to be a problem with Python and more with ME I can live with it :) Thanks for all your help guys, Have fun, Mark. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-18 11:01 Message: Logged In: YES user_id=539787 Perhaps this has to do only with your version of IDLE? In the current CVS, various greps for "orker", "recieved" etc did not show up with something relevant. If you are sure about the "Worker" spelling, try this script in your Millenium windows: ### code start import sys, os, itertools for dirname, dirnames, filenames in os.walk(sys.prefix): joiner = os.path.join.__get__(dirname) for filename in itertools.imap(joiner, filenames): data = file(filename, "rb").read() if "Worker" in data: print filename ### code end this searches your whole python installation directory, for /any/ file containing the string "Worker". A run on a 2.3b2 install showed these files: C:\PY.23\Lib\distutils\bcppcompiler.py C:\PY.23\Lib\distutils\ccompiler.py C:\PY.23\Lib\distutils\msvccompiler.py ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-17 18:35 Message: Logged In: YES user_id=797196 The problem can also been see when running IDLE (idle.py intead of the idle.pyw). When you close the program the "worker thread" message appears in the Python window before it closes. My conclusion is that this error is definatly to do with the socket module (The version of IDLE packaged in 2.3 uses sockets). What chages were made to the socket module in 2.3? Also has anyone else knoticed this error? Any help would be very appreciated, Thanks, Mark. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-12 23:53 Message: Logged In: YES user_id=797196 Ok I've spent allot of my free time working on this now and I'm pretty sure it isn't in the urllib module. The same message is displayed when using smtplib and sendmail. Both modules use the socket module, but I am not sure about searching that for the message since it is writen in C (A lang' i've only brushed with a few times) plus i'm not sure if this has been changed since 2.2.. I could probably upgrade my version at home and see if i get the same message but i'm a little reluctant to do that. Sorry cannon, I don't know much about Macs or Mac OS :) Hope this helps, let me know what you think. Am not sure where to go next. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-09 20:25 Message: Logged In: YES user_id=357491 If you could attempt to figure out where the message is coming from that would be great since I have no clue what would be causing it. As for the file path thing, I was executing from my CVS directory with your files on my desktop so I did not have my working directory the same as where the script was. ---------------------------------------------------------------------- Comment By: mark lee smith (netytan) Date: 2003-08-09 06:50 Message: Logged In: YES user_id=797196 I agree with you.. I have a few box's, the error is on Windows me box. I havn't had the oppertunity to upgrade the version of Python on my XP box because it is running some fairly important stuff i'm working on but I plan on upgrading as soon as I can. I have a FreeBSD box aswell but no Python as of yet. My friend is running FreeBSD and doesn't see the Worker Thread either.. I did the same search after I posted this message yesterday and couldnt fine anything either. If take into account my lack of copying skills then that could explain the miss spelling, I know we do spell some words differently from american english. Thanks for the tip, as far as I'm aware if you open a file with just the files names then Python automatically looks in the same dir as the script. So i'm a little unsure why I would want to use an absolute file name when the file is right there :). Thanks for your help. Mark. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-08 21:21 Message: Logged In: YES user_id=357491 On my OS X machine I don't get that message. What OS are you using, Mark? If you look at urllib it does not import any threading module. I ran ``egrep -r "Worker thread" *`` and it found nothing. Search also failed for "recieved quit event" (which "recieved" is misspelled so you would think a search would turn it up easily). I have a sneaking suspicion this might be platform- specific. Also, just a tip on opening files relative to the running code: it's best to make it absolute by making the path like so: path = os.path.join(os.path.split(__file__)[0], "file.txt")) This makes the path absolute so if people (like me) try to execute your script from another directory Python doesn't say it can't find the file you are referencing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=785584&group_id=5470 From noreply at sourceforge.net Thu Aug 21 21:40:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:42:05 2003 Subject: [Python-bugs-list] [ python-Bugs-788520 ] Queue class has logic error when non-blocking Message-ID: Bugs item #788520, was opened at 2003-08-14 04:57 Message generated for change (Comment added) made by gazzadee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gary Donovan (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: Queue class has logic error when non-blocking Initial Comment: Looking at the Queue class, I noticed that it might incorrectly raise a Full/Empty Exception when called with block=False. This leads to the following undesirable behaviour: * Full exception raised when Queue not full * Full exception raised when Queue has no maxsize Here's my logic (for put(), but get() is similar): First part of code for put, in Queue.py: def put(self, item, block=1): if block: self.fsema.acquire() elif not self.fsema.acquire(0): raise Full Now, for the purposes of raising a Full exception, we are assuming that fsema is locked if and only if the Queue is full. BUT, it seems that fsema is locked every time an item is added to the Queue, even if that item would not make the Queue full. Hence, it might be possible for a Full exception to be raised, when fsema is locked due to adding an item that would not actually make the Queue full. An example... * Queue with maxsize 10, currently 5 objects in it. * Threads T1 and T2, both trying to add an item with Queue.put(item, block=True). * This should obviously be fine, resulting in a Queue with 7 items. [1] Call T1.put(item1, block=True) [2] Call T2.put(item2, block=True) [3] T1 grabs fsema and mutex, but then the current thread changes before they are released... [4] T2 cannot acquire fsema (since T1 currently has it), and so raises the Full exception (incorrectly) Of course, I may have misunderstood something, since I haven't been able to consistently reproduce the problem (threading errors are so vexing). I have no easy solution to this issue (redo the class using a threading.BoundedSemaphore to count the Queue length?). My python version: Python 2.2.2 (#1, Feb 24 2003, 17:36:09) [GCC 3.0.4 (Mandrake Linux 8.2 3.0.4-2mdk)] on linux2 ---------------------------------------------------------------------- >Comment By: Gary Donovan (gazzadee) Date: 2003-08-22 03:40 Message: Logged In: YES user_id=693152 Okay, that makes more sense. So, loosely expressed, non-blocking means there's no way the user can put the Queue in a blocked state (and especially not deadlocked) - as with your example of waiting forever on a get call. But, obviously, internal locks can always be used (in a careful manner). I think that's closer to my implicit understand of blocking that I was trying to express. In the case of put/get, I had a slightly different expectation about what we were blocking for (as we have already dicscussed at length :-). Anyway, I've knocked up some modifications to the documentation, which you're welcome to use, abuse, or reject out of hand. I've done this in the form of modifications to the source code. I assume that's the correct approach, but the 2.3 source code and 2.3 HTML documentation seem to be a bit different (so I ended up incorporating the relevant HTML doco into the python source doco, then modifying that). The patch is the output from: % diff Queue_v2_3.py Queue_doc_change.py ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 05:41 Message: Logged In: YES user_id=31435 It depends on what you mean by "blocking" . If the thread implementation schedules fairly, it's impossible for self.mutex to be held for a "long" time by any thread -- unlike esema and fsema, self.mutex is used only for mutual exclusion over brief sections of code that don't wait for anything, and nothing Queue clients do can cause self.mutex to be held for an arbitrarily long time (a spectacularly bad OS implementation of thread scheduling could, but that's out of the user's-- and out of Python's --hands). The usual meaning of "blocking" is that clients *can* do something to get the system into a state where a call can take arbitrarily long to complete (while assuming fair thread scheduling). The obvious example here is that Queue.get() can take forever if the Queue is empty and the app stops adding anything to the Queue. There's nothing (sane) the app can do that can make Queue.get_nowait() take forever. BTW, I hope you're looking at the 2.3 code here! Queue is more complicated in 2.3 because these methods have also grown optional timeout arguments. If you're really worried about "spurious" Full exceptions, doing a blocking 2.3 Queue.put() call with a short timeout will try to grab fsema several times before giving up. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 04:52 Message: Logged In: YES user_id=693152 Whoops - let's try that question in a clearer way: When you do a non-blocking call to put(), why does it acquire mutex in a blocking way (ie. "put(block=False)" will call "mutex.acquire()", which could block whilst acquiring mutex). I thought the theory was that you *never* block anywhere. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 04:32 Message: Logged In: YES user_id=31435 We acquire a mutex with a blocking call because the use of a blocking call announces that the client is *willing* to block, and nothing about the state of a Queue can be changed without acquiring a lock first. So it wouldn't make sense not to acquire a lock in that case. I have no objection at all to improving the docs. They appear to be what they are now because the original version of the Queue module didn't have a non-blocking put() method, or a Full exception. I added those 7(!) years later, in 1999. Development was done by emailing changes to Guido at that time, though, and doc changes were often dropped on the floor. If you can work up a doc patch to supply words that would make better sense to you, that would be great. ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 03:53 Message: Logged In: YES user_id=693152 First up, you're right that non-blocking calls are unusual. This isn't exactly a critical matter for me :-) Okay, I have misunderstood the meaning of non-blocking calls - so it actually means "ensure we never under any circumstances block". Why then do we acquire mutex with a blocking call? I am not suggesting there's anything wrong with the naming of Full (amusing as your suggestion is :-). Of course you can't completely describe how an exception will be used in it's name. It just seems more intuitive for put's documentation to fully and unambiguously describe when an exception is raised, rather than to have part of the function documentation ("or locked") in the Exception documentation. More straightforward, etc. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-18 03:22 Message: Logged In: YES user_id=31435 The primary point of a non-blocking call is never to block. That's the common meaning of "non-blocking" (in or out of Python). After all, a "non-blocking" call that *could* block is useless for apps that need not to block. If you're willing to block, use the blocking methods (which most apps do use, BTW -- using the non-blocking methods is unusual). The Full exception isn't raised incorrectly. "Full" is just 4 letters strung together, and is only meant to be suggestive and convenient -- its full meaning is explained in the docs, albeit somewhat cryptically. I don't think it would be a real improvement to, e.g., rename this exception to FullOrMaybeNotFullButCheckingForThatCouldPotentiallyBlockSo WeSkippedThat . ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-08-18 02:55 Message: Logged In: YES user_id=693152 Sorry - my fault. I didn't read that part of the doco well enough. However, is it an issue that important behaviour of a function is described separately to the function (ie. in the exception)? Could we put a general note in the put/get documentation also (Eg. "In the current implementation the Full exception may sometimes be raised incorrectly.") Also, I may have the wrong expectations for how this class should behave. My assumption was that put(block=False) means don't block waiting for a slot in the queue, but it's implicitly okay to block for other reasons (eg. internal data sharing, as actually happens with mutex). Was this incorrect? I'll see if I can think up an alternative implementation over the next few days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-17 20:50 Message: Logged In: YES user_id=31435 Yes, but unless it's a screamingly obvious non-bug I like to wait at least a week to see whether somebody else has a clever approach that works as well but without the surprising parts. The docs in this case aren't terribly clear, because they really can't explain the whole truth without explaining the implementation. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-17 20:30 Message: Logged In: YES user_id=80475 Can this be closed as invalid? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-14 14:59 Message: Logged In: YES user_id=31435 As the docs say (ALL CAPS emphasis added), """ exception Full Exception raised when non-blocking put() (or put_nowait()) is called on a Queue object which is full OR LOCKED. """ and similarly for Empty. The primary point of a non-blocking call is never to block, and that's why "or locked" is in the docs. A BoundedSemaphore (or any other "reliable" synchronization gimmick) could block, so cannot be used. In practice, it doesn't matter: a Queue user who wants to use non-blocking calls has to be prepared for Full or Empty exceptions, and that's the end of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788520&group_id=5470 From noreply at sourceforge.net Thu Aug 21 12:02:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:42:38 2003 Subject: [Python-bugs-list] [ python-Bugs-792656 ] Misleading [i:j:k] slicing description Message-ID: Bugs item #792656, was opened at 2003-08-21 19:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792656&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raoul Gough (raoulgough) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading [i:j:k] slicing description Initial Comment: Section 2.2.6 (Sequence types), note 5 from the table says: "The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that 0 <= n < abs(i-j). [...]" However, n should only range up to (j-i)//k Note also that (j-i)//k correctly specifies the results for negative values of k, and empty sequence returns where signof(j-i) != signof (k). Maybe worth mentioning that k != 0 (!! :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792656&group_id=5470 From noreply at sourceforge.net Thu Aug 21 12:02:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:42:52 2003 Subject: [Python-bugs-list] [ python-Bugs-789519 ] CSV reader does not parse Mac line endings Message-ID: Bugs item #789519, was opened at 2003-08-15 17:16 Message generated for change (Comment added) made by bbum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (lmeyn) Assigned to: Skip Montanaro (montanaro) Summary: CSV reader does not parse Mac line endings Initial Comment: #Test code: import csv import traceback class excel_mac(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_mac", excel_mac) class excel_unix(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\n' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_unix", excel_unix) testdata = range(10) for dialect in ["excel","excel_unix","excel_mac"]: try: print '\n Testing dialect "%s"' % dialect test = file('test.csv','w') writer = csv.writer(test,dialect=dialect) for i in range(3): writer.writerow(testdata) test.close() test = file('test.csv','r') reader = csv.reader(test,dialect=dialect) for row in reader: print row except: traceback.print_exc() #Results """ Testing dialect "excel" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_unix" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_mac" Traceback (most recent call last): File "/Users/lmeyn/Desktop/testcsv.py", line 36, in ? print row Error: newline inside string """ ---------------------------------------------------------------------- Comment By: Bill Bumgarner (bbum) Date: 2003-08-21 14:02 Message: Logged In: YES user_id=103811 Why doesn't the csv module use the lineterminator for reading files? As it is, the lineterminator appears to be used only for the writing of rows to a file. This, of course, means that csv will quite happily write a file that it cannot subsequently read with the same dialect. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-08-21 12:01 Message: Logged In: YES user_id=44345 We've been discussing this bug on the csv mailing list. I suspect we will make a change to U mode for 2.3.1 and 2.4, though we have yet to test the proposed change. Skip ---------------------------------------------------------------------- Comment By: Larry Meyn (lmeyn) Date: 2003-08-21 11:44 Message: Logged In: YES user_id=28540 If I open files using the universal, 'U', mode this is not a problem. Too bad the 'U' mode is not the default. (I know, there is a lot of *nix python code out there that opens binary files as text, and it would all break if 'U' were the default.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 From noreply at sourceforge.net Thu Aug 21 11:45:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:43:14 2003 Subject: [Python-bugs-list] [ python-Bugs-792649 ] RESET_ERROR is not defined(logging module) Message-ID: Bugs item #792649, was opened at 2003-08-22 02:45 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=792649&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: RESET_ERROR is not defined(logging module) Initial Comment: ConfigStreamHandler class(logging/config.py) has the following code in its handle method: except socket.error, e: if type(e.args) != types.TupleType: raise else: errcode = e.args[0] if errcode != RESET_ERROR: raise However, RESET_ERROR is not defined. So if the handle method catches socket.error, this will raise NameError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792649&group_id=5470 From noreply at sourceforge.net Thu Aug 21 10:01:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:43:32 2003 Subject: [Python-bugs-list] [ python-Bugs-789519 ] CSV reader does not parse Mac line endings Message-ID: Bugs item #789519, was opened at 2003-08-15 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=789519&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (lmeyn) Assigned to: Skip Montanaro (montanaro) Summary: CSV reader does not parse Mac line endings Initial Comment: #Test code: import csv import traceback class excel_mac(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_mac", excel_mac) class excel_unix(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\n' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_unix", excel_unix) testdata = range(10) for dialect in ["excel","excel_unix","excel_mac"]: try: print '\n Testing dialect "%s"' % dialect test = file('test.csv','w') writer = csv.writer(test,dialect=dialect) for i in range(3): writer.writerow(testdata) test.close() test = file('test.csv','r') reader = csv.reader(test,dialect=dialect) for row in reader: print row except: traceback.print_exc() #Results """ Testing dialect "excel" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_unix" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_mac" Traceback (most recent call last): File "/Users/lmeyn/Desktop/testcsv.py", line 36, in ? print row Error: newline inside string """ ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-08-21 11:01 Message: Logged In: YES user_id=44345 We've been discussing this bug on the csv mailing list. I suspect we will make a change to U mode for 2.3.1 and 2.4, though we have yet to test the proposed change. Skip ---------------------------------------------------------------------- Comment By: Larry Meyn (lmeyn) Date: 2003-08-21 10:44 Message: Logged In: YES user_id=28540 If I open files using the universal, 'U', mode this is not a problem. Too bad the 'U' mode is not the default. (I know, there is a lot of *nix python code out there that opens binary files as text, and it would all break if 'U' were the default.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 From noreply at sourceforge.net Thu Aug 21 09:44:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:43:57 2003 Subject: [Python-bugs-list] [ python-Bugs-789519 ] CSV reader does not parse Mac line endings Message-ID: Bugs item #789519, was opened at 2003-08-15 14:16 Message generated for change (Comment added) made by lmeyn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (lmeyn) Assigned to: Skip Montanaro (montanaro) Summary: CSV reader does not parse Mac line endings Initial Comment: #Test code: import csv import traceback class excel_mac(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\r' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_mac", excel_mac) class excel_unix(csv.Dialect): delimiter = ',' quotechar = '"' doublequote = True skipinitialspace = False lineterminator = '\n' quoting = csv.QUOTE_MINIMAL csv.register_dialect("excel_unix", excel_unix) testdata = range(10) for dialect in ["excel","excel_unix","excel_mac"]: try: print '\n Testing dialect "%s"' % dialect test = file('test.csv','w') writer = csv.writer(test,dialect=dialect) for i in range(3): writer.writerow(testdata) test.close() test = file('test.csv','r') reader = csv.reader(test,dialect=dialect) for row in reader: print row except: traceback.print_exc() #Results """ Testing dialect "excel" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_unix" ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9'] Testing dialect "excel_mac" Traceback (most recent call last): File "/Users/lmeyn/Desktop/testcsv.py", line 36, in ? print row Error: newline inside string """ ---------------------------------------------------------------------- >Comment By: Larry Meyn (lmeyn) Date: 2003-08-21 08:44 Message: Logged In: YES user_id=28540 If I open files using the universal, 'U', mode this is not a problem. Too bad the 'U' mode is not the default. (I know, there is a lot of *nix python code out there that opens binary files as text, and it would all break if 'U' were the default.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789519&group_id=5470 From noreply at sourceforge.net Thu Aug 21 09:37:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:44:18 2003 Subject: [Python-bugs-list] [ python-Bugs-792570 ] SimpleXMLRPCServer cannot handle large requests Message-ID: Bugs item #792570, was opened at 2003-08-21 11: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=792570&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marc-Andr? Morissette (morissette) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer cannot handle large requests Initial Comment: SimpleXMLRPCServer throws a WSAEINTR ioerror on large XML-RPC requests. Under Windows, the socket.read() method cannot seem to handle large (tens of megabytes) reads (could be a Python specific problem). This means that very large XML-RPC requests can cause the exception. Here is a tentative patch against 2.2.3 to fix the problem. It should be easy to port it to 2.3 --- /cygdrive/c/Python22/Lib/SimpleXMLRPCServer.py 2003-07-09 14:16:52.000000000 -0400 +++ /cygdrive/z/SimpleXMLRPCServer.py 2003-08-21 11:01:19.000000000 -0400 @@ -73,6 +73,8 @@ import SocketServer import BaseHTTPServer import sys +import cStringIO class SimpleXMLRPCRequestHandler (BaseHTTPServer.BaseHTTPRequestHandler): """Simple XML-RPC request handler class. @@ -95,7 +97,14 @@ try: # get arguments - data = self.rfile.read(int(self.headers["content- length"])) + max_chunk_size = 10000000 + content_length = int(self.headers["content- length"]) + buffer = cStringIO.StringIO() + for offset in range(0, content_length, max_chunk_size): + chunk_size = min(content_length - offset, max_chunk_size) + buffer.write(self.rfile.read(chunk_size)) + data = buffer.getvalue() + buffer.close() params, method = xmlrpclib.loads(data) # generate response ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&group_id=5470 From noreply at sourceforge.net Thu Aug 21 09:22:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:44:40 2003 Subject: [Python-bugs-list] [ python-Bugs-792558 ] csv Message-ID: Bugs item #792558, was opened at 2003-08-21 15:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792558&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Otten (potten) Assigned to: Nobody/Anonymous (nobody) Summary: csv Initial Comment: To conform with the documentation, csv.DictReader (and possibly DictWriter) should accept keyword arguments to specify a dialect on the fly and forward them to its reader instance: class DictReader: def __init__(self, f, fieldnames, restkey=None, restval=None, dialect="excel", *args, **kwd): self.fieldnames = fieldnames # list of keys for the dict self.restkey = restkey # key to catch long rows self.restval = restval # default value for short rows self.reader = reader(f, dialect, *args, **kwd) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792558&group_id=5470 From noreply at sourceforge.net Thu Aug 21 04:16:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:46:26 2003 Subject: [Python-bugs-list] [ python-Bugs-789262 ] __getattr__ and metaclasses Message-ID: Bugs item #789262, was opened at 2003-08-15 10:18 Message generated for change (Comment added) made by michele_s You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789262&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gon?alo Rodrigues (grodr) Assigned to: Nobody/Anonymous (nobody) Summary: __getattr__ and metaclasses Initial Comment: This came out from a thread in comp.lang.python: Here?s the reference: http://groups.google.pt/groups?hl=pt-PT&lr=&ie=UTF- 8&threadm=md94jvccu02b9dv5890k34629rkot79roj% 404ax.com&rnum=6&prev=/groups%3Fq%3Dgon%25C3% 25A7alo%2Brodrigues%2Bgroup:comp.lang.python.*% 26hl%3Dpt-PT%26lr%3D%26ie%3DUTF-8%26group% 3Dcomp.lang.python.*%26selm% 3Dmd94jvccu02b9dv5890k34629rkot79roj% 25404ax.com%26rnum%3D6 Consider the following example (provided by M. Simionato) >>> class M(type): ... def __getattr__(self, name): ... if name == '__iter__': ... return lambda self: iter([]) ... >>> class C(object): ... __metaclass__ = M ... >>> C.__iter__ at 0x0110E8F0> >>> c = C() >>> iter(c) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence >>> This means that the iterator machinery does not check __getattr__ (or __getattribute__ for that matter ? I have made the test). The Language Reference says: ?A class can implement certain operations that are invoked by special syntax (such as arithmetic operations or subscripting and slicing) by defining methods with special names.? Which does not throw much light on the matter at hand. So there are two ways we can view the above: (A) It?s a bug. This is the one I favour ;-). Arguing by contradiction, not being considered a bug means that there is a very special distinction being made when it comes to attribute lookup of special names. I tend to follow the Gang of Four?s main injunction ?Prefer composition to inheritance?. Composition is great in Python precisely because of the __getattr__ hook. Not being able to use __getattr__ in metaclasses to trap special names surely hampers that role somewhat. (B) It?s not a bug. Then at least I think that the documentation should be worded more accurately. Quoting A. Martelli on the same thread ?__getattr__ is not a BINDING of the special method, though it may be considered a DEFINITION of it, which is why the current phrase in the Language Reference is not 100% correct and complete -- only 99.44%, and I agree that the remaining 0.56% _is_ a delicate defect in the documentation.? With my best regards, G. Rodrigues ---------------------------------------------------------------------- Comment By: Michele Simionato (michele_s) Date: 2003-08-21 06:16 Message: Logged In: YES user_id=583457 Two comments: 1. The credit for discovering this "issue" goes to Bjorn Pettersen, not to me. 2. The issue is NOT with metaclasses, the title should be "special methods and __getattr__" The metaclass works perfectly fine and X.__iter__(x) works. The problem is with the "iter" builtin, since iter(x) DOES NOT call X.__iter__(x). Same with str, len, etc. Metaclasses are not guilty here! Michele ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789262&group_id=5470 From noreply at sourceforge.net Wed Aug 20 12:50:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:48:34 2003 Subject: [Python-bugs-list] [ python-Bugs-792101 ] urllib.urlopen for https doesn't always provide readlines Message-ID: Bugs item #792101, was opened at 2003-08-20 14: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=792101&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen for https doesn't always provide readlines Initial Comment: The doc for urllib.urlopen says that the object returned supports readlines. However, I have a simple case where it doesn't seem to raise IOError, but readlines isn't provided. The initial problem seems to be in addbase.__init__, which tests fp for readlines, but doesn't do anything if it's not there. Presumably it should either provide a dummy or raise an error (or alternatively, change the documented behavior to match). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 From noreply at sourceforge.net Wed Aug 20 10:02:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:49:27 2003 Subject: [Python-bugs-list] [ python-Bugs-791968 ] Arguments tooltip wrong if def contains tuple Message-ID: Bugs item #791968, was opened at 2003-08-20 18:16 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Kurt B. Kaiser (kbk) Summary: Arguments tooltip wrong if def contains tuple Initial Comment: This happens in IDLE on Windows 2000, from 2.3 EXE installer. Type the following: >>> def f((a,b), c): print a, b, c >>> f( The tooltip shows up containing the following exact string (but the triple quotes): """(.0, c)""" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-08-20 19:02 Message: Logged In: YES user_id=539787 I tried this: def f((a,b), c, (d,e)): pass and f.func_code.co_varnames is ('.0', 'c', '.4', 'a', 'b', 'd', 'e') That means .0 and .4 are dummy placeholders for the argument tuples. I couldn't find a direct way to know the length of each tuple, though --unless one analyzes the first UNPACK_SEQUENCE bytecodes of fob.func_code.co_code, and then uses the tuple fob.func_code.co_varnames [fob.func_code.co_argcount:] to recreate the tuples; should we get into this trouble, or just do a regular expression replace a la: argText = "(%s)" % re.sub("\.\d+", "", argText) at line 144? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-20 18:44 Message: Logged In: YES user_id=539787 Quite fast, Neal! :) It seems it's not exactly an IDLE bug; check ToolTip.py, line 134 (vanilla 2.3); it's the f.func_code.co_varnames that returns this tuple: ('.0', 'c', 'a', 'b') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 From noreply at sourceforge.net Wed Aug 20 09:44:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:49:40 2003 Subject: [Python-bugs-list] [ python-Bugs-791968 ] Arguments tooltip wrong if def contains tuple Message-ID: Bugs item #791968, was opened at 2003-08-20 18:16 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Kurt B. Kaiser (kbk) Summary: Arguments tooltip wrong if def contains tuple Initial Comment: This happens in IDLE on Windows 2000, from 2.3 EXE installer. Type the following: >>> def f((a,b), c): print a, b, c >>> f( The tooltip shows up containing the following exact string (but the triple quotes): """(.0, c)""" ---------------------------------------------------------------------- >Comment By: Christos Georgiou (tzot) Date: 2003-08-20 18:44 Message: Logged In: YES user_id=539787 Quite fast, Neal! :) It seems it's not exactly an IDLE bug; check ToolTip.py, line 134 (vanilla 2.3); it's the f.func_code.co_varnames that returns this tuple: ('.0', 'c', 'a', 'b') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 From noreply at sourceforge.net Wed Aug 20 09:40:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:49:54 2003 Subject: [Python-bugs-list] [ python-Bugs-791968 ] Arguments tooltip wrong if def contains tuple Message-ID: Bugs item #791968, was opened at 2003-08-20 11:16 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) >Assigned to: Kurt B. Kaiser (kbk) Summary: Arguments tooltip wrong if def contains tuple Initial Comment: This happens in IDLE on Windows 2000, from 2.3 EXE installer. Type the following: >>> def f((a,b), c): print a, b, c >>> f( The tooltip shows up containing the following exact string (but the triple quotes): """(.0, c)""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 From noreply at sourceforge.net Wed Aug 20 09:30:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:50:08 2003 Subject: [Python-bugs-list] [ python-Bugs-791445 ] Re: Bugs item #765456 Message-ID: Bugs item #791445, was opened at 2003-08-19 22:18 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791445&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Shawn Leard (sleard1) Assigned to: Nobody/Anonymous (nobody) Summary: Re: Bugs item #765456 Initial Comment: Regarding, Bugs item #765456, was opened at 2003-07-03 18:42 I have also recently ran into this same bug on Solaris 8 with Python-2.3. mars$ /files/local/src/Python-2.3/python test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImport_WithStuff (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImport_WithStuff (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ====================================================================== ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ====================================================================== ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ---------------------------------------------------------------------- Ran 26 tests in 0.097s FAILED (errors=2) Traceback (most recent call last): File "test_zipimport.py", line 215, in ? test_main() File "test_zipimport.py", line 211, in test_main CompressedZipImportTestCase File "/files/local/src/Python-2.3/Lib/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/files/local/src/Python-2.3/Lib/test/test_support.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-08-20 18:30 Message: Logged In: YES user_id=539787 Wouldn't it be more appropriate to annotate 765456 (this number reminds me of piano lessons :) than to create a new bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791445&group_id=5470 From noreply at sourceforge.net Wed Aug 20 09:16:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:50:20 2003 Subject: [Python-bugs-list] [ python-Bugs-791968 ] Arguments tooltip wrong if def contains tuple Message-ID: Bugs item #791968, was opened at 2003-08-20 18: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=791968&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: Arguments tooltip wrong if def contains tuple Initial Comment: This happens in IDLE on Windows 2000, from 2.3 EXE installer. Type the following: >>> def f((a,b), c): print a, b, c >>> f( The tooltip shows up containing the following exact string (but the triple quotes): """(.0, c)""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791968&group_id=5470 From noreply at sourceforge.net Tue Aug 19 15:32:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:57:29 2003 Subject: [Python-bugs-list] [ python-Bugs-791542 ] test_threading Message-ID: Bugs item #791542, was opened at 2003-08-19 17: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=791542&group_id=5470 Category: Build Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shawn Leard (sleard1) Assigned to: Nobody/Anonymous (nobody) Summary: test_threading Initial Comment: Due the problems reported with version 2.3 I thought I would give version 2.2.3 a shot. The problem I am having here is no matter what switches I pass configure to disable threading it still tries to test them and as a result the make test fails. 168 tests OK. 1 test failed: test_threading 24 tests skipped: test_al test_asynchat test_bsddb test_cd test_cl test_curses test_dl test_email_codecs test_fork1 test_gl test_imgfile test_linuxaudiodev test_minidom test_openpty test_pyexpat test_queue test_sax test_socket_ssl test_socketserver test_thread test_threaded_import test_threadedtempfile test_winreg test_winsound -------- ./configure --prefix=/usr/local --with-gnu-ld --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld --enable-nls --with-included-gettext --with-fpectl --with-threads=no --without-threads --disable-threads --with-gnu-as -------- mars$ /files/local/src/Python-2.2.3/python test_threading.py Traceback (most recent call last): File "test_threading.py", line 7, in ? import threading File "/files/local/src/Python-2.2.3/Lib/threading.py", line 5, in ? import thread ImportError: No module named thread ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791542&group_id=5470 From noreply at sourceforge.net Tue Aug 19 16:00:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:57:42 2003 Subject: [Python-bugs-list] [ python-Bugs-791445 ] Re: Bugs item #765456 Message-ID: Bugs item #791445, was opened at 2003-08-19 15:18 Message generated for change (Settings changed) made by sleard1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791445&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 8 Submitted By: Shawn Leard (sleard1) Assigned to: Nobody/Anonymous (nobody) Summary: Re: Bugs item #765456 Initial Comment: Regarding, Bugs item #765456, was opened at 2003-07-03 18:42 I have also recently ran into this same bug on Solaris 8 with Python-2.3. mars$ /files/local/src/Python-2.3/python test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImport_WithStuff (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImport_WithStuff (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ====================================================================== ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ====================================================================== ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ---------------------------------------------------------------------- Ran 26 tests in 0.097s FAILED (errors=2) Traceback (most recent call last): File "test_zipimport.py", line 215, in ? test_main() File "test_zipimport.py", line 211, in test_main CompressedZipImportTestCase File "/files/local/src/Python-2.3/Lib/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/files/local/src/Python-2.3/Lib/test/test_support.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791445&group_id=5470 From noreply at sourceforge.net Tue Aug 19 13:18:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:57:55 2003 Subject: [Python-bugs-list] [ python-Bugs-791445 ] Re: Bugs item #765456 Message-ID: Bugs item #791445, was opened at 2003-08-19 15: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=791445&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shawn Leard (sleard1) Assigned to: Nobody/Anonymous (nobody) Summary: Re: Bugs item #765456 Initial Comment: Regarding, Bugs item #765456, was opened at 2003-07-03 18:42 I have also recently ran into this same bug on Solaris 8 with Python-2.3. mars$ /files/local/src/Python-2.3/python test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImport_WithStuff (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImport_WithStuff (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ====================================================================== ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ====================================================================== ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ---------------------------------------------------------------------- Ran 26 tests in 0.097s FAILED (errors=2) Traceback (most recent call last): File "test_zipimport.py", line 215, in ? test_main() File "test_zipimport.py", line 211, in test_main CompressedZipImportTestCase File "/files/local/src/Python-2.3/Lib/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/files/local/src/Python-2.3/Lib/test/test_support.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791445&group_id=5470 From noreply at sourceforge.net Tue Aug 19 12:04:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:58:18 2003 Subject: [Python-bugs-list] [ python-Bugs-791397 ] Tutorial: mutable objects may be keys Message-ID: Bugs item #791397, was opened at 2003-08-19 14:04 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=791397&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Victor (brianhv) Assigned to: Nobody/Anonymous (nobody) Summary: Tutorial: mutable objects may be keys Initial Comment: http://python.org/doc/tut/node7.html#SECTION007400000000000000000 The tutorial section 5.4 ("Dictionaries") says, "Unlike sequences, which are indexed by a range of numbers, dictionaries are indexed by keys, which can be any immutable type; strings and numbers can always be keys." This strongly implies that only immutable objects may be keys, and I always assumed that to be the case. I have recently learned that is not true. I would suggest a change along the lines of "which can be any immutable type or mutuable types under some circumstances," with a link to further elaboration on what is required for a type to be hashable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791397&group_id=5470 From noreply at sourceforge.net Tue Aug 19 12:32:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 11:58:30 2003 Subject: [Python-bugs-list] [ python-Bugs-791410 ] Make logging consistent in the standard library Message-ID: Bugs item #791410, was opened at 2003-08-19 13: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=791410&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Matthew F. Barnes (mfbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: Make logging consistent in the standard library Initial Comment: Logging should be consistent in the standard library. Standard library modules that currently define their own logging functions should be updated to use the standard 'logging' module instead. Such modules include (not necessarily a complete list): asyncore.py BaseHTTPServer.py cgi.py doctest.py imaplib.py unittest.py distutils package ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=791410&group_id=5470 From noreply at sourceforge.net Tue Aug 19 18:29:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 12:01:06 2003 Subject: [Python-bugs-list] [ python-Bugs-687747 ] _iscommand() in webbrowser module Message-ID: Bugs item #687747, was opened at 2003-02-17 15:17 Message generated for change (Comment added) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: _iscommand() in webbrowser module Initial Comment: [From a post to python-help] Under KDE under Mandrake Linux the BROWSER environment variable is set to kfmclient openProfile webbrowsing The problem is that _iscommand() in the webbrowser module doesn't realize that only the first thing there is the name of the executable. It looks for an executable with that whole thing as its name and doesn't find one. Since the module doesn't use any browser it has found if BROWSER is set, it raises an error rather than opening the page. The possible fixes that are obvious to me all have potential disadvantages: One solution would be to assume that the name of the executable ran only up to the first space. But executables can have spaces in their names, especially on a Macintosh, I think. Another possibility would be not to call _iscommand() on anything in BROWSER. That would have the additional advantage of not requiring that the executable specified there be in a directory that's in the user's PATH. The problem with doing things this way is that it would be impossible to tell which of the browsers specified in BROWSER should be used until the user called open(). I'm prepared to work on a fix if given some guidance about the best way to go. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-08-20 10:29 Message: Logged In: YES user_id=6405 This is still an issue... has there been any movement on it outside of this bug report? I'm seeing the behaviour on Mandrake 9.1, KDE 3.1.3 that the module is finding the BROWSER env var as described above, and thus not finding a usable browser. As a fallback, the _tryorder shouldn't be *replaced* by BROWSER, but just prepended with its value. Sure, that means that the KDE BROWSER value will be ignored, but it'll still find konqueror. This approach works for me, and I'm sure it'll work for others who have "valid" BROWSER values :) Simple patch against python2.3 (sorry, sf will mangle this, but it's short): --- webbrowser.py 2003-08-20 10:28:07.000000000 +1000 +++ /usr/lib/python2.3/webbrowser.py 2003-08-04 10:18:17.000000000 +1000 @@ -354,7 +354,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). - _tryorder[0:0] = os.environ["BROWSER"].split(os.pathsep) + _tryorder = os.environ["BROWSER"].split(os.pathsep) for cmd in _tryorder: if not cmd.lower() in _browsers: ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 12:19 Message: Logged In: YES user_id=6380 You know, I have no idea why all the lower() business is there. Assigning to Fred Drake, maybe he knows more. (Fred, please treat this as a hot potato -- if you don't immediately know the answer, assign it back to me.) ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-03-03 07:43 Message: Logged In: YES user_id=198518 A week after posting ("webbrowser module under MacOS"), it hasn't gotten any replies. That suggests that Mac users either don't much care about the module or don't read comp.lang.python. If it's desirable merely to stop at the first space, it should be sufficient to replace: if _iscommand(cmd.lower()): with if _iscommand(cmd.lower().split(" ")[0]): There remain some things that are dubious about the handling of the values in the BROWSER environment variable. In particular, the lower() in that line, the assumption that the executables specified in BROWSER are in the user's PATH, and the lack of handling of %% and %s in those values. Still, it may be reasonable to ignore those issues until they pose a problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-24 00:53 Message: Logged In: YES user_id=6380 Please ask around on c.l.py if the macintosh problem actually exists; if it doesn't, stopping at the first space sounds like the right idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=687747&group_id=5470 From noreply at sourceforge.net Tue Aug 19 13:12:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 12:02:07 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 14:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-19 15:12 Message: Logged In: YES user_id=33168 Your fix is the same as what I checked in, except that I used Py_XDECREF instead of Py_DECREF, since PyObject_CallFunction could fail and return NULL. This still needs a test and backport to 2.3.1. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-19 09:52 Message: Logged In: YES user_id=845425 Over the weekend and through Monday I ran my system 24/7 with the previously attached code. There do not seem to be any problems, but I am waiting for your "blessing" before considering it a fix. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-16 19:09 Message: Logged In: YES user_id=845425 I think I may have a fix. Check out the attached file. It seems to work for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 16:07 Message: Logged In: YES user_id=33168 Wow, it sure does leak! Checked in as: Objects/fileobject.c 2.180 Still needs a test. Leaving open until I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Tue Aug 19 14:17:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 12:07:40 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 13:23 Message generated for change (Comment added) made by jdalambert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- >Comment By: David Lambert (jdalambert) Date: 2003-08-19 15:17 Message: Logged In: YES user_id=845425 Good point, but if PyObject_CallFunction fails, is PyErr_SetObject safe with a NULL second parameter? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-19 14:12 Message: Logged In: YES user_id=33168 Your fix is the same as what I checked in, except that I used Py_XDECREF instead of Py_DECREF, since PyObject_CallFunction could fail and return NULL. This still needs a test and backport to 2.3.1. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-19 08:52 Message: Logged In: YES user_id=845425 Over the weekend and through Monday I ran my system 24/7 with the previously attached code. There do not seem to be any problems, but I am waiting for your "blessing" before considering it a fix. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-16 18:09 Message: Logged In: YES user_id=845425 I think I may have a fix. Check out the attached file. It seems to work for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 15:07 Message: Logged In: YES user_id=33168 Wow, it sure does leak! Checked in as: Objects/fileobject.c 2.180 Still needs a test. Leaving open until I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Wed Aug 20 02:31:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 12:09:16 2003 Subject: [Python-bugs-list] [ python-Bugs-747320 ] rfc2822 formatdate functionality duplication Message-ID: Bugs item #747320, was opened at 2003-06-01 21:18 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747320&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: rfc2822 formatdate functionality duplication Initial Comment: There are at least 4 places in the standard Python 2.3 library which build an RFC 2822 formatted string: rfc822.formatstring email.Utils.formatdate logging.handlers.SMTPHandler.date_time BaseHTTPServer.HTTPServer.date_time_string Looking at them, it makes sense to me to - replace rfc822's implementation with email's (that's the most flexible of the bunch) - start a migration so that email uses the one from rfc822, if available, else it's own implementation (since email is distributed to older Pythons) - have logging use the one in rfc822. - have BaseHTTPServer use the one in rfc822 If this is deemed an appropriate change, I can send in a patch. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-20 00:31 Message: Logged In: YES user_id=139865 Careful, date/time formats differ between RFCs. RFC 850 = Wdy, DD-Mon-YYYY HH:MM:SS (UT/GMT/(+/-)DDDD/...) RFC 2616 = Wdy, DD Mon YYYY HH:MM:SS GMT RFC 2822 = Wdy, DD Mon YYYY HH:MM:SS (+/-)DDDD rfc822.formatstring deprecated; let it rot email.Utils.formatdate uses RFC 2822, the One True Date Format logging.handlers.SMTPHandler.date_time uses RFC 2616, should be using RFC 2822 BaseHTTPServer.HTTPServer.date_time_string uses RFC 2616 Cookie._getdate uses RFC 850 Patch 791776 changes SMTPHandler to use rfc2822.formatdate. grepping for day names, month names, year, gmtime, and localtime does not reveal further duplication. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-02 04:37 Message: Logged In: YES user_id=12800 Personally, I'd like to see the email package's date formatting (and other email related tasks) be the canonical standard, and for other modules to use its rules when appropriate. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-06-01 22:13 Message: Logged In: YES user_id=29957 It's not just formatdate - various email formatting tasks are probably the single largest source of duplication in the std library... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=747320&group_id=5470 From noreply at sourceforge.net Fri Aug 22 04:20:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:29:30 2003 Subject: [Python-bugs-list] [ python-Bugs-793078 ] Easier-to-create alternative Python installer for Windows Message-ID: Bugs item #793078, was opened at 2003-08-22 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=793078&group_id=5470 Category: Installation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Easier-to-create alternative Python installer for Windows Initial Comment: It is unfortunate that the standard Python installer requires proprietrary products (Wise) to build on Windows. It makes it difficult to recreate a Python installer for those who want a custom installer. While I appreciate the nice installer donated by Wise (http://starship.python.net/crew/mhammond/wise/wise.html) it would be great if there was a simpler solution. The ultimate solution would be to use the distutils setup to create an installer. It doesn't have to look as nice as the Wise one, as long as it can be created using all Open-source tools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793078&group_id=5470 From noreply at sourceforge.net Fri Aug 22 02:39:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:30:30 2003 Subject: [Python-bugs-list] [ python-Bugs-792558 ] csv.DictReader parms inconsistent with docs Message-ID: Bugs item #792558, was opened at 2003-08-21 15:22 Message generated for change (Settings changed) made by potten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792558&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Otten (potten) Assigned to: Nobody/Anonymous (nobody) >Summary: csv.DictReader parms inconsistent with docs Initial Comment: To conform with the documentation, csv.DictReader (and possibly DictWriter) should accept keyword arguments to specify a dialect on the fly and forward them to its reader instance: class DictReader: def __init__(self, f, fieldnames, restkey=None, restval=None, dialect="excel", *args, **kwd): self.fieldnames = fieldnames # list of keys for the dict self.restkey = restkey # key to catch long rows self.restval = restval # default value for short rows self.reader = reader(f, dialect, *args, **kwd) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792558&group_id=5470 From noreply at sourceforge.net Fri Aug 22 02:44:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:30:49 2003 Subject: [Python-bugs-list] [ python-Bugs-711632 ] htmllib.HTMLParser.anchorlist problem Message-ID: Bugs item #711632, was opened at 2003-03-28 15:26 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711632&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Gray (cpgray) Assigned to: Nobody/Anonymous (nobody) Summary: htmllib.HTMLParser.anchorlist problem Initial Comment: htmllib.HTMLParser.anchorlist is cleared when __init__() is called but not when reset() is called. Processing more than one document with the same instance accumulates anchors from all documents processed in the list. Arguably a feature not a bug, but it makes sense for reset to clear whatever is initialized by __init__. Here is an illustrative IDLE session: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import htmllib >>> import formatter >>> p = htmllib.HTMLParser(formatter.NullFormatter()) >>> p.feed('Python') >>> p.anchorlist ['http://www.python.org'] >>> p.reset() >>> p.feed('Sourceforge') >>> p.anchorlist ['http://www.python.org', 'http://sourceforge.net/'] ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-22 00:44 Message: Logged In: YES user_id=139865 See patch 793021 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=711632&group_id=5470 From noreply at sourceforge.net Fri Aug 22 02:48:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:31:31 2003 Subject: [Python-bugs-list] [ python-Bugs-603724 ] setting file buffer size is unreliable Message-ID: Bugs item #603724, was opened at 2002-09-02 14:37 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: setting file buffer size is unreliable Initial Comment: The description of open() (ie file()) says: "If the buffering argument is given, 0 means unbuffered, 1 means line buffered, and larger numbers specify the buffer size." PyFile_SetBufSize() passes the requested buffer size on to setvbuf(), with NULL as setvbuf()'s second parameter. The C89 standard doesn't guarantee any change to the buffer size when the second parameter is NULL, and some stdio implementations (legitimately) ignore the size parmater in such circumstances. C99's gives more guidelines, but nothing that can be relied upon: "If buf is not a null pointer, the array it points to may be used instead of a buffer allocated by the setvbuf function and the argument size specifies the size of the array; otherwise, size may determine the size of buffer allocated by the setvbuf function." (7.19.5.6) (What good is "may" to anyone?) The result of all this is that fd = open('file', 'w', 8) will not have the desired (and documented) effect (flushing the output buffer every 8 characters) on some platforms, so either the documentation of open() or the code (PyFile_SetBufSize()) should be fixed. The same problems exist with setbuf() as well. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-22 00:48 Message: Logged In: YES user_id=139865 See patch 788249 for a fix. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-12 00:12 Message: Logged In: YES user_id=21627 I see, it appears indeed that the size argument is unused on Linux. Any volunteers to come up with a patch? ---------------------------------------------------------------------- Comment By: Jeremy Yallop (yallop) Date: 2002-09-11 12:49 Message: Logged In: YES user_id=479330 Debian on x86 with glibc-2.2.5 (which I believe uses Per Bothner's libio) ignores the size parameter when the buffer parameter is NULL. I've attached a demonstration program which calls setvbuf with a size of 2 and with either NULL or a static buffer (depending on argc). Run it and kill (with Ctrl-C or whatever) before it's finished. Alternatively, the effect can be observed in python by something like >>> fd = open('file', 'write', 2) >>> fd.write('Hello, world.\n') >>> Ctrl-Z [1]+ Stopped python $ killall -9 python $ cat file $ PS I'm not sure declaring Debian as unsupported would be very popular :-). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-09-11 08:56 Message: Logged In: YES user_id=21627 Can you please report which systems ignore the setvbuf call? Python makes loads of assumptions about systems which are not backed by any standard. On systems which meet Python's expectation, Python behaves as documented. On systems which don't meet the expectations, we have two options a) declare the system as unsupported, or b) fix the implementation for the specific system to meet the documentation. So in the abstract, I don't see a bug here - setting the buffer size *is* reliable on Linux and Windows and many other supported systems. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 14:35 Message: Logged In: YES user_id=31392 The C99 rationale has a helpful comment on the subject of setvbuf(): C90 was not clear about what, if anything, the size argument means when buf is a null pointer. Existing practice is mixed: some implementations ignore it completely, other implementations use it as guidance for determining the size of the buffer allocated by setvbuf. C9X gives warning that size might be ignored in this case, so portable programs must be sure to supply a reasonable value. I'd be mostly inclined to change the documentation to say that the buffer is under control of the C library and that Python does whatever setvbuf() does. Or however we write the C99 weasel words in Python docstring-ease. Thankfully, Linux and Windows both have sane setvbuf() implementations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=603724&group_id=5470 From noreply at sourceforge.net Fri Aug 22 02:47:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:31:55 2003 Subject: [Python-bugs-list] [ python-Bugs-703198 ] os.popen with mode "rb" fails on Unix Message-ID: Bugs item #703198, was opened at 2003-03-13 11:35 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703198&group_id=5470 Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: J. Peterson (isonno) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen with mode "rb" fails on Unix Initial Comment: On Windows, it's necessary to use the mode "rb" to open a binary stream to a process. On Unix the "b" modifier isn't necessary, but supplying it causes the popen call to fail with OSError: [Errno 22] Invalid argument The Unix version of popen should accept and simply ignore the "b" modifier to the mode, rather than fail. That way the same code can run on both platforms without modification or extra code to special case an OS that may need the "b" modifier. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-22 00:47 Message: Logged In: YES user_id=139865 See patch 788404 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703198&group_id=5470 From noreply at sourceforge.net Fri Aug 22 04:08:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:32:27 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793069 ] Add --remove-source option Message-ID: Feature Requests item #793069, was opened at 2003-08-22 12:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Add --remove-source option Initial Comment: For distributing non-opensource software, it is helpful to just distribute the .pyc/.pyo files and not the original .py files. The reverse (just distributing .py files) is possible through the --no-target-compile and --no-target-optimize switches to the distutils bdist command. We have added a --remove-source option which goes through and deletes all the source files from the build directory. This has been tested and works smoothly with Python 2.2.3 and seems to apply cleanly to Python 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470 From noreply at sourceforge.net Fri Aug 22 04:34:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 17:32:59 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793069 ] Add --remove-source option Message-ID: Feature Requests item #793069, was opened at 2003-08-22 12:08 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Add --remove-source option Initial Comment: For distributing non-opensource software, it is helpful to just distribute the .pyc/.pyo files and not the original .py files. The reverse (just distributing .py files) is possible through the --no-target-compile and --no-target-optimize switches to the distutils bdist command. We have added a --remove-source option which goes through and deletes all the source files from the build directory. This has been tested and works smoothly with Python 2.2.3 and seems to apply cleanly to Python 2.3 ---------------------------------------------------------------------- >Comment By: David Fraser (davidfraser) Date: 2003-08-22 12:34 Message: Logged In: YES user_id=221678 Added a patch for this (sorry, probably should have just done that) as 793070: https://sourceforge.net/tracker/?func=detail&aid=793070&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793069&group_id=5470 From noreply at sourceforge.net Fri Aug 22 18:35:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Aug 22 21:36:51 2003 Subject: [Python-bugs-list] [ python-Bugs-709491 ] sgmllib.SGMLParser.reset() problem Message-ID: Bugs item #709491, was opened at 2003-03-25 06:55 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709491&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Chris Gray (cpgray) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLParser.reset() problem Initial Comment: sgmllib.SGMLParser.reset() doesn't reset __starttag_text to None Here's an IDLE session illustrating the problem using the subclass htmllib.HTMLParser: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import formatter >>> import htmllib >>> class HTMLP(htmllib.HTMLParser): def __init__(self): htmllib.HTMLParser.__init__(self, formatter.NullFormatter()) >>> p = HTMLP() >>> print p.get_starttag_text() None >>> p.feed('') >>> print p.get_starttag_text() >>> p.reset() >>> print p.get_starttag_text() The value for this last call to get_starttag_text() should be None. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-22 16:35 Message: Logged In: YES user_id=139865 See patch 793559 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=709491&group_id=5470 From noreply at sourceforge.net Fri Aug 22 06:52:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 07:45:46 2003 Subject: [Python-bugs-list] [ python-Bugs-792656 ] Misleading [i:j:k] slicing description Message-ID: Bugs item #792656, was opened at 2003-08-21 19:02 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792656&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Raoul Gough (raoulgough) >Assigned to: Michael Hudson (mwh) Summary: Misleading [i:j:k] slicing description Initial Comment: Section 2.2.6 (Sequence types), note 5 from the table says: "The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that 0 <= n < abs(i-j). [...]" However, n should only range up to (j-i)//k Note also that (j-i)//k correctly specifies the results for negative values of k, and empty sequence returns where signof(j-i) != signof (k). Maybe worth mentioning that k != 0 (!! :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792656&group_id=5470 From noreply at sourceforge.net Fri Aug 22 07:07:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Aug 23 07:46:00 2003 Subject: [Python-bugs-list] [ python-Bugs-793200 ] Typo in documentation for Cell Objects Message-ID: Bugs item #793200, was opened at 2003-08-22 15: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=793200&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in documentation for Cell Objects Initial Comment: The current online documenation says: ---- PyObject*?PyCell_GET(PyObject *cell) Return value: Borrowed reference. Return the contents of the cell cell, but without checking that cell is non-NULL and a call object. ---- The last three words should be 'a cell object'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793200&group_id=5470 From noreply at sourceforge.net Sun Aug 24 09:18:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:11:36 2003 Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed Message-ID: Bugs item #794140, was opened at 2003-08-24 10:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alejandro Lopez-Valencia (dradul) Assigned to: Nobody/Anonymous (nobody) Summary: cygwin builds do not embed Initial Comment: As an example case, try to build a copy of vim with an embeded python interpreter: """ indow.o objects/if_python.o objects/py_config.o objects/netbeans.o object s/version.o -lncurses -liconv -lintl - L/usr/lib/python2.3/config -lpyt hon2.3 -lutil -lm objects/py_config.o(.data+0x4):config.c: referencia a `_initthread' sin definir objects/py_config.o(.data+0xc):config.c: referencia a `_initsignal' sin definir objects/py_config.o(.data+0x14):config.c: referencia a `_initposix' sin definir objects/py_config.o(.data+0x1c):config.c: referencia a `_initerrno' sin definir objects/py_config.o(.data+0x24):config.c: referencia a `_init_sre' sin definir objects/py_config.o(.data+0x2c):config.c: referencia a `_init_codecs' sin defini r """ As you can see, it doesn't embed. I have tracked down the failure to a problem in the LDSHARED defaults provided by configure.in. The default supplied is: LDSHARED="gcc -shared -Wl,--enable-auto-image- base";; but this *does not* work. As per Cygwin documentation on the creation of DLLs, this works (already tested compiling vim under the same conditions): LDSHARED="gcc -shared -Wl,--enable-auto-image-base - Wl,--export-all-symbols -Wl,--enable-auto-import";; As a side note, please notice that this problem, proper user of GNU ld flags under win32, has a direct impact on the possible success of a true Mingw32 port (which I expect eagerly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470 From noreply at sourceforge.net Sat Aug 23 04:01:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:12:47 2003 Subject: [Python-bugs-list] [ python-Bugs-793702 ] Section 13.1 HTMLParser documentation error Message-ID: Bugs item #793702, was opened at 2003-08-23 03:01 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=793702&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Baker (kemokid) Assigned to: Nobody/Anonymous (nobody) Summary: Section 13.1 HTMLParser documentation error Initial Comment: The description for handle_comment() says: The comment argument is a string containing the text between the "" delimiters, but not the delimiters themselves. For example, the comment "" will cause this method to be called with the argument 'text'. This is incorrect - the comment delimiters are "" (two hyphens, not just one). Purusing the code, it appears that the module itself behaves correctly, so this is only a very minor documentation bug, but to a HTML newbie, it could be an incredibly frustrating one. This was seen on 2003/8/23 at http://www.python.org/doc/current/lib/module-HTMLParser.html And a big thank you to all Pythonic volunteers! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470 From noreply at sourceforge.net Sat Aug 23 04:03:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:13:04 2003 Subject: [Python-bugs-list] [ python-Bugs-793702 ] Section 13.1 HTMLParser documentation error Message-ID: Bugs item #793702, was opened at 2003-08-23 03:01 Message generated for change (Settings changed) made by kemokid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Martin Baker (kemokid) Assigned to: Nobody/Anonymous (nobody) Summary: Section 13.1 HTMLParser documentation error Initial Comment: The description for handle_comment() says: The comment argument is a string containing the text between the "" delimiters, but not the delimiters themselves. For example, the comment "" will cause this method to be called with the argument 'text'. This is incorrect - the comment delimiters are "" (two hyphens, not just one). Purusing the code, it appears that the module itself behaves correctly, so this is only a very minor documentation bug, but to a HTML newbie, it could be an incredibly frustrating one. This was seen on 2003/8/23 at http://www.python.org/doc/current/lib/module-HTMLParser.html And a big thank you to all Pythonic volunteers! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470 From noreply at sourceforge.net Fri Aug 22 21:40:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:13:29 2003 Subject: [Python-bugs-list] [ python-Bugs-793200 ] Typo in documentation for Cell Objects Message-ID: Bugs item #793200, was opened at 2003-08-22 08:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793200&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in documentation for Cell Objects Initial Comment: The current online documenation says: ---- PyObject*?PyCell_GET(PyObject *cell) Return value: Borrowed reference. Return the contents of the cell cell, but without checking that cell is non-NULL and a call object. ---- The last three words should be 'a cell object'. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-22 22:40 Message: Logged In: YES user_id=80475 Okay, I fixed it. Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793200&group_id=5470 From noreply at sourceforge.net Sun Aug 24 13:52:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:13:49 2003 Subject: [Python-bugs-list] [ python-Bugs-794291 ] double symlinking corrupts sys.path[0] Message-ID: Bugs item #794291, was opened at 2003-08-24 21: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=794291&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Csaba Henk (dzsekijo) Assigned to: Nobody/Anonymous (nobody) Summary: double symlinking corrupts sys.path[0] Initial Comment: The bug can be demonstrated as follows (In some Bourne-tpye Unix shell) type $ mkdir d1 d2 && echo 'import sys print sys.path[0]' > d1/script.py && ln -s ../d1/script.py d2 && ln -s d2/script.py . Now see what the three invocations of script.py give us: $ python d1/script.py d1 $ python d2/script.py d2/../d1 $ python script.py d2 -- if script.py imported modules residing in d1, at the third invocation the modules would not be found. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794291&group_id=5470 From noreply at sourceforge.net Sat Aug 23 03:09:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:14:27 2003 Subject: [Python-bugs-list] [ python-Bugs-793687 ] runnig thread multiple times Message-ID: Bugs item #793687, was opened at 2003-08-23 11:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793687&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Nobody/Anonymous (nobody) Summary: runnig thread multiple times Initial Comment: Internal variable __started remains set to True/1 even if thread is already terminated, this situation will generate assertion error when .start is invoked second time. demo.py import time import threading done = threading.Event() def demo(): print 'bip' done.set() t=threading.Thread(target=demo) t.start() while not done.isSet(): time.sleep(0.1) done.clear() print 'returned' t.start() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793687&group_id=5470 From noreply at sourceforge.net Sat Aug 23 17:30:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:15:47 2003 Subject: [Python-bugs-list] [ python-Bugs-793826 ] using itertools.izip to mutate tuples Message-ID: Bugs item #793826, was opened at 2003-08-23 12:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793826&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Raymond Hettinger (rhettinger) Summary: using itertools.izip to mutate tuples Initial Comment: Not sure how crucial this exactly is, but the itertools.izip() can be abused to create a tuple that can be mutated once. I couldn't find a way to crash anything, however, but I wouldn't leave such a possibility open in the Python interpreter nevertheless. . from itertools import imap, izip . . def mutatingtuple(tuple1, f, tuple2): . # this builds a tuple t which is a copy of tuple1, . # then calls f(t), then mutates t to be equal to tuple2 . # (needs len(tuple1) == len(tuple2)). . def g(value, first=[1]): . if first: . del first[:] . f(z.next()) . return value . items = list(tuple2) . items[1:1] = list(tuple1) . gen = imap(g, items) . z = izip(*[gen]*len(tuple1)) . z.next() . . def f(t): . global T . T = t . print T . . mutatingtuple((1,2,3), f, (4,5,6)) # print T -> (1, 2, 3) . print T # print T -> (4, 5, 6) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-23 18:30 Message: Logged In: YES user_id=80475 I'm inclined to not worry about this one. The tuple re-use technique appears elsewhere in the code base and has not had any problems in practice. The exploitation script is impressive and it makes clear that mutation requires combining a number of rare, deliberate steps that don't occur in practice, i.e. the intensional assignment to a tuple inside a self-referential iterator that refers to itself by the name in an enclosing scope. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-08-23 12:28 Message: Logged In: YES user_id=4771 Assigned to Raymond on the rationale that he's the author of itertoolsmodule.c. I can propose a patch to itertoolsmodule.c if you wish. Also attached above example in a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793826&group_id=5470 From noreply at sourceforge.net Sat Aug 23 10:02:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:17:45 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793802 ] class for function calls that are not thread safe Message-ID: Feature Requests item #793802, was opened at 2003-08-23 18:02 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=793802&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: class for function calls that are not thread safe Initial Comment: I would like that a class will be added to perform thread unsafe function or method calls in an easy way like I describe it in the request "https://sourceforge.net/mailarchive/forum.php?thread_id=1585197&forum_id=24972" for the TCL thread package. The description "http://zthread.sourceforge.net/html/classZThread_1_1SynchronousExecutor.html" seems to come near what I want. But I think that there is a little bit missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470 From noreply at sourceforge.net Sat Aug 23 11:17:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:18:26 2003 Subject: [Python-bugs-list] [ python-Bugs-793822 ] gc.get_referrers() is inherently dangerous Message-ID: Bugs item #793822, was opened at 2003-08-23 17:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793822&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: gc.get_referrers() is inherently dangerous Initial Comment: gc.get_referrers() can be used to crash any Python interpreter because it allows the user to obtain objects which are still under construction. Here is an example where an iterator can use it to obtain a tuple while it is still being populated by the 'tuple' built-in function. The following example triggers a SystemError, but as the tuple 't' is at the moment still full of null values it can easily generate segfaults instead. from gc import get_referrers def iter(): tag = object() yield tag # 'tag' gets stored in the result tuple lst = [x for x in get_referrers(tag) if isinstance(x, tuple)] t = lst[0] # this *is* the result tuple print t # full of nulls ! tuple(iter()) Unless someone has more ideas than me as to how to prevent this problem, I'd suggest that gc.get_referrers() should be deemed 'officially dangerous' in the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793822&group_id=5470 From noreply at sourceforge.net Sat Aug 23 07:37:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Aug 24 21:18:56 2003 Subject: [Python-bugs-list] [ python-Bugs-793753 ] sgmllib parser problem Message-ID: Bugs item #793753, was opened at 2003-08-23 15: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=793753&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Hofmann (walterh) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib parser problem Initial Comment: Hi, I notices that the parser htmllib.HTMLParser has a problem with parsing the following code: