From noreply at sourceforge.net Sat Nov 1 11:29:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 11:29:08 2003 Subject: [Python-bugs-list] [ python-Bugs-548661 ] os.popen w/o using the shell Message-ID: Bugs item #548661, was opened at 2002-04-25 17:30 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen w/o using the shell Initial Comment: I heard that there was an undocumented feature to the os.popen family, where instead of passing a command string as the first argument you could pass a list, as [path, arg1, arg2, ...], and circumvent any shell interpretation. I was disapointed to see that this was not so ("popen() argument 1 must be string, not list" ditto tuple) I believe this would be an excellent feature -- using the shell is a significant source of errors due to quoting, as well as a serious security concern. 95% of the time the shell is not required. The shell also introduces portability concerns (e.g., bug #512433) -- creating a Python shell is not necessary when the shell is usually superfluous anyway. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-01 17:29 Message: Logged In: YES user_id=344921 popen5 never uses the shell (http://www.lysator.liu.se/~astrand/popen5/) ---------------------------------------------------------------------- Comment By: Juli?n Mu?oz (julian69) Date: 2003-01-08 17:15 Message: Logged In: YES user_id=77756 Does this mean that giving a list to popen2 free us from taking care of the dangerous characters that could be interprated/escaped by the shell ??? I don't find any documentation about this feature !!! ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2002-04-25 20:18 Message: Logged In: YES user_id=210337 I see you are correct. It would be nice if this feature was consistent across all popen*, and was also documented (and so also committed to with clear semantics) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-04-25 20:13 Message: Logged In: YES user_id=21627 This feature is indeed available in popen2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470 From noreply at sourceforge.net Sat Nov 1 11:44:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 11:44:17 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 14:29 Message generated for change (Comment added) made by astrand 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: Peter ?strand (astrand) Date: 2003-11-01 17:44 Message: Logged In: YES user_id=344921 popen5 (http://www.lysator.liu.se/~astrand/popen5/) uses a sequence argument instead of a string, and has no problems with whitespace. Also, it supports connecting several subprocesses together (feeding the output from one command into another). ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-09-01 12:41 Message: Logged In: YES user_id=233844 I was trying to use python as a shell replacement for simple scripts, but I was disapppointed by the poor level of support of python for those things. In my case, the list of files was pulled from a command and passed to another one. I have some suggestions on how to improve python shell scripting capability. Right now, as soon as you want to do something a little bit complicated, like feeding a program (let's say grep) from the output of another program and checking the output and the exit status is quite complicated. For such an interface to be good, it has to provide _very_ easy way to: - read stdout from a command - provide stdin to a command - read exit status of a command. - pipe a command into another one Let's say I want to run the equivalent of find . -name '*.cpp' | grep -i toto My suggested interface to run a simple command would be as following: cmd( "find", ".", "-name", "*.cpp") This defines a command to be run. To be versatile, this would have to accept although the following format: cmd( [ "find", ".", "-name", "*.cpp" ] ) cmd( "find", [ ".", "-name", "*.cpp" ] ) which are slightly different ways of spawning a command. I think all these three ways have a usage pattern. To actually execute the command, you woud do: cmd( "find", ".", "-name", "*.cpp" ).go() This create an object which has To run it, you just apply the go() method: cmd( "find", ".", "*.cpp" ).go() This could return a tuple (stdout, stderr, return_code) Now, if you want to pipe a command into another one, we can either override the operator | or write it manually. My initial command would become: cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ) I dislike using a syntax like cmd().pipe( cmd ) because piping multiple commands would required parenthesis nesting which does not look nice. The goal is to reach the simplicity of shell scripting. To execute the previous command, one would simple again use the go() method: (stdout, stderr, ret_status) = cmd( "find", ".", "-name", "*.cpp" ).pipe().cmd( "grep", "-i", "toto" ).go() Here for my suggestion. It might be more appropriate to post it to a mailing list, to get more feedback ? I am sorry, I am very busy now and won't have time to implement this myself. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-19 14: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-21 01: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 Sat Nov 1 15:41:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 15:41:04 2003 Subject: [Python-bugs-list] [ python-Bugs-830347 ] python-mode.el: py-b-of-def-or-class looks inside strings Message-ID: Bugs item #830347, was opened at 2003-10-26 03:57 Message generated for change (Comment added) made by dhagglund You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 Category: Demos and Tools Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Dale Hagglund (dhagglund) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el: py-b-of-def-or-class looks inside strings Initial Comment: Using python-mode.el 4.6 and gnu emacs 21.1. To demonstrate this problem: 1. Open the attached file with emacs. 2. Position point at the "#" on the last line. 3. Type `M-C-a', py-beginning-of-def-or-class. Point will now be inside the docstring for class x. py-b-o-d-o-c uses regexps to look backwards for def or class lines. When it finds a candidate line, should it maybe use partial-parse-sexp to decide if it's in a string or not? I apologize if this issue has been raised before, but I wasn't able to figure out how to do keyword searches with sourceforge. ---------------------------------------------------------------------- >Comment By: Dale Hagglund (dhagglund) Date: 2003-11-01 20:41 Message: Logged In: YES user_id=895011 Resubmitted to the python-mode project, and closed this one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-27 14:08 Message: Logged In: YES user_id=33168 This bug/patch should be submitted to the python-mode project. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Dale Hagglund (dhagglund) Date: 2003-10-26 05:32 Message: Logged In: YES user_id=895011 I guess I should have waited a bit longer before filing this as a bug. The attached patch resolves this bug for me. This patch also fixes a minor related bug in py-end-of-def-or-class. If COUNT was greater than zero, the call to py-beginning-of-def-or-class was incorrect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 From noreply at sourceforge.net Sat Nov 1 19:37:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 19:37:23 2003 Subject: [Python-bugs-list] [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-01 16: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=834351&group_id=5470 Category: Tkinter Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Richardson (garyrxx) Assigned to: Martin v. L?wis (loewis) Summary: Mouse wheel crashes program Initial Comment: The following program (by Michael Peuser) crashes as soon as the mouse wheel is moved. See my post to c.l.p. on Oct 29. Gary Richardson #------------------------- from Tkinter import * def _onMouseWheel(event): print event root = Tk() root.bind('',_onMouseWheel) root.mainloop() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 From noreply at sourceforge.net Sat Nov 1 20:12:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 1 20:12:09 2003 Subject: [Python-bugs-list] [ python-Bugs-824430 ] Package Manager Scrolling Behavior Message-ID: Bugs item #824430, was opened at 2003-10-16 00:00 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824430&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Larry Meyn (lmeyn) Assigned to: Jack Jansen (jackjansen) Summary: Package Manager Scrolling Behavior Initial Comment: The Package Manager scroll bar always jumps to the top of the list after being moved. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-02 02:12 Message: Logged In: YES user_id=45365 Fixed in PackageManager.py rev. 1.14.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824430&group_id=5470 From noreply at sourceforge.net Sun Nov 2 03:41:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 03:41:17 2003 Subject: [Python-bugs-list] [ python-Bugs-834452 ] python and lithuanian locales Message-ID: Bugs item #834452, was opened at 2003-11-02 10:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mantas (mantaz) Assigned to: Nobody/Anonymous (nobody) Summary: python and lithuanian locales Initial Comment: python's locale.py file contains only one lithuanian locale Iso 8859-4 which is obsolete. Now almost all uses iso 8859-13. Lithuanian locale is called lt, and i think it must be named lt_lt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470 From noreply at sourceforge.net Sun Nov 2 04:30:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 04:30:20 2003 Subject: [Python-bugs-list] [ python-Bugs-834461 ] simple bsddb interface potential for deadlock with threads Message-ID: Bugs item #834461, was opened at 2003-11-02 01: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=834461&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: simple bsddb interface potential for deadlock with threads Initial Comment: >From Lib/bsddb/__init__.py # FIXME-20031101-greg: I believe there is still the potential # for deadlocks in a multithreaded environment if someone # attempts to use the any of the cursor interfaces in one # thread while doing a put or delete in another thread. The # reason is that _checkCursor and _closeCursors are not atomic # operations. Doing our own locking around self.dbc, # self.saved_dbc_key and self._iter_cursors could prevent this. # TODO: A test case demonstrating the problem needs to be written. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&group_id=5470 From noreply at sourceforge.net Sun Nov 2 04:47:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 04:47:24 2003 Subject: [Python-bugs-list] [ python-Bugs-834461 ] simple bsddb interface potential for deadlock with threads Message-ID: Bugs item #834461, was opened at 2003-11-02 01:30 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: simple bsddb interface potential for deadlock with threads Initial Comment: >From Lib/bsddb/__init__.py # FIXME-20031101-greg: I believe there is still the potential # for deadlocks in a multithreaded environment if someone # attempts to use the any of the cursor interfaces in one # thread while doing a put or delete in another thread. The # reason is that _checkCursor and _closeCursors are not atomic # operations. Doing our own locking around self.dbc, # self.saved_dbc_key and self._iter_cursors could prevent this. # TODO: A test case demonstrating the problem needs to be written. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-11-02 01:47 Message: Logged In: YES user_id=413 While I'm at it, I think there might be a memory leak in my __iter__ and iteritems() implementation when the resulting generator objects are destroyed without completing their iteration (as will happen in UserDict.DictMixIn.popitem among other things). They add their DBCursor to _DBWithCursor._iter_cursors but only ever delete it from that hash before a return rather than a yield. The solution to this should be simple: have _closeCursors() empty the _iter_cursors hash after calling close() on all of the cursors. __iter__ and iteritems() already ignore a KeyError when trying to remove their cursor from the map when returning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&group_id=5470 From noreply at sourceforge.net Sun Nov 2 04:55:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 04:55:57 2003 Subject: [Python-bugs-list] [ python-Bugs-819178 ] optparse "append" action should always make the empty list. Message-ID: Bugs item #819178, was opened at 2003-10-07 05:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Greg Ward (gward) Summary: optparse "append" action should always make the empty list. Initial Comment: I was torn between "Bug" and "RFE" on this one. Anyway, with options whose action is "append", optparse.OptionParser will set the option to None if it's never called. Instead, I think it should set the option to the empty list, so code can iterate over the list regardless of whether the option was ever given. It keeps users from having to guard their iteration with "if options.foo:" Such a change would be slightly backwards-incompatible; users who use "if option.foo is None:" form instead of just "if not options.foo:" would run into trouble, as well as those users who used an "else" statement in their loops. The latter seemed like a big problem, until I realized that those users' code *already* guards against the empty case, and thus shouldn't run into difficulties. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-07 05:48 Message: Logged In: YES user_id=99508 So, I *thought* I could change this to an RFE after submitting it, but apparently not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 From noreply at sourceforge.net Sun Nov 2 05:00:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 05:01:09 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 02:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-02 05:00 Message: Logged In: YES user_id=80475 I think it's fine as is. Also, it is certain that some existing code relies on it. Other that bugging the OP, I see no harm from it. Recommend closing this as "not a bug". ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-28 09:22 Message: Logged In: YES user_id=388573 I don't know why setattr() should allows *any* attribute name, but if so shouldn't this ability will be documented at least? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-10-27 21:29 Message: Logged In: YES user_id=357491 I am going to argue for "no" on this one. The major point of setattr is that it allows you to set an attribute for *any* name after compile time. This should go for even attribute names that would not normally work. It is a rather powerful ability that I think should stay. Anyone else care to weigh in on this? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-27 20:00 Message: Logged In: YES user_id=539787 Note: there is a valid_identifier function in Objects/typeobject.c which is being used by the __slots__ mechanism and I believe is quite handy; however, it is declared as static. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-26 04:09 Message: Logged In: YES user_id=388573 Give me some use case examples. Maybe you use object's __dict__ like general purpose dictionary? If so, it seems ugly for me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-25 08:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 06:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 15:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Sun Nov 2 05:04:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 05:04:40 2003 Subject: [Python-bugs-list] [ python-Bugs-827856 ] object.h misdocuments PyDict_SetItemString Message-ID: Bugs item #827856, was opened at 2003-10-21 17:47 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Raymond Hettinger (rhettinger) Summary: object.h misdocuments PyDict_SetItemString Initial Comment: I just happened to notice the following in the comment titled "Reference Counts" toward the end of object.h (2.3.2): Functions that 'store' objects such as PyTuple_SetItem () and PyDict_SetItemString() don't increment the reference count of the object I believe PyDict_SetItemString does increment the refcount. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 04:29 Message: Logged In: YES user_id=887415 Hi Greg, you are right, whoever wrote it probably meant PyList_SetItem (according to Ref.Manual 1.2.1.1 and source). Will you submit a patch? ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 From noreply at sourceforge.net Sun Nov 2 05:30:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 05:31:36 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 02:53 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-02 05:00 Message: Logged In: YES user_id=80475 I think it's fine as is. Also, it is certain that some existing code relies on it. Other that bugging the OP, I see no harm from it. Recommend closing this as "not a bug". ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-28 09:22 Message: Logged In: YES user_id=388573 I don't know why setattr() should allows *any* attribute name, but if so shouldn't this ability will be documented at least? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-10-27 21:29 Message: Logged In: YES user_id=357491 I am going to argue for "no" on this one. The major point of setattr is that it allows you to set an attribute for *any* name after compile time. This should go for even attribute names that would not normally work. It is a rather powerful ability that I think should stay. Anyone else care to weigh in on this? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-27 20:00 Message: Logged In: YES user_id=539787 Note: there is a valid_identifier function in Objects/typeobject.c which is being used by the __slots__ mechanism and I believe is quite handy; however, it is declared as static. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-26 04:09 Message: Logged In: YES user_id=388573 Give me some use case examples. Maybe you use object's __dict__ like general purpose dictionary? If so, it seems ugly for me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-25 08:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 06:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 15:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Sun Nov 2 09:42:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 09:42:05 2003 Subject: [Python-bugs-list] [ python-Bugs-827856 ] object.h misdocuments PyDict_SetItemString Message-ID: Bugs item #827856, was opened at 2003-10-21 14:47 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Raymond Hettinger (rhettinger) Summary: object.h misdocuments PyDict_SetItemString Initial Comment: I just happened to notice the following in the comment titled "Reference Counts" toward the end of object.h (2.3.2): Functions that 'store' objects such as PyTuple_SetItem () and PyDict_SetItemString() don't increment the reference count of the object I believe PyDict_SetItemString does increment the refcount. ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-11-02 05:42 Message: Logged In: YES user_id=86307 Attached is a patch (against 2.3.2 object.h) which changes the reference to PyDict_SetItemString to PyList_SetItem. It also corrects another typo I noticed this morning. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 01:29 Message: Logged In: YES user_id=887415 Hi Greg, you are right, whoever wrote it probably meant PyList_SetItem (according to Ref.Manual 1.2.1.1 and source). Will you submit a patch? ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 From noreply at sourceforge.net Sun Nov 2 10:31:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 10:31:18 2003 Subject: [Python-bugs-list] [ python-Bugs-814253 ] Grouprefs in lookbehind assertions Message-ID: Bugs item #814253, was opened at 2003-09-28 19:31 Message generated for change (Comment added) made by glchapman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814253&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Fredrik Lundh (effbot) Summary: Grouprefs in lookbehind assertions Initial Comment: I was trying to get a pattern like this to work: pat = re.compile(r'(?<=(...)\1)abc') pat.match('jkljklabc', 6) Unfortunately, that doesn't work. The problem is that sre_parse.Subpattern.getwidth() ignores GROUPREFs when calculating the width, so the subpattern in the assertion is deemed to have length of 3 (I was hoping that sre could detect that the group 1 had a fixed length, so the reference to it would also have a fixed length). I've since discovered that both Perl and PerlRE cannot handle the above pattern, but they both generate exceptions indicating that the assertion has a variable length pattern. I think it would be a good idea if sre generated an exception as well (rather than silently ignoring GROUPREFs). ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-11-02 06:31 Message: Logged In: YES user_id=86307 Attached is a patch which gives GROUPREFs an arbitrary variable width, so that they raise an exception if used in a lookbehind assertion. Obviously, it would be better if GROUPREFs returned the length of the group to which they refer, but I don't see any obvious way for getwidth() to get that information (perhaps I missed something?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814253&group_id=5470 From noreply at sourceforge.net Sun Nov 2 11:12:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 11:12:05 2003 Subject: [Python-bugs-list] [ python-Bugs-833905 ] Incorrect priority 'in' and '==' Message-ID: Bugs item #833905, was opened at 2003-10-31 23:06 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833905&group_id=5470 Category: Documentation >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Roth (jhrothjr) >Assigned to: Alex Martelli (aleax) Summary: Incorrect priority 'in' and '==' Initial Comment: Section 5.9 of the LRM specifies that 'in' and 'is' are treated the same as '=='. However, the priority chart in the 5.14 Summary part of chapter 5 gives them different priorities. This leads one to expect that 'a' in 'abc' == 1 should parse as if it was 'a' in ('abc' == 1) while it actually parses as ('a' in 'abc') == 1. The priority chart in the LRM should be corrected to put both 'is' and 'in' on the same line with the other conditionals. It would also be nice if a note pointed out that all of the operators on this line exhibit short circuit behavior, and also that this is not a change from prior releases. See the discussion on c.l.py beginning on 10/30/2003 titled Boolean Confusion. The first post is by Frantisek Fuka. I've put it under 2.2.3 only because I don't have the 2.3.2 manual to hand. I believe the original report on c.l.py was under 2.3.2 John Roth ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 17:12 Message: Logged In: YES user_id=60314 The latex source code for the priority chart is clearly coded with the intention of having tests and comparisons in the same box (there is just one \hline tag before and one after them all) but the latex->html formatting does not follow this intention (and does put each into a visually separate "box", leading to the possible confusion). As a fix, I have clarified the previously rather elliptical text just before the table, explicitly reminding the reader that comparisons _and tests_ all have the same priority, and all chain, and inserting a reference to 5.9 in lieu of the previous vaguer "see above". The reminder about short-circuiting here is unwarranted -- indeed it's not even given for 'and' and 'or' -- as this table is about syntax, not semantics -- so I have not inserted it as suggested; the explicit pointer to 5.9 should take care of that. Attached see the context-diff file ref5.diff; I have also committed the change (on the 2.3 maintenance branch of the CVS sources, only). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833905&group_id=5470 From noreply at sourceforge.net Sun Nov 2 11:31:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 11:31:54 2003 Subject: [Python-bugs-list] [ python-Bugs-832515 ] Bad Security Advice in CGI Documentation Message-ID: Bugs item #832515, was opened at 2003-10-29 18:20 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832515&group_id=5470 Category: Documentation >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matt Steven (mr_perl) >Assigned to: Alex Martelli (aleax) Summary: Bad Security Advice in CGI Documentation Initial Comment: /usr/share/doc/python-docs-2.2.3/html/lib/node305.html Contains the suggestion: "When reading or writing external files, make sure they can be read or written by every user on the system." This is terrible advice, suggesting you make all your files 777. This line should be removed, or replaced with something like "When reading or writing external files, make sure they can be read or written by the web server or appropriate suexec UID" ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 17:31 Message: Logged In: YES user_id=60314 The advice as given is indeed bad security. I have replaced it with: \item When reading or writing external files, make sure they can be read or written by the userid under which your CGI script will be running: this is typically the userid under which the web server is running, or some explicitly specified userid for a web server's \samp{suexec} feature. and committed the change on the 2.3 branch on CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832515&group_id=5470 From noreply at sourceforge.net Sun Nov 2 11:39:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 11:39:13 2003 Subject: [Python-bugs-list] [ python-Bugs-831969 ] Docstring for pyclbr.readmodule() is incorrect Message-ID: Bugs item #831969, was opened at 2003-10-28 22:48 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831969&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeff Grimmett (grimmtooth) >Assigned to: Alex Martelli (aleax) Summary: Docstring for pyclbr.readmodule() is incorrect Initial Comment: Review of source code for pyclbr.readmodule() reveals the following: '''Backwards compatible interface. Call readmodule_ex() and then only keep Class objects from the resulting dictionary.''' However, the function actually calls pyclbr._readmodule (): dict = _readmodule(module, path) (around line 81 of pyclbr.py) It *appears* that the code is good and that the docstring just needs adjusted. (py v. 2.3.1, Win2K 5.00.2195) ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 17:39 Message: Logged In: YES user_id=60314 The docstring correctly describes the _effects_ of function readmodule in terms of documented function readmodule_ex. The existence of function _readmodule to which both functions readmodule and readmodule_ex delegate their jobs is an implementation detail and as such it is not a bug that it's not explained in the docstring of function readmodule. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831969&group_id=5470 From noreply at sourceforge.net Sun Nov 2 11:51:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 11:52:01 2003 Subject: [Python-bugs-list] [ python-Bugs-831271 ] httplib.HTTPConnection._send_request header parsing bug Message-ID: Bugs item #831271, was opened at 2003-10-27 20:57 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470 >Category: Python Library Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Jason R. Coombs (jaraco) >Assigned to: Alex Martelli (aleax) Summary: httplib.HTTPConnection._send_request header parsing bug Initial Comment: The test on lines 730-731 of httplib.py as released with Python 2.3.2 doesn't do what it's intended to do. Consider >>> headers = { 'hoST': 'www.someplace.org' } >>> 'Host' in ( headers or [k for k in headers.iterkeys() if k.lower() == 'host' ] ) False This sample code demonstrates that the code in httplib at line 730 doesn't work as intended (it should return true for any dict who's keys include 'host' of any case). Clearly the 'or' syntax has confused someone here, because the portion after the or (if executed) is always an empty list. I recommend instead if 'host' in map( str.lower, headers.keys() ): Or a better general solution might be to force all header keys to be case-insensitive strings by overriding str and dict to new case-insensitive versions, something like the attached. This idea, however, is just a suggestion, and probably needs to be thought through more thoroughly. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 17:51 Message: Logged In: YES user_id=60314 You're certainly right that lines 730-731 cannot be correct, for exactly the reason you specify; and that forcing case-insensitive header dicts may be a cool idea but it's too invasive for such a simple fix. I've done some timing and I think the simplest and fastest way to check is: if 'host' in [k.lower() for k in headers]: accordingly, I have committed this change to the 2.3 branch in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470 From noreply at sourceforge.net Sun Nov 2 12:11:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 12:12:30 2003 Subject: [Python-bugs-list] [ python-Bugs-827856 ] object.h misdocuments PyDict_SetItemString Message-ID: Bugs item #827856, was opened at 2003-10-22 00:47 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 >Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Alex Martelli (aleax) Summary: object.h misdocuments PyDict_SetItemString Initial Comment: I just happened to notice the following in the comment titled "Reference Counts" toward the end of object.h (2.3.2): Functions that 'store' objects such as PyTuple_SetItem () and PyDict_SetItemString() don't increment the reference count of the object I believe PyDict_SetItemString does increment the refcount. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 18:11 Message: Logged In: YES user_id=60314 I have fixed (and otherwise clarified) the comment in question, as per glchapman's patch, and committed the change to the 2.3 maintenance branch of CVS . ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-11-02 15:42 Message: Logged In: YES user_id=86307 Attached is a patch (against 2.3.2 object.h) which changes the reference to PyDict_SetItemString to PyList_SetItem. It also corrects another typo I noticed this morning. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 11:29 Message: Logged In: YES user_id=887415 Hi Greg, you are right, whoever wrote it probably meant PyList_SetItem (according to Ref.Manual 1.2.1.1 and source). Will you submit a patch? ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 From noreply at sourceforge.net Sun Nov 2 12:28:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 12:28:53 2003 Subject: [Python-bugs-list] [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-21 01:41 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&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: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 18:28 Message: Logged In: YES user_id=60314 I notice that the tutorial currently in CVS seems to have been already fixed (by exciding the paragraph tjreedy quoted). To fix the reference manual, I propose the enclosed patch. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-21 20:19 Message: Logged In: YES user_id=593130 The tutorial will also need revision of deletion: 5.1.4 List Comprehensions has this: To make list comprehensions match the behavior of for loops, assignments to the loop variable remain visible outside of the comprehension: >>> x = 100 # this gets overwritten >>> [x**3 for x in range(5)] [0, 1, 8, 27, 64] >>> x # the final value for range(5) 4 ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-21 16:26 Message: Logged In: YES user_id=43607 Actually, this is not different from $ python Python 2.4a0 (#2, Oct 14 2003, 11:28:48) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> for x in []: ... pass ... >>> print x Traceback (most recent call last): File "", line 1, in ? NameError: name 'x' is not defined >>> where x is also undefined after iteraring through an empty list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-10-21 15:52 Message: Logged In: YES user_id=44345 A good point raised by Michael Hudson is that foo = [x for x in R] print x will fail if R is empty (and x wasn't previously defined). All the more reason to deprecate its usage and suppress the leaking variable. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-21 02:04 Message: Logged In: YES user_id=593130 Ref Man 5.2.4 List displays: suggested addition at end. Using leaked 'for ' control variables outside the list display is deprecated and will not work when the bug is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Sun Nov 2 12:56:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 12:57:06 2003 Subject: [Python-bugs-list] [ python-Bugs-824371 ] ntpath.expandvars doesn't expand Windows-style variables. Message-ID: Bugs item #824371, was opened at 2003-10-15 22:32 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824371&group_id=5470 >Category: Windows >Group: Feature Request Status: Open Resolution: None >Priority: 4 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: ntpath.expandvars doesn't expand Windows-style variables. Initial Comment: ntpath.expandvars is exactly the same as posixpath.expandvars -- it only expands $vars. But in windows, environment variables are represented by %vars%, not $vars. I can write a patch if necessary. Having read the code, I noticed that it went to great lengths to do what could quite easily be done with a regular expression, so I assume using regular expressions isn't kosher in the *path modules? ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 18:56 Message: Logged In: YES user_id=60314 it seems to me that the behavior of os.path.expandvars is clearly documented (both in the docstrings and the library reference) and therefore i marked this as a feature request with slightly lower priority (features are unlikely to be added within 2.3 any more -- you may want to target 2.4 for this, therefore). ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-20 20:26 Message: Logged In: YES user_id=887415 Hi Jeremy The purpose of path.expandvars is to retrieve environment variables in a platform independant way into a user supplied string, as in path.expandvars('$PYTHON/Lib/site-packages'). Using %vars% on windows and $vars on unix would make the method pointless. So this is no bug, though it might be explained a little vague in the docstring (IMHO the overall purpose and the phrase "left unchanged" are both unclear): >>> help(path.expandvars) Help on function expandvars in module ntpath: expandvars(path) Expand shell variables of form $var and ${var}. Unknown variables are left unchanged. Though, the module docs offer a better explanation: "Return the argument with environment variables expanded. Substrings of the form "$name" or "${name}" are replaced by the value of environment variable name. Malformed variable names and references to non-existing variables are left unchanged. On the Macintosh, this always returns path unchanged." Still, what does "unchanged" mean? On my windows system non-existing variables are IGNORED, they are not left unchanged anywhere: >>> path.expandvars('$MADEUP/Lib/site-packages') '/Lib/site-packages' Is it me or is that a bug? :) ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824371&group_id=5470 From noreply at sourceforge.net Sun Nov 2 13:13:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 13:13:46 2003 Subject: [Python-bugs-list] [ python-Bugs-821896 ] _set_cloexec of tempfile.py uses incorrect error handling Message-ID: Bugs item #821896, was opened at 2003-10-11 21:49 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821896&group_id=5470 Category: Python Library >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Per Cederqvist (ceder) >Assigned to: Alex Martelli (aleax) Summary: _set_cloexec of tempfile.py uses incorrect error handling Initial Comment: The _set_cloexec function of tempfile.py looks like this on Unix-like platforms: def _set_cloexec(fd): flags = _fcntl.fcntl(fd, _fcntl.F_GETFD, 0) if flags >= 0: # flags read successfully, modify flags |= _fcntl.FD_CLOEXEC _fcntl.fcntl(fd, _fcntl.F_SETFD, flags) However, fcntl.fcntl() will never return a negative value. If an error occurs, it will instead raise an exception: >>> fcntl.fcntl(10, fcntl.F_GETFD, 0) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 9] Bad file descriptor (This was tested on Linux.) I doubt that this will ever cause any problems, except if somebody uses the code as an example and copies the error to their own code. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 19:13 Message: Logged In: YES user_id=60314 your remarks are entirely correct. I have changed the incorrect test into a try/except IOError, and committed the change on the 2.3 maintenance branch in CVS. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821896&group_id=5470 From noreply at sourceforge.net Sun Nov 2 13:37:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 13:37:23 2003 Subject: [Python-bugs-list] [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-02 01:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 Category: Tkinter Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Richardson (garyrxx) Assigned to: Martin v. L?wis (loewis) Summary: Mouse wheel crashes program Initial Comment: The following program (by Michael Peuser) crashes as soon as the mouse wheel is moved. See my post to c.l.p. on Oct 29. Gary Richardson #------------------------- from Tkinter import * def _onMouseWheel(event): print event root = Tk() root.bind('',_onMouseWheel) root.mainloop() ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 19:37 Message: Logged In: YES user_id=21627 What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 From noreply at sourceforge.net Sun Nov 2 14:28:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 14:28:50 2003 Subject: [Python-bugs-list] [ python-Bugs-834676 ] segfault in unicodedata module (hangul syllables) Message-ID: Bugs item #834676, was opened at 2003-11-02 19: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=834676&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: segfault in unicodedata module (hangul syllables) Initial Comment: [forwarded from http://bugs.debian.org/218697] start an interactive python2.3 interpreter. run the following command, twice if necessary: __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') this reliably segfaults python2.3 on both i686 and powerpc. although my testing has not been very extensive (unicode is somewhat large and slightly complex,) so far i have seen the crash only when processing pre-composed hangul syllables. decomposing them into combining jamos before calling unicodedata.normalize seems to avoid the crash, and i've included a wrapper that does just that in this report. unfortunately, this method is used internally by encodings.idna, so this means processing some internationalized korean domain names can likely crash any python program with support for internationalized domain names. please do let me know if you would like more details, or if there's anything further i can do to help! workaround: as a workaround in my own python programs, i wrapped unicodedata.normalize like this (see attachment). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 From noreply at sourceforge.net Sun Nov 2 14:40:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 14:40:12 2003 Subject: [Python-bugs-list] [ python-Bugs-821818 ] pyclbr.readmodule_ex() Message-ID: Bugs item #821818, was opened at 2003-10-11 18:10 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821818&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dmitry Vasiliev (hdima) >Assigned to: Alex Martelli (aleax) Summary: pyclbr.readmodule_ex() Initial Comment: Function readmodule_ex() from pyclbr module needs to be described. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 20:40 Message: Logged In: YES user_id=60314 added the missing docs and committed the change to the CVS 2.3 maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821818&group_id=5470 From noreply at sourceforge.net Sun Nov 2 14:56:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 14:57:13 2003 Subject: [Python-bugs-list] [ python-Bugs-815668 ] test_locale and en_US Message-ID: Bugs item #815668, was opened at 2003-10-01 09:28 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_locale and en_US Initial Comment: Is it worth making test_locale try first "en_US", then "C", as locale names? None of the systems I've tried have "en_US" as a valid locale. ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 20:56 Message: Logged In: YES user_id=60314 hmmm -- my Linux Mandrake 9.1 does succeed happily with en_US (and on Windows we already use 'en' instead). What systems have you tried, Anthony? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:30 Message: Logged In: YES user_id=21627 That would be incorrect. The test whether there is grouping in numeric formatting. However, in the C locale, there is no grouping. Most systems should have an English locale - it might have a different name, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 From noreply at sourceforge.net Sun Nov 2 15:01:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 15:01:33 2003 Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-29 22:55 Message generated for change (Comment added) made by aleax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: Alex Martelli (aleax) Date: 2003-11-02 21:01 Message: Logged In: YES user_id=60314 any news on this, i.e., does the --without-cxx solve everything? Just seeing if the bug can be marked as closed... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 02:26 Message: Logged In: YES user_id=29957 configure --without-cxx is the magic you probably want. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 16:15 Message: Logged In: YES user_id=876734 I didn't realize that the decision to use g++ as the linker was one that we made here locally (I didn't do the build). We'll try avoiding it and see if things get better. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 16:14 Message: Logged In: YES user_id=21627 I did not suggest to avoid gcc, but to avoid g++ (I'm only guessing here, since you haven't reported the build log, ldd output for pyexpat.so, or similar - but it might be that pyexpat.so was linked with g++, which would explain that it somehow calls __cxa_finalize). pyexpat itself has no C++ in it. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 15:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Sun Nov 2 15:21:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 15:21:23 2003 Subject: [Python-bugs-list] [ python-Bugs-834676 ] segfault in unicodedata module (hangul syllables) Message-ID: Bugs item #834676, was opened at 2003-11-02 19:28 Message generated for change (Comment added) made by bsittler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: M.-A. Lemburg (lemburg) Summary: segfault in unicodedata module (hangul syllables) Initial Comment: [forwarded from http://bugs.debian.org/218697] start an interactive python2.3 interpreter. run the following command, twice if necessary: __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') this reliably segfaults python2.3 on both i686 and powerpc. although my testing has not been very extensive (unicode is somewhat large and slightly complex,) so far i have seen the crash only when processing pre-composed hangul syllables. decomposing them into combining jamos before calling unicodedata.normalize seems to avoid the crash, and i've included a wrapper that does just that in this report. unfortunately, this method is used internally by encodings.idna, so this means processing some internationalized korean domain names can likely crash any python program with support for internationalized domain names. please do let me know if you would like more details, or if there's anything further i can do to help! workaround: as a workaround in my own python programs, i wrapped unicodedata.normalize like this (see attachment). ---------------------------------------------------------------------- Comment By: Benjamin C. W. Sittler (bsittler) Date: 2003-11-02 20:21 Message: Logged In: YES user_id=645359 fyi, i ran into this while adding an encoding similar to IDNA [i believe it's an IDNA superset], but capable of handling free text -- see http://xent.com/~bsittler/icb_ace.py -- and my very first test data was the word 한글, written in precomposed form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 From noreply at sourceforge.net Sun Nov 2 21:42:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 21:42:20 2003 Subject: [Python-bugs-list] [ python-Bugs-834351 ] Mouse wheel crashes program Message-ID: Bugs item #834351, was opened at 2003-11-01 16:37 Message generated for change (Comment added) made by garyrxx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 Category: Tkinter Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Richardson (garyrxx) Assigned to: Martin v. L?wis (loewis) Summary: Mouse wheel crashes program Initial Comment: The following program (by Michael Peuser) crashes as soon as the mouse wheel is moved. See my post to c.l.p. on Oct 29. Gary Richardson #------------------------- from Tkinter import * def _onMouseWheel(event): print event root = Tk() root.bind('',_onMouseWheel) root.mainloop() ---------------------------------------------------------------------- >Comment By: Gary Richardson (garyrxx) Date: 2003-11-02 18:42 Message: Logged In: YES user_id=899035 I'm using Win98SE. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-02 10:37 Message: Logged In: YES user_id=21627 What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834351&group_id=5470 From noreply at sourceforge.net Sun Nov 2 21:54:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 21:54:42 2003 Subject: [Python-bugs-list] [ python-Bugs-834840 ] Unhelpful error message from cgi module Message-ID: Bugs item #834840, was opened at 2003-11-02 20: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=834840&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: Unhelpful error message from cgi module Initial Comment: [From a post to python-help] If an instance of the cgi module's FieldStorage class doesn't recognize the HTTP request it's trying to parse as a form, no error is raised but attempting to access any of the form data later raises the unhelpful exception TypeError, "not indexable". It seems that even Andrew Kuchling was once confused by this behavior: http://groups.yahoo.com/group/web-sig/message/28 It happens because in the FieldStorage class's __init__(), the request's content-type is tested against "multipart/" and "application/x-www-form-urlencoded". If it doesn't match either of those, read_single() is called. In that case, self.list isn't changed from its default of None. That causes any call to __getitem__() to raise TypeError, "not indexable". I'm no CGI expert, but I don't see the value of read_single(). As far as I can tell, it would make sense to raise TypeError (or perhaps ValueError) at that point with a message something like, "Data not recognized as a form". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834840&group_id=5470 From noreply at sourceforge.net Sun Nov 2 22:29:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 2 22:29:58 2003 Subject: [Python-bugs-list] [ python-Bugs-834461 ] simple bsddb interface potential for deadlock with threads Message-ID: Bugs item #834461, was opened at 2003-11-02 01:30 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Gregory P. Smith (greg) Summary: simple bsddb interface potential for deadlock with threads Initial Comment: >From Lib/bsddb/__init__.py # FIXME-20031101-greg: I believe there is still the potential # for deadlocks in a multithreaded environment if someone # attempts to use the any of the cursor interfaces in one # thread while doing a put or delete in another thread. The # reason is that _checkCursor and _closeCursors are not atomic # operations. Doing our own locking around self.dbc, # self.saved_dbc_key and self._iter_cursors could prevent this. # TODO: A test case demonstrating the problem needs to be written. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-11-02 19:29 Message: Logged In: YES user_id=413 A fix for my first comment about the memory leak has been committed that uses weak references and callbacks so that DBCursor objects are always destroyed and their references removed from _DBWithCursor's pool when the iterator that created them is destroyed. The potential threading deadlock issues still stand. Lockng seems like it could have a serious performance impact by surrounding way too many database operations (all cursor operations, iterator use and __delitem__, __setitem__ and close) with locks. what should be done: _DBWithCursor __delitem__, __setitem__ and close methods need to prevent any cursors from being created until they have completed. But for performance reasons multiple database read operations should be allowed at the same time (get, cursor methods or iterators). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-11-02 01:47 Message: Logged In: YES user_id=413 While I'm at it, I think there might be a memory leak in my __iter__ and iteritems() implementation when the resulting generator objects are destroyed without completing their iteration (as will happen in UserDict.DictMixIn.popitem among other things). They add their DBCursor to _DBWithCursor._iter_cursors but only ever delete it from that hash before a return rather than a yield. The solution to this should be simple: have _closeCursors() empty the _iter_cursors hash after calling close() on all of the cursors. __iter__ and iteritems() already ignore a KeyError when trying to remove their cursor from the map when returning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834461&group_id=5470 From noreply at sourceforge.net Mon Nov 3 05:09:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 05:09:53 2003 Subject: [Python-bugs-list] [ python-Bugs-834676 ] segfault in unicodedata module (hangul syllables) Message-ID: Bugs item #834676, was opened at 2003-11-02 20:28 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. L?wis (loewis) Summary: segfault in unicodedata module (hangul syllables) Initial Comment: [forwarded from http://bugs.debian.org/218697] start an interactive python2.3 interpreter. run the following command, twice if necessary: __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') this reliably segfaults python2.3 on both i686 and powerpc. although my testing has not been very extensive (unicode is somewhat large and slightly complex,) so far i have seen the crash only when processing pre-composed hangul syllables. decomposing them into combining jamos before calling unicodedata.normalize seems to avoid the crash, and i've included a wrapper that does just that in this report. unfortunately, this method is used internally by encodings.idna, so this means processing some internationalized korean domain names can likely crash any python program with support for internationalized domain names. please do let me know if you would like more details, or if there's anything further i can do to help! workaround: as a workaround in my own python programs, i wrapped unicodedata.normalize like this (see attachment). ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-03 11:09 Message: Logged In: YES user_id=38388 Martin wrote this part. Assigning to him. ---------------------------------------------------------------------- Comment By: Benjamin C. W. Sittler (bsittler) Date: 2003-11-02 21:21 Message: Logged In: YES user_id=645359 fyi, i ran into this while adding an encoding similar to IDNA [i believe it's an IDNA superset], but capable of handling free text -- see http://xent.com/~bsittler/icb_ace.py -- and my very first test data was the word 한글, written in precomposed form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 From noreply at sourceforge.net Mon Nov 3 06:59:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 06:59:19 2003 Subject: [Python-bugs-list] [ python-Bugs-832535 ] Inconsitent line numbering in traceback Message-ID: Bugs item #832535, was opened at 2003-10-29 17:48 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsitent line numbering in traceback Initial Comment: Transcript below documents the problem. A traceback shows a line with no float() op, but complains of a float op error. I restart the shell, with no changes to the imported module, and this time line 45 is correctly listed. >>> reload(brawley) >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 color = elems[-2] ValueError: invalid literal for float(): 'White >>> ================================ RESTART ================================ >>> import brawley >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-03 11:59 Message: Logged In: YES user_id=6656 If by reload you mean the builtin function reload(), the answer is probably because that would be a bitch to arrange (have you ever looked at the import code? scares me more than most other in Python). Could be done, though, and is perhaps the right answer. Other answers would be having traceback.py not use linecache or deprecating and doing away with linecache entirely. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-31 19:41 Message: Logged In: YES user_id=99508 Yeah, this is definitely the linecache problem. Is there a good reason why reload doesn't do a linecache.checkcache itself? I really doubt reload is being called inside performance-sensitive code. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-29 18:02 Message: Logged In: YES user_id=6656 Is this the hoary old "being lied to by linecache" thing? I complain about that every now and again, but haven't actually done anything about it yet... ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-10-29 17:56 Message: Logged In: YES user_id=191709 It's a little more serious. After a save/reload, the traceback will echo code that's no longer present in the source at all. Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White' But line 45 in the saved/reloaded source is really: x,y,z,radius = [float(i) for i in elems.split(',')[:-1]] When I restart the shell and import, the real source code is echoed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 From noreply at sourceforge.net Mon Nov 3 07:03:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 07:03:23 2003 Subject: [Python-bugs-list] [ python-Bugs-833905 ] Incorrect priority 'in' and '==' Message-ID: Bugs item #833905, was opened at 2003-10-31 22:06 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833905&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Roth (jhrothjr) Assigned to: Alex Martelli (aleax) Summary: Incorrect priority 'in' and '==' Initial Comment: Section 5.9 of the LRM specifies that 'in' and 'is' are treated the same as '=='. However, the priority chart in the 5.14 Summary part of chapter 5 gives them different priorities. This leads one to expect that 'a' in 'abc' == 1 should parse as if it was 'a' in ('abc' == 1) while it actually parses as ('a' in 'abc') == 1. The priority chart in the LRM should be corrected to put both 'is' and 'in' on the same line with the other conditionals. It would also be nice if a note pointed out that all of the operators on this line exhibit short circuit behavior, and also that this is not a change from prior releases. See the discussion on c.l.py beginning on 10/30/2003 titled Boolean Confusion. The first post is by Frantisek Fuka. I've put it under 2.2.3 only because I don't have the 2.3.2 manual to hand. I believe the original report on c.l.py was under 2.3.2 John Roth ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-03 12:03 Message: Logged In: YES user_id=6656 Alex, I think as a point of principle checking things in to the maintenence branch *only* is a bad idea. Changes generally filter from trunk to release branch, not the other way round. Would it be terribly hard for you to make all your weekend checkins on the trunk, too? ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-11-02 16:12 Message: Logged In: YES user_id=60314 The latex source code for the priority chart is clearly coded with the intention of having tests and comparisons in the same box (there is just one \hline tag before and one after them all) but the latex->html formatting does not follow this intention (and does put each into a visually separate "box", leading to the possible confusion). As a fix, I have clarified the previously rather elliptical text just before the table, explicitly reminding the reader that comparisons _and tests_ all have the same priority, and all chain, and inserting a reference to 5.9 in lieu of the previous vaguer "see above". The reminder about short-circuiting here is unwarranted -- indeed it's not even given for 'and' and 'or' -- as this table is about syntax, not semantics -- so I have not inserted it as suggested; the explicit pointer to 5.9 should take care of that. Attached see the context-diff file ref5.diff; I have also committed the change (on the 2.3 maintenance branch of the CVS sources, only). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833905&group_id=5470 From noreply at sourceforge.net Mon Nov 3 10:17:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 10:19:08 2003 Subject: [Python-bugs-list] [ python-Bugs-834676 ] segfault in unicodedata module (hangul syllables) Message-ID: Bugs item #834676, was opened at 2003-11-02 14:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Martin v. L?wis (loewis) Summary: segfault in unicodedata module (hangul syllables) Initial Comment: [forwarded from http://bugs.debian.org/218697] start an interactive python2.3 interpreter. run the following command, twice if necessary: __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') this reliably segfaults python2.3 on both i686 and powerpc. although my testing has not been very extensive (unicode is somewhat large and slightly complex,) so far i have seen the crash only when processing pre-composed hangul syllables. decomposing them into combining jamos before calling unicodedata.normalize seems to avoid the crash, and i've included a wrapper that does just that in this report. unfortunately, this method is used internally by encodings.idna, so this means processing some internationalized korean domain names can likely crash any python program with support for internationalized domain names. please do let me know if you would like more details, or if there's anything further i can do to help! workaround: as a workaround in my own python programs, i wrapped unicodedata.normalize like this (see attachment). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-03 10:17 Message: Logged In: YES user_id=33168 Here's some more info, hope it helps. >>> __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') Debug memory block at address p=0x402ac410: 20 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x402ac424 are not all FORBIDDENBYTE (0xfb): at tail+0: 0xaf *** OUCH at tail+1: 0x11 *** OUCH at tail+2: 0x00 *** OUCH at tail+3: 0x00 *** OUCH The block was made by call #19688 to debug malloc/realloc. Data at p: 12 11 00 00 61 11 00 00 ... 00 11 00 00 73 11 00 00 Fatal Python error: bad trailing pad byte #7 0x08082a7c in _PyObject_DebugRealloc (p=0x402ac410, nbytes=28) at Objects/obmalloc.c:1038 #8 0x0809f1b7 in unicode_resize (unicode=0x40299988, length=6) at Objects/unicodeobject.c:150 #9 0x0809f6da in PyUnicodeUCS4_Resize (unicode=0xbffff4bc, length=6) at Objects/unicodeobject.c:298 #10 0x405d702e in nfd_nfkd (input=0x40299928, k=0) at /home/neal/build/python/2_3/Modules/unicodedata.c:356 #11 0x405d7233 in nfc_nfkc (input=0x40299928, k=0) at /home/neal/build/python/2_3/Modules/unicodedata.c:412 #12 0x405d7616 in unicodedata_normalize (self=0x0, args=0x4052522c) at /home/neal/build/python/2_3/Modules/unicodedata.c:517 #13 0x0810a182 in PyCFunction_Call (func=0x4052553c, arg=0x4052522c, kw=0x0) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-03 05:09 Message: Logged In: YES user_id=38388 Martin wrote this part. Assigning to him. ---------------------------------------------------------------------- Comment By: Benjamin C. W. Sittler (bsittler) Date: 2003-11-02 15:21 Message: Logged In: YES user_id=645359 fyi, i ran into this while adding an encoding similar to IDNA [i believe it's an IDNA superset], but capable of handling free text -- see http://xent.com/~bsittler/icb_ace.py -- and my very first test data was the word 한글, written in precomposed form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 From noreply at sourceforge.net Mon Nov 3 11:07:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 11:08:10 2003 Subject: [Python-bugs-list] [ python-Bugs-835110 ] possible uninitialized variable in listobject.c:listsort Message-ID: Bugs item #835110, was opened at 2003-11-03 10: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=835110&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Raymond Hettinger (rhettinger) Summary: possible uninitialized variable in listobject.c:listsort Initial Comment: GCC warns that the local variable n in listobject.c:listsort might be uninitialized. I'm not convinced that's the case, but it seems that n should only be declared once and should be initialized at that point to avoid confusion. It's both a variable local to listsort and a variable local to an embedded do/while loop. It's also not clear that the goto fail statement inside the do/while is correct. Do you intend for n to have the value set within the loop? I think when you get to the fail: label you'll see the outer n. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835110&group_id=5470 From noreply at sourceforge.net Mon Nov 3 12:06:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 12:07:04 2003 Subject: [Python-bugs-list] [ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1 Message-ID: Bugs item #835145, was opened at 2003-11-03 08:06 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=835145&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] zipfile test failure on AIX 5.1 Initial Comment: $ cd /opt/build/Python-2.3.2 $ ./python -E -tt Lib/test/test_zipfile.py Traceback (most recent call last): File "Lib/test/test_zipfile.py", line 35, in ? zipTest(file, zipfile.ZIP_STORED, writtenData) File "Lib/test/test_zipfile.py", line 13, in zipTest zip.close() File "/opt/build/Python-2.3.2/Lib/zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert Exception exceptions.OverflowError: 'long int too large to convert' in > ignored The test passes just fine on AIX 4.3.2. This is against a Python built with the IBM v6 C compiler and GCC 3.3.2. I added some debugging print statements to Lib/zipfile.py and it seems that zinfo.external_attr is out of whack. On AIX 4.3.2, the value for this variable is "2176057344" while on AIX 5.1 it is "10765991936". I tracked this back to the following line in the write method of Lib/zipfile.py: zinfo.external_attr = st[0] << 16L # Unix attributes On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is 164276. In python 2.2.x, it was '<< 16' which resulted in a signed value on AIX 5.1. I really don't think you can use the 16L as mode_t on AIX is unsigned int. Ditto for other platforms. Why not just store st[0] unchanged? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 From noreply at sourceforge.net Mon Nov 3 12:58:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 12:58:40 2003 Subject: [Python-bugs-list] [ python-Bugs-835176 ] [2.3.2] bz2 test failure on AIX 4.3.2, Tru64 UNIX Message-ID: Bugs item #835176, was opened at 2003-11-03 08: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=835176&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] bz2 test failure on AIX 4.3.2, Tru64 UNIX Initial Comment: I'm seeing test failures of the bz2 module on AIX 4.3.2 and Tru64 UNIX (and sporadically on HP-UX 11.00): $ cd /opt/build/Python-2.3.2 $ ./python -E -tt Lib/test/test_bz2.py testIterator (__main__.BZ2FileTest) ... ok testOpenDel (__main__.BZ2FileTest) ... ok testOpenNonexistent (__main__.BZ2FileTest) ... ok ... testDecompress (__main__.FuncTest) ... ok testDecompressEmpty (__main__.FuncTest) ... ok testDecompressIncomplete (__main__.FuncTest) ... ok ====================================================================== ERROR: testCompress (__main__.FuncTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_bz2.py", line 295, in testCompress self.assertEqual(self.decompress(data), self.TEXT) File "Lib/test/test_bz2.py", line 26, in decompress pop.tochild.close() IOError: [Errno 32] Broken pipe ---------------------------------------------------------------------- Ran 30 tests in 5.213s FAILED (errors=1) Traceback (most recent call last): File "Lib/test/test_bz2.py", line 320, in ? test_main() File "Lib/test/test_bz2.py", line 316, in test_main FuncTest File "/opt/build/Python-2.3.2/Lib/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/opt/build/Python-2.3.2/Lib/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_bz2.py", line 295, in testCompress self.assertEqual(self.decompress(data), self.TEXT) File "Lib/test/test_bz2.py", line 26, in decompress pop.tochild.close() IOError: [Errno 32] Broken pipe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835176&group_id=5470 From noreply at sourceforge.net Mon Nov 3 15:01:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 15:01:50 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 (Comment added) made by astrand 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. ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-03 21:01 Message: Logged In: YES user_id=344921 I've added universal newline support to popen5. http://www.lysator.liu.se/~astrand/popen5/. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-27 00:04 Message: Logged In: YES user_id=45365 Theoretically this is easy to fix: if mode=="U" or "rU" just pass "r" to popen(), "rb" to fdopen() and _O_BINARY to the lowlevel calls, and the original string to PyFile_FromFile. But this whole popen{,2,3,4} section of posixmodule.c is so fiendishly complicated with all the platform special cases that I'm loath to touch it... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788035&group_id=5470 From noreply at sourceforge.net Mon Nov 3 15:26:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 15:26:17 2003 Subject: [Python-bugs-list] [ python-Bugs-835255 ] new.function() docs out of date Message-ID: Bugs item #835255, was opened at 2003-11-03 15:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: new.function() docs out of date Initial Comment: The argument list for new.function() has grown to accomodate new runtime features (closure info, for example), but the docs have not kept up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470 From noreply at sourceforge.net Mon Nov 3 16:23:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 16:23:41 2003 Subject: [Python-bugs-list] [ python-Bugs-835300 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835300, was opened at 2003-11-03 22: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=835300&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 From noreply at sourceforge.net Mon Nov 3 16:36:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 16:36:39 2003 Subject: [Python-bugs-list] [ python-Bugs-835307 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835307, was opened at 2003-11-03 22:36 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=835307&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 From noreply at sourceforge.net Mon Nov 3 16:37:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 16:38:02 2003 Subject: [Python-bugs-list] [ python-Bugs-835307 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835307, was opened at 2003-11-03 22:36 Message generated for change (Settings changed) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 From noreply at sourceforge.net Mon Nov 3 16:38:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 16:38:50 2003 Subject: [Python-bugs-list] [ python-Bugs-835300 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835300, was opened at 2003-11-03 22:23 Message generated for change (Settings changed) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 From noreply at sourceforge.net Mon Nov 3 16:38:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 16:38:51 2003 Subject: [Python-bugs-list] [ python-Bugs-835307 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835307, was opened at 2003-11-03 22:36 Message generated for change (Comment added) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- >Comment By: Max Neunh?ffer (neunhoef) Date: 2003-11-03 22:38 Message: Logged In: YES user_id=350896 Sorry, this was accidentally submitted twice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 From noreply at sourceforge.net Mon Nov 3 17:16:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 17:17:02 2003 Subject: [Python-bugs-list] [ python-Bugs-835338 ] [2.3.2] test_socket failure on IRIX 6.5 Message-ID: Bugs item #835338, was opened at 2003-11-03 13: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=835338&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] test_socket failure on IRIX 6.5 Initial Comment: Lib/test/test_socket.py fails on IRIX 6.5.19m with GCC 3.3.2: $ ./python -E -tt ./Lib/test/test_socket.py testCrucialConstants (__main__.GeneralModuleTests) ... ok testDefaultTimeout (__main__.GeneralModuleTests) ... ok testGetServByName (__main__.GeneralModuleTests) ... ok ... testReadline (__main__.SmallBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok ====================================================================== FAIL: testStringToIPv4 (__main__.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test_socket.py", line 361, in testStringToIPv4 self.assertEquals('1.0.1.0', f('\x01\x00\x01\x00')) File "/opt/build/Python-2.3.2/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, AssertionError: '1.0.1.0' != '0.0.0.0' ---------------------------------------------------------------------- Ran 51 tests in 2.454s FAILED (failures=1) Traceback (most recent call last): File "./Lib/test/test_socket.py", line 755, in ? test_main() File "./Lib/test/test_socket.py", line 752, in test_main test_support.run_unittest(*tests) File "/opt/build/Python-2.3.2/Lib/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/opt/build/Python-2.3.2/Lib/test/test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "./Lib/test/test_socket.py", line 361, in testStringToIPv4 self.assertEquals('1.0.1.0', f('\x01\x00\x01\x00')) File "/opt/build/Python-2.3.2/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, AssertionError: '1.0.1.0' != '0.0.0.0' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835338&group_id=5470 From noreply at sourceforge.net Mon Nov 3 17:34:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 17:35:18 2003 Subject: [Python-bugs-list] [ python-Bugs-835307 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835307, was opened at 2003-11-03 15:36 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- Comment By: Max Neunh?ffer (neunhoef) Date: 2003-11-03 15:38 Message: Logged In: YES user_id=350896 Sorry, this was accidentally submitted twice! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835307&group_id=5470 From noreply at sourceforge.net Mon Nov 3 17:36:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 17:36:39 2003 Subject: [Python-bugs-list] [ python-Bugs-835300 ] socket object method "makefile" has wrong doc Message-ID: Bugs item #835300, was opened at 2003-11-03 15:23 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 1 Submitted By: Max Neunh?ffer (neunhoef) >Assigned to: Skip Montanaro (montanaro) Summary: socket object method "makefile" has wrong doc Initial Comment: The documentation of the method "makefile" for socket objects still claims that the new file object corresponds to a dup()ped file descriptor, which seems to be wrong. Python Version: 2.3.2 Operating system: Debian GNU/Linux ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835300&group_id=5470 From noreply at sourceforge.net Mon Nov 3 17:45:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 17:45:48 2003 Subject: [Python-bugs-list] [ python-Bugs-835353 ] logging.StreamHandler encodes log message in UTF-8 Message-ID: Bugs item #835353, was opened at 2003-11-03 23: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=835353&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vaclav Dvorak (vdvo) Assigned to: Nobody/Anonymous (nobody) Summary: logging.StreamHandler encodes log message in UTF-8 Initial Comment: For some reason that I do not see, logging.StreamHandler in Python 2.3 insists on writing plain non-Unicode strings to the stream, and the encoding is hard-coded as UTF-8: if not hasattr(types, "UnicodeType"): #if no unicode support... self.stream.write("%s\n" % msg) else: try: self.stream.write("%s\n" % msg) except UnicodeError: self.stream.write("%s\n" % msg.encode("UTF-8")) This behaviour is neither documented nor reasonable. Files can be perfectly able to write Unicode strings (e.g., through the use of codecs.EncodedFile or with a default encoding of sys.stdout), and even if they are not, UTF-8 is hardly the only choice for an encoding. I propose to simply replace the above code with: self.stream.write(msg) self.stream.write("\n") ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835353&group_id=5470 From noreply at sourceforge.net Mon Nov 3 21:47:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 3 21:47:30 2003 Subject: [Python-bugs-list] [ python-Bugs-835457 ] Small typo in logging documentation Message-ID: Bugs item #835457, was opened at 2003-11-04 03:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835457&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lars Bj?nnes (larsbjonnes) Assigned to: Nobody/Anonymous (nobody) Summary: Small typo in logging documentation Initial Comment: >From logging/handlers.py, in class RotatingFileHandler(logging.FileHandler) def emit(self, record): ... Output the record to the file, catering for rollover as described in setRollover(). .... There is no method named setRollover() in the module, and I believe the author really meant doRollover(). (Just nitpicking; I was just browsing through the code when I noticed it.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835457&group_id=5470 From noreply at sourceforge.net Tue Nov 4 01:58:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 4 01:58:43 2003 Subject: [Python-bugs-list] [ python-Feature Requests-835521 ] More obvious indication of __reduce__ documentation. Message-ID: Feature Requests item #835521, was opened at 2003-11-04 01:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=835521&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: More obvious indication of __reduce__ documentation. Initial Comment: I just spent quite some time searching for documentation on the interface for __reduce__. Turns out, it's in the library documentation, 3.14.5.2, under the heading "Pickling and unpickling extension types." Perhaps that heading can be changed to more clearly indicate that "__reduce__ is documented here!" At least, when I'm writing new-style classes (which the pickle/copy machinery doesn't accept anything but a copy_reg registration or __reduce__ or __reduce_ex__) I don't generally consider my work to be an "extension class" and thus hadn't ever looked under that heading. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=835521&group_id=5470 From noreply at sourceforge.net Tue Nov 4 10:43:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 4 10:43:49 2003 Subject: [Python-bugs-list] [ python-Bugs-835790 ] MacPython builds with DESTROOT need fixup Message-ID: Bugs item #835790, was opened at 2003-11-04 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835790&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython builds with DESTROOT need fixup Initial Comment: Currently building MacPython with DESTROOT causes the #! lines in the applet boot scripts to be incorrect (they include DESTROOT, but shouldn't). At the moment we fix this up later, but it would be better if they were built correctly in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835790&group_id=5470 From noreply at sourceforge.net Tue Nov 4 15:49:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 4 15:49:46 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-05 09: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=836035&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: M.-A. Lemburg (lemburg) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Tue Nov 4 16:13:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 4 16:13:27 2003 Subject: [Python-bugs-list] [ python-Bugs-836058 ] socket.send() on behaves as nonblocking when timeout is set Message-ID: Bugs item #836058, was opened at 2003-11-04 22:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836058&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vaclav Dvorak (vdvo) Assigned to: Thomas Heller (theller) Summary: socket.send() on behaves as nonblocking when timeout is set Initial Comment: When a timeout is set on a connected socket, the socket's send() method behaves as if non-blocking mode was set: when not enough buffer space is available, it raises socket.error(10035, 'The socket operation could not complete without blocking'). Instead, it should block up to the specified number of seconds and only then raise a socket.timeout exception if the data still wasn't sent. This is with Python 2.3.2-1 on Windows 98. On Linux, it works as expected. Bug 805194 might be related. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836058&group_id=5470 From noreply at sourceforge.net Wed Nov 5 00:15:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 00:15:39 2003 Subject: [Python-bugs-list] [ python-Bugs-814266 ] new.function raises TypeError for some strange reason... Message-ID: Bugs item #814266, was opened at 2003-09-29 01:31 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814266&group_id=5470 Category: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: new.function raises TypeError for some strange reason... Initial Comment: Here's an example pasted directly from the interpreter: >>> def thread(f): ... """Makes sure a command spawns a thread when called.""" ... def newf(self, irc, msg, args, *L): ... ff = new.instancemethod(f, self, self.__class__) ... t = callbacks.CommandThread(self.callCommand, ff, irc, msg, args, *L) ... t.start() ... newf = new.function(newf.func_code, newf.func_globals, f.func_name) ... newf.__doc__ = f.__doc__ ... return newf ... >>> import new >>> def groovy(): ... pass ... >>> thread(groovy) Traceback (most recent call last): File "", line 1, in ? File "", line 7, in thread TypeError: arg 5 (closure) must be tuple Given that I didn't even give the (optional) arg 5, there's some bug here, even if it's only documentation/error message. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-11-05 00:15 Message: Logged In: YES user_id=99508 This is basically a duplicate of bug #835255, except with a less-clear title. I'm going to close it (I hope you don't mind, Fred). ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-21 15:52 Message: Logged In: YES user_id=99508 Ok, I finally found my problem -- I wasn't passing the closure=newf.func_closure argument to it. Anyway, this is a significant documentation bug, I think -- aside from the fact that the library documentation isn't inline with the __doc__ string, it should be documented that the closure argument is required if the func_code depends on a closure. Check this out: >>> print new.function.__doc__ function(code, globals[, name[, argdefs[, closure]]]) Create a function object from a code object and a dictionary. The optional name string overrides the name from the code object. The optional argdefs tuple specifies the default argument values. The optional closure tuple supplies the bindings for free variables. Versus the library documentation: function( code, globals[, name[, argdefs]]) Returns a (Python) function with the given code and globals. If name is given, it must be a string or None. If it is a string, the function will have the given name, otherwise the function name will be taken from code.co_name. If argdefs is given, it must be a tuple and will be used to determine the default values of parameters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814266&group_id=5470 From noreply at sourceforge.net Wed Nov 5 01:26:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 01:27:00 2003 Subject: [Python-bugs-list] [ python-Bugs-836293 ] email generator can give bad output Message-ID: Bugs item #836293, was opened at 2003-11-05 06:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Draper (crunch) Assigned to: Nobody/Anonymous (nobody) Summary: email generator can give bad output Initial Comment: #!/usr/bin/env python #Feedback to crunch@shopip.com #Python 2.3.2 under OpenBSD 3.4 i386 import email print r""" Example of Python email generator bug. If a MIME message is missing the terminating line, the generator creates one for it -only it forgets to add the \n\n to it. This causes the following message to be concatenated to the first. """ #s1 is MIME missing terminating line; #s2 is a proper MIME message. s1="""Received: by spameater (127.0.0.1)... From: "Victor Virus" To: Subject: Unterminated MIME to corrupt your mbox! MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="xxxx" --xxxx Content-Type: text/plain; This is an unterminated MIME, like many viruses generate. I don't care about rights of viruses, but I do care if improper handling of MIME causes following messages to be lost. --xxxx """ s2=s1+"""--xxxx--\n\n""" #Create properly terminator msg1=email.message_from_string(s1) msg2=email.message_from_string(s2) print str(msg1)+str(msg2) print "p.s. Notice how the first message runs into the" print " second message." print " By adding the missing '--', this won't happen." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836293&group_id=5470 From noreply at sourceforge.net Wed Nov 5 02:37:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 02:37:54 2003 Subject: [Python-bugs-list] [ python-Bugs-836058 ] socket.send() on behaves as nonblocking when timeout is set Message-ID: Bugs item #836058, was opened at 2003-11-04 22:13 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836058&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vaclav Dvorak (vdvo) >Assigned to: Nobody/Anonymous (nobody) Summary: socket.send() on behaves as nonblocking when timeout is set Initial Comment: When a timeout is set on a connected socket, the socket's send() method behaves as if non-blocking mode was set: when not enough buffer space is available, it raises socket.error(10035, 'The socket operation could not complete without blocking'). Instead, it should block up to the specified number of seconds and only then raise a socket.timeout exception if the data still wasn't sent. This is with Python 2.3.2-1 on Windows 98. On Linux, it works as expected. Bug 805194 might be related. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-05 08:37 Message: Logged In: YES user_id=11105 Sorry, no time for this now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836058&group_id=5470 From noreply at sourceforge.net Wed Nov 5 07:52:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 07:52:31 2003 Subject: [Python-bugs-list] [ python-Bugs-836293 ] email generator can give bad output Message-ID: Bugs item #836293, was opened at 2003-11-05 01:26 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836293&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Draper (crunch) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email generator can give bad output Initial Comment: #!/usr/bin/env python #Feedback to crunch@shopip.com #Python 2.3.2 under OpenBSD 3.4 i386 import email print r""" Example of Python email generator bug. If a MIME message is missing the terminating line, the generator creates one for it -only it forgets to add the \n\n to it. This causes the following message to be concatenated to the first. """ #s1 is MIME missing terminating line; #s2 is a proper MIME message. s1="""Received: by spameater (127.0.0.1)... From: "Victor Virus" To: Subject: Unterminated MIME to corrupt your mbox! MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="xxxx" --xxxx Content-Type: text/plain; This is an unterminated MIME, like many viruses generate. I don't care about rights of viruses, but I do care if improper handling of MIME causes following messages to be lost. --xxxx """ s2=s1+"""--xxxx--\n\n""" #Create properly terminator msg1=email.message_from_string(s1) msg2=email.message_from_string(s2) print str(msg1)+str(msg2) print "p.s. Notice how the first message runs into the" print " second message." print " By adding the missing '--', this won't happen." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836293&group_id=5470 From noreply at sourceforge.net Wed Nov 5 09:24:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 09:26:37 2003 Subject: [Python-bugs-list] [ python-Bugs-836515 ] Windows installer 2.3.2 leaves old version in control panel Message-ID: Bugs item #836515, was opened at 2003-11-05 14: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=836515&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Heiko Selber (drhok) Assigned to: Thomas Heller (theller) Summary: Windows installer 2.3.2 leaves old version in control panel Initial Comment: I installed Python 2.3.2 (Python-2.3.2-1.exe) over 2.3 on WinXP. I assumed that this removes Python 2.3, but aside from Python 2.3.2, the software section of the control panel still has a (stale?) reference to Python 2.3. When I try to remove 2.3, I get a dialog saying that 2.3.2 is about to be removed. This looks inconsistent. Perhaps some cleanup is missing in the installation procedure? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836515&group_id=5470 From noreply at sourceforge.net Wed Nov 5 15:30:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 15:31:36 2003 Subject: [Python-bugs-list] [ python-Bugs-835353 ] logging.StreamHandler encodes log message in UTF-8 Message-ID: Bugs item #835353, was opened at 2003-11-03 23:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835353&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Vaclav Dvorak (vdvo) Assigned to: Nobody/Anonymous (nobody) Summary: logging.StreamHandler encodes log message in UTF-8 Initial Comment: For some reason that I do not see, logging.StreamHandler in Python 2.3 insists on writing plain non-Unicode strings to the stream, and the encoding is hard-coded as UTF-8: if not hasattr(types, "UnicodeType"): #if no unicode support... self.stream.write("%s\n" % msg) else: try: self.stream.write("%s\n" % msg) except UnicodeError: self.stream.write("%s\n" % msg.encode("UTF-8")) This behaviour is neither documented nor reasonable. Files can be perfectly able to write Unicode strings (e.g., through the use of codecs.EncodedFile or with a default encoding of sys.stdout), and even if they are not, UTF-8 is hardly the only choice for an encoding. I propose to simply replace the above code with: self.stream.write(msg) self.stream.write("\n") ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-05 21:30 Message: Logged In: YES user_id=21627 That would be an incompatible change, of course, as you then may get encoding errors where you currently get none. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835353&group_id=5470 From noreply at sourceforge.net Wed Nov 5 15:28:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 15:31:48 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-04 21:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: M.-A. Lemburg (lemburg) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-05 21:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Wed Nov 5 15:40:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 15:41:27 2003 Subject: [Python-bugs-list] [ python-Bugs-836769 ] file.readfile(filename, mode) Message-ID: Bugs item #836769, was opened at 2003-11-05 12: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=836769&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Manny (mssf) Assigned to: Nobody/Anonymous (nobody) Summary: file.readfile(filename, mode) Initial Comment: The idea is to provide a shortcut for: f = file(filename, mode) d = f.read() f.close() by adding a 'static' function to the builtin file class The above code would replaced with something like: d = file.readfile(filename, mode) mode could either accept the same values as the file constructor, i.e. 'r', 'rt', 'rb', or simply 'b' or 't' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836769&group_id=5470 From noreply at sourceforge.net Wed Nov 5 16:11:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 16:12:54 2003 Subject: [Python-bugs-list] [ python-Bugs-836769 ] file.readfile(filename, mode) Message-ID: Bugs item #836769, was opened at 2003-11-05 12:40 Message generated for change (Settings changed) made by mssf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836769&group_id=5470 Category: Python Library Group: Feature Request >Status: Deleted Resolution: None Priority: 5 Submitted By: mssf (mssf) Assigned to: Nobody/Anonymous (nobody) Summary: file.readfile(filename, mode) Initial Comment: The idea is to provide a shortcut for: f = file(filename, mode) d = f.read() f.close() by adding a 'static' function to the builtin file class The above code would replaced with something like: d = file.readfile(filename, mode) mode could either accept the same values as the file constructor, i.e. 'r', 'rt', 'rb', or simply 'b' or 't' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836769&group_id=5470 From noreply at sourceforge.net Wed Nov 5 17:03:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 17:03:40 2003 Subject: [Python-bugs-list] [ python-Bugs-805200 ] _tkinter compilation fails Message-ID: Bugs item #805200, was opened at 2003-09-12 12:13 Message generated for change (Comment added) made by robinf1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Samson Abramsky (bobrowski) Assigned to: Nobody/Anonymous (nobody) Summary: _tkinter compilation fails Initial Comment: Building Python 2.3 on Linux. At make stage: _tkinter compilation fails: libtk8.4.so no such file of directory with gcc arguments -L/usr/local/lib -ltk8.4 However, /usr/local/lib/libtk8.4.so does exist.! ---------------------------------------------------------------------- Comment By: Robin Friedrich (robinf1) Date: 2003-11-05 16:03 Message: Logged In: YES user_id=404550 I'm seeing this same link error. Python 2.3.2 / Red Hat Linux 7.3. I configure tcl/tk with a --prefix in configure and install. Works. I configure Python with same prefix; build fails to link saying it can't find libtk8.4.so when it indeed there. (the link line has the right -L and -l) For comparison I build a clean Python 2.2.3 from scratch with the same configure options and it compiled/linked/installed fine against this same exact .so. PS> Is LD_LIBRARY_PATH really necessary? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-09-12 13:35 Message: Logged In: YES user_id=33168 Are you sure libtk8.4.so isn't a sym link to a non-existent file? Is /usr/local/lib configured in ld.so? Is LD_LIBRARY_PATH set properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470 From noreply at sourceforge.net Wed Nov 5 17:45:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 5 17:45:20 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-05 09:49 Message generated for change (Comment added) made by tim_evans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode Group: Not a Bug >Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: M.-A. Lemburg (lemburg) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: Tim Evans (tim_evans) Date: 2003-11-06 11:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 09:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Thu Nov 6 03:09:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 03:09:56 2003 Subject: [Python-bugs-list] [ python-Bugs-837046 ] pyport.h redeclares gethostname() if SOLARIS is defined Message-ID: Bugs item #837046, was opened at 2003-11-06 09: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=837046&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Bostock (jbostock) Assigned to: Nobody/Anonymous (nobody) Summary: pyport.h redeclares gethostname() if SOLARIS is defined Initial Comment: The file pyport.h contains the lines: #ifdef SOLARIS /* Unchecked */ extern int gethostname(char *, int); #endif However, Solaris already defines gethostname() in /usr/include/unistd.h [I only have access to Solaris 2.6 and 2.8 so I can't vouch for other versions]. This in iteself is not a problem. However, under Python2.3, pyconfig.h defines _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED which cause (indirectly) the following prototype to be selected from unitstd.h: extern int gethostname(char *, size_t); Since size_t is an unsigned char, a compiler error message is generated (both by the native compiler and gcc) saying that the function has been redefined. This means that no python program can be compiled if SOLARIS is #defined. I imagine that the above code from pyport.h is only applicable to an earlier version of Solaris than 2.6, and so should either be removed or qualified somehow. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837046&group_id=5470 From noreply at sourceforge.net Thu Nov 6 03:53:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 03:53:59 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-04 21:49 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode Group: Not a Bug Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) >Assigned to: Nobody/Anonymous (nobody) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-06 09:53 Message: Logged In: YES user_id=38388 Tim, there's nothing much we can do about this since the strftime() API is a direct interface to the underlying C lib API. Python simply passes through the arguments to this function and returns whatever teh C lib has to offer. Please refer to the C lib documentation for your platform for details about the encoding being used for the strings. BTW, a simpe table with the month names in your application should nicely solve your problem; addtitionally it gives you full control ove the encoding and wording being used. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-05 23:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-05 21:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Thu Nov 6 09:55:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 09:55:12 2003 Subject: [Python-bugs-list] [ python-Bugs-579116 ] pthread_exit missing in thread_pthread.h Message-ID: Bugs item #579116, was opened at 2002-07-09 08:45 Message generated for change (Comment added) made by vpogrebi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 Category: Threads Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Michael Pronath (micpro) Assigned to: Nobody/Anonymous (nobody) Summary: pthread_exit missing in thread_pthread.h Initial Comment: I'm using the Python 2.2.1 interpreter for scripting language in a larger program. When I used the threading module to create new threads, my main program did not exit anymore, but hang, because one python thread always remained. It got much better when I inserted a call to pthread_exit into do_PyThread_exit_thread (thread_pthread.h). Patchfile is attached. ---------------------------------------------------------------------- Comment By: Valeriy Pogrebitskiy (vpogrebi) Date: 2003-11-06 09:55 Message: Logged In: YES user_id=902722 I'm using Python 2.2.1 (Unix) in a daemon process that starts child threads to handle specific events. I have noticed that occasionally (not all the time) child thread "stays" (in a SLEEPING) status after thread exits. When this happens, that thread never exits until entire process is stopped. I have log files that have output coming from threading module (I have set threading._VERBOSE to 1) that show each thread's start and termination events. In addition, I use Queue module for inter-thread communication (when thread starts execution, it posts "START" message, and when it is about to exit its run() method, it posts "END" event). So, from these logs and from output of "ps -fp - o 'user,pid,ppid,pgid,time,stime,lwp,s'" I can see that some threads exit (which is indicated by _VERBOSE output and a message in a Queue), but still stay (in a SLEEPING state) in the process. Does this behavior have something to do with the problem described in this report, or is it something different? Is there patch (full instalation package) that fixes this problem (without me having to update source code and recompile the executable)? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:08 Message: Logged In: YES user_id=33168 Michael do you still have this problem with 2.2.2 or do you still require this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 From noreply at sourceforge.net Thu Nov 6 09:59:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 09:59:17 2003 Subject: [Python-bugs-list] [ python-Bugs-837228 ] Python.h must be included first Message-ID: Bugs item #837228, was opened at 2003-11-06 09: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=837228&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 7 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Python.h must be included first Initial Comment: Both the API reference and the Extending and Embedding doc need to scream louder about the requirement to #include Python.h first. Should be fixed for all maintained versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837228&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:03:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:03:49 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:05:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:05:38 2003 Subject: [Python-bugs-list] [ python-Bugs-837234 ] Tk.quit and sys.exit cause Fatal Error Message-ID: Bugs item #837234, was opened at 2003-11-06 22:05 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=837234&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Martin v. L?wis (loewis) Summary: Tk.quit and sys.exit cause Fatal Error Initial Comment: Fatal Python error: PyEval_RestoreThread: NULL tstate I get this if I do a sys.exit() or a Tkinter quit() from with an after call or from capturing an input event. HOWEVER, if I capture a event and then call quit(), everything works fine! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837234&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:11:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:11:50 2003 Subject: [Python-bugs-list] [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-07 02:11 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=837242&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:12:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:12:20 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Settings changed) made by mdornseif You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 >Category: Extension Modules >Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:25:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:25:46 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-07 02:03 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-07 02:25 Message: Logged In: YES user_id=29957 If you strip the test down further, which bits are necessary for the leak? Is the full socket()/connect()/send()/recv()/shutdown()/close() set needed? What about just socket()/connect()/close() ? Or just creating and del of the sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:27:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:27:27 2003 Subject: [Python-bugs-list] [ python-Bugs-837234 ] Tk.quit and sys.exit cause Fatal Error Message-ID: Bugs item #837234, was opened at 2003-11-06 22:05 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837234&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Martin v. L?wis (loewis) Summary: Tk.quit and sys.exit cause Fatal Error Initial Comment: Fatal Python error: PyEval_RestoreThread: NULL tstate I get this if I do a sys.exit() or a Tkinter quit() from with an after call or from capturing an input event. HOWEVER, if I capture a event and then call quit(), everything works fine! ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-11-06 22:27 Message: Logged In: YES user_id=22406 Ah! Calling destroy works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837234&group_id=5470 From noreply at sourceforge.net Thu Nov 6 10:35:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 10:35:50 2003 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-23 09:07 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Anthony Baxter (anthonybaxter) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-07 02:35 Message: Logged In: YES user_id=29957 I'll fix this for 2.3.3, because it causes test failures on the HP testdrive boxes, and that annoys me . ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-08-31 03:28 Message: Logged In: YES user_id=89016 Now that 2.3 is out the door, should this be checked in? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 13:01 Message: Logged In: YES user_id=12800 Thanks Jean for the independent verification. We'll fix this for Python 2.3.1. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 09:24 Message: Logged In: YES user_id=832557 The '+ ...' line at the end of the /etc/passwd file tells the system to also pickup information from the appropriate map in LDAP, or NIS (yellow pages). See also section 7.2 on this page: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-29 07:56 Message: Logged In: YES user_id=33168 I don't recall what the + is for either. Does it have something to do with YP/NIS? I don't think this is really critical so I'm droping the priority. If pwdmodule.c is changed, it will be an interface change so it's questionable for 2.3.1. This was found on the snake farm, never reported by a user. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-07-29 04:36 Message: Logged In: YES user_id=89016 pwdmodule.c hasn't changed in 7 months, so I'd say this is a problem with the test. But ('+', None, 0, []) doesn't seem to be a valid entry, so (although it's not a bug in Python) maybe Python should hide this entry. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 02:22 Message: Logged In: YES user_id=12800 Remind me what + on a line means in /etc/group. "man group" on RH9 gives no clue. I'm still nervous about it, can we defer until 2.3.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply at sourceforge.net Thu Nov 6 15:54:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 15:54:51 2003 Subject: [Python-bugs-list] [ python-Bugs-837242 ] id() for large ptr should return a long Message-ID: Bugs item #837242, was opened at 2003-11-06 16:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: id() for large ptr should return a long Initial Comment: Under something like Redhat 10 the address space is messed about with to "prevent stack smash attacks" or some such. This means that you sometimes get addresses in the high half of a 32 bit int. Since Python ints are signed, this means we return a negative number from id(). For 2.4, we should probably return a long. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:54 Message: Logged In: YES user_id=21627 Would there anything be wrong with making that change right away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837242&group_id=5470 From noreply at sourceforge.net Thu Nov 6 15:52:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 15:57:02 2003 Subject: [Python-bugs-list] [ python-Bugs-834676 ] segfault in unicodedata module (hangul syllables) Message-ID: Bugs item #834676, was opened at 2003-11-02 20:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Martin v. L?wis (loewis) Summary: segfault in unicodedata module (hangul syllables) Initial Comment: [forwarded from http://bugs.debian.org/218697] start an interactive python2.3 interpreter. run the following command, twice if necessary: __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') this reliably segfaults python2.3 on both i686 and powerpc. although my testing has not been very extensive (unicode is somewhat large and slightly complex,) so far i have seen the crash only when processing pre-composed hangul syllables. decomposing them into combining jamos before calling unicodedata.normalize seems to avoid the crash, and i've included a wrapper that does just that in this report. unfortunately, this method is used internally by encodings.idna, so this means processing some internationalized korean domain names can likely crash any python program with support for internationalized domain names. please do let me know if you would like more details, or if there's anything further i can do to help! workaround: as a workaround in my own python programs, i wrapped unicodedata.normalize like this (see attachment). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:52 Message: Logged In: YES user_id=21627 This is now fixed in test_normalization.py 1.9 unicodedata.c 2.29 test_normalization.py 1.7.8.2 NEWS 1.831.4.73 unicodedata.c 2.28.10.1 As an alternative work-around, adding three extra space characters before normalization, and removing them afterwards should also reliably avoid the crash. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-03 16:17 Message: Logged In: YES user_id=33168 Here's some more info, hope it helps. >>> __import__('unicodedata').normalize('NFC',u'\ud55c\uae00') Debug memory block at address p=0x402ac410: 20 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x402ac424 are not all FORBIDDENBYTE (0xfb): at tail+0: 0xaf *** OUCH at tail+1: 0x11 *** OUCH at tail+2: 0x00 *** OUCH at tail+3: 0x00 *** OUCH The block was made by call #19688 to debug malloc/realloc. Data at p: 12 11 00 00 61 11 00 00 ... 00 11 00 00 73 11 00 00 Fatal Python error: bad trailing pad byte #7 0x08082a7c in _PyObject_DebugRealloc (p=0x402ac410, nbytes=28) at Objects/obmalloc.c:1038 #8 0x0809f1b7 in unicode_resize (unicode=0x40299988, length=6) at Objects/unicodeobject.c:150 #9 0x0809f6da in PyUnicodeUCS4_Resize (unicode=0xbffff4bc, length=6) at Objects/unicodeobject.c:298 #10 0x405d702e in nfd_nfkd (input=0x40299928, k=0) at /home/neal/build/python/2_3/Modules/unicodedata.c:356 #11 0x405d7233 in nfc_nfkc (input=0x40299928, k=0) at /home/neal/build/python/2_3/Modules/unicodedata.c:412 #12 0x405d7616 in unicodedata_normalize (self=0x0, args=0x4052522c) at /home/neal/build/python/2_3/Modules/unicodedata.c:517 #13 0x0810a182 in PyCFunction_Call (func=0x4052553c, arg=0x4052522c, kw=0x0) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-03 11:09 Message: Logged In: YES user_id=38388 Martin wrote this part. Assigning to him. ---------------------------------------------------------------------- Comment By: Benjamin C. W. Sittler (bsittler) Date: 2003-11-02 21:21 Message: Logged In: YES user_id=645359 fyi, i ran into this while adding an encoding similar to IDNA [i believe it's an IDNA superset], but capable of handling free text -- see http://xent.com/~bsittler/icb_ace.py -- and my very first test data was the word 한글, written in precomposed form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834676&group_id=5470 From noreply at sourceforge.net Thu Nov 6 15:56:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 15:57:05 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:56 Message: Logged In: YES user_id=21627 What is a KQUEUE entry, and why do you think there is a bug in Python (rather than in FreeBSD 5.1)? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-06 16:25 Message: Logged In: YES user_id=29957 If you strip the test down further, which bits are necessary for the leak? Is the full socket()/connect()/send()/recv()/shutdown()/close() set needed? What about just socket()/connect()/close() ? Or just creating and del of the sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Thu Nov 6 16:00:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 16:00:57 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-05 09:49 Message generated for change (Comment added) made by tim_evans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode Group: Not a Bug Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: Nobody/Anonymous (nobody) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: Tim Evans (tim_evans) Date: 2003-11-07 10:00 Message: Logged In: YES user_id=561705 The windows C lib docs say that calling mbstowcs on the output of strftime (or calling wcsftime instead of strftime) will return the correct wide-character (utf-16?) string. This produces something that looks like it could be correct. Decoding with the 'mbcs' encoding in Python is not equivalent to calling mbstowcs because mbstowcs is locale-dependent. Perhaps it would be a good idea to have time.strftime return a unicode string. As this wouldn't be backward compatible, it could be done via a new function time.ustrftime, or via an optional unicode=True argument to the existing function. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-06 21:53 Message: Logged In: YES user_id=38388 Tim, there's nothing much we can do about this since the strftime() API is a direct interface to the underlying C lib API. Python simply passes through the arguments to this function and returns whatever teh C lib has to offer. Please refer to the C lib documentation for your platform for details about the encoding being used for the strings. BTW, a simpe table with the month names in your application should nicely solve your problem; addtitionally it gives you full control ove the encoding and wording being used. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 11:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 09:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Thu Nov 6 16:33:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 16:33:32 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-04 21:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode Group: Not a Bug Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: Nobody/Anonymous (nobody) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 22:33 Message: Logged In: YES user_id=21627 Is there any way to find out the encoding that mbstowcs uses? ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 22:00 Message: Logged In: YES user_id=561705 The windows C lib docs say that calling mbstowcs on the output of strftime (or calling wcsftime instead of strftime) will return the correct wide-character (utf-16?) string. This produces something that looks like it could be correct. Decoding with the 'mbcs' encoding in Python is not equivalent to calling mbstowcs because mbstowcs is locale-dependent. Perhaps it would be a good idea to have time.strftime return a unicode string. As this wouldn't be backward compatible, it could be done via a new function time.ustrftime, or via an optional unicode=True argument to the existing function. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-06 09:53 Message: Logged In: YES user_id=38388 Tim, there's nothing much we can do about this since the strftime() API is a direct interface to the underlying C lib API. Python simply passes through the arguments to this function and returns whatever teh C lib has to offer. Please refer to the C lib documentation for your platform for details about the encoding being used for the strings. BTW, a simpe table with the month names in your application should nicely solve your problem; addtitionally it gives you full control ove the encoding and wording being used. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-05 23:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-05 21:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Thu Nov 6 17:21:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 17:21:32 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-05 09:49 Message generated for change (Comment added) made by tim_evans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode Group: Not a Bug Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: Nobody/Anonymous (nobody) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: Tim Evans (tim_evans) Date: 2003-11-07 11:21 Message: Logged In: YES user_id=561705 I have looked at the source code for the MS C library (it comes with VC++6) and I believe that that something equivalent to the following is used: char codepage[16]; GetLocaleInfo( GetThreadLocale(), LOCALE_IDEFAULTANSICODEPAGE, codepage, 16); This returns "1252" for "C" locale, and for the chinese locale that I was expirmenting with it returns "936". Python does not have an encoding "cp936", but from C the conversion with an explicit codepage produces the same results as mbstwcs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-07 10:33 Message: Logged In: YES user_id=21627 Is there any way to find out the encoding that mbstowcs uses? ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-07 10:00 Message: Logged In: YES user_id=561705 The windows C lib docs say that calling mbstowcs on the output of strftime (or calling wcsftime instead of strftime) will return the correct wide-character (utf-16?) string. This produces something that looks like it could be correct. Decoding with the 'mbcs' encoding in Python is not equivalent to calling mbstowcs because mbstowcs is locale-dependent. Perhaps it would be a good idea to have time.strftime return a unicode string. As this wouldn't be backward compatible, it could be done via a new function time.ustrftime, or via an optional unicode=True argument to the existing function. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-06 21:53 Message: Logged In: YES user_id=38388 Tim, there's nothing much we can do about this since the strftime() API is a direct interface to the underlying C lib API. Python simply passes through the arguments to this function and returns whatever teh C lib has to offer. Please refer to the C lib documentation for your platform for details about the encoding being used for the strings. BTW, a simpe table with the month names in your application should nicely solve your problem; addtitionally it gives you full control ove the encoding and wording being used. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 11:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 09:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Thu Nov 6 18:11:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 6 18:11:17 2003 Subject: [Python-bugs-list] [ python-Bugs-837577 ] cryptic os.spawnvpe() return code Message-ID: Bugs item #837577, was opened at 2003-11-06 23:11 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=837577&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Clinton Roy (clintonroy) Assigned to: Nobody/Anonymous (nobody) Summary: cryptic os.spawnvpe() return code Initial Comment: Hellos, If a non string value is passed along in an environment mapping to os.spawnvpe() it cryptically returns 127, which doesn't help discover the problem at all. I think an exception should be raised, much like attempting to set something in os.environ to a non string. thanks, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837577&group_id=5470 From noreply at sourceforge.net Fri Nov 7 02:26:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 02:26:40 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Comment added) made by mdornseif You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- >Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 08:26 Message: Logged In: YES user_id=554460 Martin: KQUEUES are used by FreeBSD for event Notification like / dev/poll on Linux. KQUEUES are exposed to the userland and can used for efficient non-blocking I/O - there is even a Python module for them. See http://people.freebsd.org/~jmg/kqueue.man.html for further enlightenment. To my understanding Python 2.3 itself ignores KQUEUES completely. I SUSPECT FreeBSD 5 maps select and poll internally to code using KQUEUES. Is this a Bug in FreeBSD? May be. But they will ask for a test program (in C) and I was not able to reproduce the problem in C or Perl. I also have found only one other mention of this problem and this was related to ntop which is doing all kind of funky stuff with your network; it also seemed they where not able to reproduce the problem. So I think - as usual - the userland code has to work around bugs (Features?) in the kernel space. Especially since we (pythoneers) changed something between 2.2 and 2.3 which exposed the problem. Anthony: I have only limited access to the FreeBSD 5.1. machine today, but it seems even socket().connect(); del results in the leak while socket(); del does not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:56 Message: Logged In: YES user_id=21627 What is a KQUEUE entry, and why do you think there is a bug in Python (rather than in FreeBSD 5.1)? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-06 16:25 Message: Logged In: YES user_id=29957 If you strip the test down further, which bits are necessary for the leak? Is the full socket()/connect()/send()/recv()/shutdown()/close() set needed? What about just socket()/connect()/close() ? Or just creating and del of the sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Fri Nov 7 04:43:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 04:43:17 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Comment added) made by mdornseif You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- >Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 10:43 Message: Logged In: YES user_id=554460 It turs out, the same happens on scceptiong sockets. I have just looked into an xmlrpc server: def submit_new_urls(uid, l): fn = os.path.join(destdir, "%s.newurls" % (uid)) fd = open("%s.tmp" % fn, "w") fd.write("\n".join(l)) fd.close() return "Ok" server = SimpleXMLRPCServer(("example.com", 8000)) server.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 0) server.register_function(submit_new_urls) server.serve_forever() same problem. I will try to build a striped down test to demonstrate the problem. ---------------------------------------------------------------------- Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 08:26 Message: Logged In: YES user_id=554460 Martin: KQUEUES are used by FreeBSD for event Notification like / dev/poll on Linux. KQUEUES are exposed to the userland and can used for efficient non-blocking I/O - there is even a Python module for them. See http://people.freebsd.org/~jmg/kqueue.man.html for further enlightenment. To my understanding Python 2.3 itself ignores KQUEUES completely. I SUSPECT FreeBSD 5 maps select and poll internally to code using KQUEUES. Is this a Bug in FreeBSD? May be. But they will ask for a test program (in C) and I was not able to reproduce the problem in C or Perl. I also have found only one other mention of this problem and this was related to ntop which is doing all kind of funky stuff with your network; it also seemed they where not able to reproduce the problem. So I think - as usual - the userland code has to work around bugs (Features?) in the kernel space. Especially since we (pythoneers) changed something between 2.2 and 2.3 which exposed the problem. Anthony: I have only limited access to the FreeBSD 5.1. machine today, but it seems even socket().connect(); del results in the leak while socket(); del does not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:56 Message: Logged In: YES user_id=21627 What is a KQUEUE entry, and why do you think there is a bug in Python (rather than in FreeBSD 5.1)? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-06 16:25 Message: Logged In: YES user_id=29957 If you strip the test down further, which bits are necessary for the leak? Is the full socket()/connect()/send()/recv()/shutdown()/close() set needed? What about just socket()/connect()/close() ? Or just creating and del of the sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Fri Nov 7 10:11:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 10:11:28 2003 Subject: [Python-bugs-list] [ python-Bugs-837929 ] socket.gethostbyname raises gaierror, not herror Message-ID: Bugs item #837929, was opened at 2003-11-07 16:11 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=837929&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyname raises gaierror, not herror Initial Comment: http://www.python.org/doc/current/lib/module-socket.html states that socket.gethostbyaddr() raises herror if the host isn't found. That isn't true in Python 2.3.2: Python 2.3.2 (#1, Oct 5 2003, 12:10:05) [GCC 3.3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import socket >>> socket.gethostbyname('finnsinte.ingate.se') Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-2, 'Name or service not known') >>> Also, the description of gaierror should mention that the error value is set to one of the socket.EAI_* constants. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837929&group_id=5470 From noreply at sourceforge.net Fri Nov 7 13:56:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 13:56:46 2003 Subject: [Python-bugs-list] [ python-Bugs-836035 ] strftime month name is encoded somehow Message-ID: Bugs item #836035, was opened at 2003-11-04 21:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 Category: Unicode Group: Not a Bug Status: Open Resolution: Invalid Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: Nobody/Anonymous (nobody) Summary: strftime month name is encoded somehow Initial Comment: On Windows XP, with some locales the month name returned by time.strftime('%B') is encoded somehow. For example: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> time.strftime('%B') '\xca\xae\xd2\xbb\xd4\xc2' >>> time.strftime('%d %B %Y') '05 \xca\xae\xd2\xbb\xd4\xc2 2003' >>> locale.setlocale(locale.LC_ALL, '') 'French_France.1252' >>> time.strftime('%B', (2003,12,1,0,0,0,0,0,0)) 'd\xe9cembre' I'm not sure what encoding the Chinese version is using, but the French is compatible with latin-1. It would appear that the encoding used is locale-dependent. Ideally, the win32 version of time.strftime would call the wide-character version of strftime (called wcsftime) and return a unicode object. I haven't looked at what this does under any other operating system. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-07 19:56 Message: Logged In: YES user_id=21627 This tells me that we need a function to return the current locale's code page; this should return "cp936" in your case. The fact that Python does not have a codec for cp936 is an independent issue. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 23:21 Message: Logged In: YES user_id=561705 I have looked at the source code for the MS C library (it comes with VC++6) and I believe that that something equivalent to the following is used: char codepage[16]; GetLocaleInfo( GetThreadLocale(), LOCALE_IDEFAULTANSICODEPAGE, codepage, 16); This returns "1252" for "C" locale, and for the chinese locale that I was expirmenting with it returns "936". Python does not have an encoding "cp936", but from C the conversion with an explicit codepage produces the same results as mbstwcs. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 22:33 Message: Logged In: YES user_id=21627 Is there any way to find out the encoding that mbstowcs uses? ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-06 22:00 Message: Logged In: YES user_id=561705 The windows C lib docs say that calling mbstowcs on the output of strftime (or calling wcsftime instead of strftime) will return the correct wide-character (utf-16?) string. This produces something that looks like it could be correct. Decoding with the 'mbcs' encoding in Python is not equivalent to calling mbstowcs because mbstowcs is locale-dependent. Perhaps it would be a good idea to have time.strftime return a unicode string. As this wouldn't be backward compatible, it could be done via a new function time.ustrftime, or via an optional unicode=True argument to the existing function. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-06 09:53 Message: Logged In: YES user_id=38388 Tim, there's nothing much we can do about this since the strftime() API is a direct interface to the underlying C lib API. Python simply passes through the arguments to this function and returns whatever teh C lib has to offer. Please refer to the C lib documentation for your platform for details about the encoding being used for the strings. BTW, a simpe table with the month names in your application should nicely solve your problem; addtitionally it gives you full control ove the encoding and wording being used. ---------------------------------------------------------------------- Comment By: Tim Evans (tim_evans) Date: 2003-11-05 23:45 Message: Logged In: YES user_id=561705 I'm reopening the bug, because that doesn't seem to work: >>> import time, locale >>> locale.setlocale(locale.LC_ALL, '') "Chinese_People's Republic of China.936" >>> x = time.strftime('%B') >>> x '\xca\xae\xd2\xbb\xd4\xc2' >>> x.decode('mbcs') '\xca\xae\xd2\xbb\xd4\xc2' >>> locale.getpreferredencoding() 'cp1252' >>> x.decode('cp1252') '\xca\xae\xd2\xbb\xd4\xc2' The preferred encoding is returned as cp1252, which can't be correct. And niether cp1252 nor mbcs appear to decode the string into anything containing the high-numbered characters I would expect for chinese (neither of them changes the string at all). The following problems (may) exist: 1. locale.getpreferredencoding() doesn't work. 2. The string return by time.strftime() is not mbcs encoded. 3. The documentation for time.strftime() doesn't say how the string is encoded. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-05 21:28 Message: Logged In: YES user_id=21627 It always contains a byte string in the locale's encoding; for compatibility, this cannot be changed. On Windows, you can access the encoding as "mbcs". In general, you need to use locale.getpreferredencoding() to find out what encoding this string is in. Closing as not-a-bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836035&group_id=5470 From noreply at sourceforge.net Fri Nov 7 14:01:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 14:02:00 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-07 20:01 Message: Logged In: YES user_id=21627 Working around system bugs is not usual for Python, and I would do so only if there was a clearly-documented bug of the system, and a reliable way for testing for the bug's presence. In the particular case of FreeBSD 5.1, I'm tempted to say "tough luck", as the system is not considered ready for production use by its developers. That said: Please try to produce an strace/truss/ktrace/whatever trace created when running the Python program. There shouldn't be a need to have 500 repetitions - the leak of resources should occur in a single repetition. ---------------------------------------------------------------------- Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 10:43 Message: Logged In: YES user_id=554460 It turs out, the same happens on scceptiong sockets. I have just looked into an xmlrpc server: def submit_new_urls(uid, l): fn = os.path.join(destdir, "%s.newurls" % (uid)) fd = open("%s.tmp" % fn, "w") fd.write("\n".join(l)) fd.close() return "Ok" server = SimpleXMLRPCServer(("example.com", 8000)) server.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 0) server.register_function(submit_new_urls) server.serve_forever() same problem. I will try to build a striped down test to demonstrate the problem. ---------------------------------------------------------------------- Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 08:26 Message: Logged In: YES user_id=554460 Martin: KQUEUES are used by FreeBSD for event Notification like / dev/poll on Linux. KQUEUES are exposed to the userland and can used for efficient non-blocking I/O - there is even a Python module for them. See http://people.freebsd.org/~jmg/kqueue.man.html for further enlightenment. To my understanding Python 2.3 itself ignores KQUEUES completely. I SUSPECT FreeBSD 5 maps select and poll internally to code using KQUEUES. Is this a Bug in FreeBSD? May be. But they will ask for a test program (in C) and I was not able to reproduce the problem in C or Perl. I also have found only one other mention of this problem and this was related to ntop which is doing all kind of funky stuff with your network; it also seemed they where not able to reproduce the problem. So I think - as usual - the userland code has to work around bugs (Features?) in the kernel space. Especially since we (pythoneers) changed something between 2.2 and 2.3 which exposed the problem. Anthony: I have only limited access to the FreeBSD 5.1. machine today, but it seems even socket().connect(); del results in the leak while socket(); del does not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:56 Message: Logged In: YES user_id=21627 What is a KQUEUE entry, and why do you think there is a bug in Python (rather than in FreeBSD 5.1)? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-06 16:25 Message: Logged In: YES user_id=29957 If you strip the test down further, which bits are necessary for the leak? Is the full socket()/connect()/send()/recv()/shutdown()/close() set needed? What about just socket()/connect()/close() ? Or just creating and del of the sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Fri Nov 7 15:44:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 15:44:36 2003 Subject: [Python-bugs-list] [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 15:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Fri Nov 7 15:47:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 7 15:47:44 2003 Subject: [Python-bugs-list] [ python-Bugs-838144 ] PackageManager does not clean up after itself Message-ID: Bugs item #838144, was opened at 2003-11-07 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838144&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager does not clean up after itself Initial Comment: This was discussed on-list, but PackageManager downloads files to /tmp, but never removes them. Documentation should at least mention this, perhaps also on the MacPython page. I will add this information to the pythonmac.org wiki as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838144&group_id=5470 From noreply at sourceforge.net Sat Nov 8 03:18:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 03:19:34 2003 Subject: [Python-bugs-list] [ python-Bugs-837231 ] Python 2.3 socketmodule breaks on FreeBSD 5.1 Message-ID: Bugs item #837231, was opened at 2003-11-06 16:03 Message generated for change (Comment added) made by mdornseif You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 7 Submitted By: Maximillian Dornseif (mdornseif) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3 socketmodule breaks on FreeBSD 5.1 Initial Comment: Every outbound socket created leaves a KQUEUE entry in the filetable which leads to a "out of ffiledescriport" problem dor long running programs or ones that do many connections. I can reproduce this behaviour with Python 2.3 and 2.3.2 on FreeBSD 5.1. I have also tested 2.2.3 on FreeBSD 5.1 and 2.3.2 on FreeBSD 4.9 which all were running fine. Example: import socket def test(): s = socket.socket() s.connect(('koeln.ccc.de', 80)) s.send('GET / HTTP/1.1\r\nHost: koeln.ccc.de\r\n\r\n') # I know, I get only len(MTU) s.recv(30000) s.shutdown(2) s.close() del s for i in range (500): test() While running this I see about 500 times following lines in lsof: python 82229 md 7u KQUEUE 0xc7d76e00 count=0, state=0 Some more documentation on my tests can be found at http://blogs.23.nu/c0re/stories/1626/ ---------------------------------------------------------------------- >Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-08 09:18 Message: Logged In: YES user_id=554460 Ouch. Seems it really IS a FreeBSD Bug. While python2.2 preformed yesterday as expected today it leaves KQUEUE entries, too. So now I have to try to reproduce this in C. Sorry for wasting your time, I'm closing this bug. (in case anybody is still interested: ktrace is available at http:// blogs.23.nu/c0re/stories/1626/#1632) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-07 20:01 Message: Logged In: YES user_id=21627 Working around system bugs is not usual for Python, and I would do so only if there was a clearly-documented bug of the system, and a reliable way for testing for the bug's presence. In the particular case of FreeBSD 5.1, I'm tempted to say "tough luck", as the system is not considered ready for production use by its developers. That said: Please try to produce an strace/truss/ktrace/whatever trace created when running the Python program. There shouldn't be a need to have 500 repetitions - the leak of resources should occur in a single repetition. ---------------------------------------------------------------------- Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 10:43 Message: Logged In: YES user_id=554460 It turs out, the same happens on scceptiong sockets. I have just looked into an xmlrpc server: def submit_new_urls(uid, l): fn = os.path.join(destdir, "%s.newurls" % (uid)) fd = open("%s.tmp" % fn, "w") fd.write("\n".join(l)) fd.close() return "Ok" server = SimpleXMLRPCServer(("example.com", 8000)) server.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 0) server.register_function(submit_new_urls) server.serve_forever() same problem. I will try to build a striped down test to demonstrate the problem. ---------------------------------------------------------------------- Comment By: Maximillian Dornseif (mdornseif) Date: 2003-11-07 08:26 Message: Logged In: YES user_id=554460 Martin: KQUEUES are used by FreeBSD for event Notification like / dev/poll on Linux. KQUEUES are exposed to the userland and can used for efficient non-blocking I/O - there is even a Python module for them. See http://people.freebsd.org/~jmg/kqueue.man.html for further enlightenment. To my understanding Python 2.3 itself ignores KQUEUES completely. I SUSPECT FreeBSD 5 maps select and poll internally to code using KQUEUES. Is this a Bug in FreeBSD? May be. But they will ask for a test program (in C) and I was not able to reproduce the problem in C or Perl. I also have found only one other mention of this problem and this was related to ntop which is doing all kind of funky stuff with your network; it also seemed they where not able to reproduce the problem. So I think - as usual - the userland code has to work around bugs (Features?) in the kernel space. Especially since we (pythoneers) changed something between 2.2 and 2.3 which exposed the problem. Anthony: I have only limited access to the FreeBSD 5.1. machine today, but it seems even socket().connect(); del results in the leak while socket(); del does not. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-06 21:56 Message: Logged In: YES user_id=21627 What is a KQUEUE entry, and why do you think there is a bug in Python (rather than in FreeBSD 5.1)? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-06 16:25 Message: Logged In: YES user_id=29957 If you strip the test down further, which bits are necessary for the leak? Is the full socket()/connect()/send()/recv()/shutdown()/close() set needed? What about just socket()/connect()/close() ? Or just creating and del of the sockets? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837231&group_id=5470 From noreply at sourceforge.net Sat Nov 8 06:36:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 06:37:03 2003 Subject: [Python-bugs-list] [ python-Bugs-835110 ] possible uninitialized variable in listobject.c:listsort Message-ID: Bugs item #835110, was opened at 2003-11-03 11:07 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835110&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Raymond Hettinger (rhettinger) Summary: possible uninitialized variable in listobject.c:listsort Initial Comment: GCC warns that the local variable n in listobject.c:listsort might be uninitialized. I'm not convinced that's the case, but it seems that n should only be declared once and should be initialized at that point to avoid confusion. It's both a variable local to listsort and a variable local to an embedded do/while loop. It's also not clear that the goto fail statement inside the do/while is correct. Do you intend for n to have the value set within the loop? I think when you get to the fail: label you'll see the outer n. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-08 06:36 Message: Logged In: YES user_id=80475 Fixed. See Objects/listobject.c 2.163 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835110&group_id=5470 From noreply at sourceforge.net Sat Nov 8 06:41:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 06:41:56 2003 Subject: [Python-bugs-list] [ python-Bugs-835457 ] Small typo in logging documentation Message-ID: Bugs item #835457, was opened at 2003-11-03 21:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835457&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lars Bj?nnes (larsbjonnes) Assigned to: Nobody/Anonymous (nobody) Summary: Small typo in logging documentation Initial Comment: >From logging/handlers.py, in class RotatingFileHandler(logging.FileHandler) def emit(self, record): ... Output the record to the file, catering for rollover as described in setRollover(). .... There is no method named setRollover() in the module, and I believe the author really meant doRollover(). (Just nitpicking; I was just browsing through the code when I noticed it.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-08 06:41 Message: Logged In: YES user_id=80475 Fixed. See Lib/logging/handlers.py 1.8 and 1.7.8.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835457&group_id=5470 From noreply at sourceforge.net Sat Nov 8 06:42:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 06:42:19 2003 Subject: [Python-bugs-list] [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) >Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Sat Nov 8 16:01:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 16:01:34 2003 Subject: [ python-Bugs-794819 ] Named groups limitation in sre Message-ID: Bugs item #794819, was opened at 2003-08-25 21:01 Message generated for change (Settings changed) made by lomby You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794819&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Pending Resolution: None >Priority: 4 Submitted By: Andrea Lombardoni (lomby) Assigned to: Fredrik Lundh (effbot) Summary: Named groups limitation in sre Initial Comment: In sre_compile.py line 473 stands: # XXX: get rid of this limitation! assert p.pattern.groups <= 100,\ "sorry, but this version only supports 100 named groups" In sre.h line 53: /* FIXME: shouldn't be a constant, really... */ #define SRE_MARK_SIZE 200 Small problem: the two numbers do not to match. Big problem: if this limitation cannot be eliminated (as suggested by the comments), I suggest setting SRE_MARK_SIZE of at least 1000. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794819&group_id=5470 From noreply at sourceforge.net Sat Nov 8 16:20:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 16:24:06 2003 Subject: [ python-Bugs-794819 ] Named groups limitation in sre Message-ID: Bugs item #794819, was opened at 2003-08-25 11:01 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794819&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Pending Resolution: None Priority: 4 Submitted By: Andrea Lombardoni (lomby) Assigned to: Fredrik Lundh (effbot) Summary: Named groups limitation in sre Initial Comment: In sre_compile.py line 473 stands: # XXX: get rid of this limitation! assert p.pattern.groups <= 100,\ "sorry, but this version only supports 100 named groups" In sre.h line 53: /* FIXME: shouldn't be a constant, really... */ #define SRE_MARK_SIZE 200 Small problem: the two numbers do not to match. Big problem: if this limitation cannot be eliminated (as suggested by the comments), I suggest setting SRE_MARK_SIZE of at least 1000. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-11-08 13:20 Message: Logged In: YES user_id=357491 Why was this changed to pending? Is Fredrik working on a fix? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794819&group_id=5470 From barry at python.org Sat Nov 8 12:22:04 2003 From: barry at python.org (Barry Warsaw) Date: Sat Nov 8 17:08:16 2003 Subject: Small change to python-bugs-list Message-ID: <1068312124.15995.204.camel@anthem> It seems pretty redundant for the subject header of messages to this list to have both the SF added [ python-Bugs-XXXXXX ] prefix and the [Python-bugs-list] prefix added by Mailman. I removed the latter. -Barry From andreyw at canoemail.com Mon Nov 3 10:22:13 2003 From: andreyw at canoemail.com (andreyw@canoemail.com) Date: Sat Nov 8 17:09:36 2003 Subject: btree set_location() in new bsddb module \python 2.3.2\ Message-ID: <88ADB9D183A29F64E8205A0830F3A41C@andreyw.canoemail.com> =========================== btree set_location() method does not work properly in new bsddb module. \ Python version 2.3.2 \ "...For binary tree databases (opened using btopen()), if key does not actually exist in the database, the cursor will point to the next item in sorted order and return that key and value." andreyw A. Weisberg @canoemail.com =========================== import bsddb mode = 0666 flag = 'n' file = 'bt_test.bsd' db = bsddb.btopen(file, flag, mode) db['a'] = 'aa' db['c'] = 'cc' print db.set_location('b') Traceback (most recent call last): File "C:\PYTHON23\lib\bsddb\__init__.py", line 147, in set_location return self.dbc.set(key) _bsddb.DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/data pair found') Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail From andreyw at canoemail.com Tue Nov 4 10:25:43 2003 From: andreyw at canoemail.com (andreyw@canoemail.com) Date: Sat Nov 8 17:09:39 2003 Subject: btree set_location() method does not work properly in new bsddb module. \ Python version 2.3.2 \ Message-ID: <607C10F9DEEC8794BA2B5765C38D8FC7@andreyw.canoemail.com> =========================== btree set_location() method does not work properly in new bsddb module. \ Python version 2.3.2 \ "...For binary tree databases (opened using btopen()), if key does not actually exist in the database, the cursor will point to the next item in sorted order and return that key and value." andreyw A. Weisberg @canoemail.com =========================== import bsddb mode = 0666 flag = 'n' file = 'bt_test.bsd' db = bsddb.btopen(file, flag, mode) db['c'] = 'cc' db['a'] = 'aa' print db.set_location('b') Traceback (most recent call last): File "C:\PYTHON23\lib\bsddb\__init__.py", line 147, in set_location return self.dbc.set(key) _bsddb.DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/data pair found') Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail From noreply at sourceforge.net Sat Nov 8 18:45:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 8 18:45:31 2003 Subject: [ python-Bugs-838616 ] MacPython for Panther additions includes IDLE Message-ID: Bugs item #838616, was opened at 2003-11-09 00: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=838616&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython for Panther additions includes IDLE Initial Comment: The second build of the MacPython for Panther additions includes the IDLE applet. But it doesn't work (because _tkinter and AquaTclTk aren't installed). This should be fixed in the next installer. Moreover, it would be nice if there was something in place to do a quick sanity check of installers (MANIFEST files with comparison to the previous installer?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838616&group_id=5470 From noreply at sourceforge.net Sun Nov 9 13:28:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 9 13:28:33 2003 Subject: [ 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 (Comment added) made by elfring 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: Martin v. L?wis (loewis) 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. ---------------------------------------------------------------------- >Comment By: Markus Elfring (elfring) Date: 2003-11-09 19:28 Message: Logged In: YES user_id=572001 Would you like to support that python scripts can be sent to a target thread like that can be done with the TCL function "thread::send"? http://cvs.sourceforge.net/viewcvs.py/*checkout*/tcl/thread/doc/html/thread.html?rev=1.10 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:07 Message: Logged In: YES user_id=21627 That feature is already available. You can easily provide a module-global mutex that is used to protect all entry points of some library. See _tkinter for one example, and socketmodule.c for another. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-09-07 15:02 Message: Logged In: YES user_id=572001 I am looking for a monitor implementation that has got the scope of a library or package and not a single synchronized method or block like it is in Java. A function object will get this monitor as a parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470 From noreply at sourceforge.net Sun Nov 9 18:28:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 9 18:28:32 2003 Subject: [ python-Bugs-838938 ] Typos in the docs (Extending/Embedding + Python/C API) Message-ID: Bugs item #838938, was opened at 2003-11-09 23: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=838938&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Florent Rougon (frougon) Assigned to: Nobody/Anonymous (nobody) Summary: Typos in the docs (Extending/Embedding + Python/C API) Initial Comment: Hi, I read a bit of the Extending/Embedding and Python/C API docs during the last weeks and gathered several typos during this process. This relates to Python 2.3.2. I attached a patch for the .tex files. Here follows the list of the problems (all minor) addressed by this patch. Thanks! Doc/api/abstract.tex: "Call the method named \var{m} of object \var{o}" should be replaced by "Call the method named \var{method} of object \var{o}". Doc/api/newtypes.tex: "The specific fields it expands to depends on" ^ "in Python 2.2.1 and later it will be initialized to the \member{ob_type} field of the base class" -> "it _is_ initialized" if the forecast was correct :-) There is a paragraph that reads "PyObject_HEAD_INIT" alone by itself, just before the "\begin{ctypedesc}{PyCFunction}". I think at least an "XXX" (as used later in the same file) is missing. "Pointer to an additional structure contains fields" -> "Pointer to an additional structure that contains fields" Doc/api/exceptions.tex: "that identifies where the context in which the unraisable exception occurred" -> "where" should be suppressed Doc/ext/newtypes.tex: "Note that used the \constant{METH_NOARGS} flag" ^ we "It's reference count" should be replaced by "Its reference count". Doc/tut/tut.tex: "When importing the package, Python searchs" -> "When importing the package, Python searches" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838938&group_id=5470 From noreply at sourceforge.net Mon Nov 10 02:21:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 02:21:26 2003 Subject: [ python-Bugs-839075 ] Document that highly recursive data cannot be pickled Message-ID: Bugs item #839075, was opened at 2003-11-10 07: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=839075&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Simon David Burton (simonb1) Assigned to: Nobody/Anonymous (nobody) Summary: Document that highly recursive data cannot be pickled Initial Comment: Make a note in section 3.4.14 Python Library Reference (perhaps a footnote?) that higly recursive data stuctures cannot be pickled. Setting the stack limit helps a bit, but does not scale to large networks of data. eg. #!/usr/bin/env python import cPickle as pickle #import pickle import os #sys.setrecursionlimit(4000) N = 2048 print "building..." nest = [ [] for i in range(N) ] for i in range(N): for j in range(N): nest[i].append( nest[j] ) print "dumping..." file = open("nest.pkl","wb") try: pickle.dump( nest, file ) except RuntimeError, e: print e ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839075&group_id=5470 From noreply at sourceforge.net Mon Nov 10 05:56:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 05:56:13 2003 Subject: [ python-Bugs-839151 ] attempt to access sys.argv when it doesn't exist Message-ID: Bugs item #839151, was opened at 2003-11-10 11:56 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=839151&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: attempt to access sys.argv when it doesn't exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 From noreply at sourceforge.net Mon Nov 10 06:32:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 06:32:15 2003 Subject: [ python-Bugs-839159 ] interators broken for weak dicts Message-ID: Bugs item #839159, was opened at 2003-11-10 11: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=839159&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: interators broken for weak dicts Initial Comment: You can't use iterators on wekref dicts because items might be removed from the dictionaries while iterating due to GC. I've attached a script that illustrates the bug with Python 2.3.2. It doesn't matter whether you use weak key or weak value dicts. If this can't be fixed, then the iteration methods should either be removed or made to (lamely) create intermediate lists to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839159&group_id=5470 From noreply at sourceforge.net Mon Nov 10 08:12:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 08:13:01 2003 Subject: [ python-Bugs-839200 ] some error in worning.py Message-ID: Bugs item #839200, was opened at 2003-11-10 16: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=839200&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Eugene Minkovskii (emin0) Assigned to: Nobody/Anonymous (nobody) Summary: some error in worning.py Initial Comment: I'm using the vim editor. In this product there are command :python {expression} which run {expression} in this expressions MODUL sys HAS NOT ATTRIBUTE argv. And when I run :python print sys.maxint + 1 I take an error. So, I wrote about this to Bram Moonlenaar (vim's maintainer) and He thing It's bug of python (I think he is right). Below, I put my letters to Bram and his answer. ===8<==============Bram Moonlenaar wrote:=============== Eugene Minkovskii wrote: > I see one bug in the vim. > So I typing in the vim: > > :py import sys > :py print sys.maxint > 2147483647 > :py print sys.maxint + 1 > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python23\Lib\warnings.py", line 53, in warn > filename = sys.argv[0] > AttributeError: 'module' object has no attribute 'argv' > :py print sys.maxint + 1L > 2147483648 This looks like a Python bug to me. It attempts to access sys.argv[0] while it doesn't exist. I could solve it by patching the Python library: *** /usr/local/lib/python2.3/warnings.py~ Mon Nov 10 11:27:00 2003 --- /usr/local/lib/python2.3/warnings.py Mon Nov 10 11:27:05 2003 *************** *** 49,55 **** if fnl.endswith(".pyc") or fnl.endswith(".pyo"): filename = filename[:-1] else: ! if module == "__main__": filename = sys.argv[0] if not filename: filename = module --- 49,55 ---- if fnl.endswith(".pyc") or fnl.endswith(".pyo"): filename = filename[:-1] else: ! if module == "__main__" and sys.__dict__.has_key("argv"): filename = sys.argv[0] if not filename: filename = module > 2) Now, the Python automatically correct this problem, by converting > numbers in longinteger format. > >>> sys.maxint + 1 > 2147483648L Apparently it also generates a warning message. After applying the above patch the result is printed as expected. > I think, really this is only one error: vim, for some strange reason, > generate wrong exception and Python can't catch them. No, the Python library accesses a member of the sys module that doesn't exist. -- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839200&group_id=5470 From noreply at sourceforge.net Mon Nov 10 09:58:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 09:59:10 2003 Subject: [ python-Bugs-839200 ] some error in worning.py Message-ID: Bugs item #839200, was opened at 2003-11-10 08:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839200&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Eugene Minkovskii (emin0) Assigned to: Nobody/Anonymous (nobody) Summary: some error in worning.py Initial Comment: I'm using the vim editor. In this product there are command :python {expression} which run {expression} in this expressions MODUL sys HAS NOT ATTRIBUTE argv. And when I run :python print sys.maxint + 1 I take an error. So, I wrote about this to Bram Moonlenaar (vim's maintainer) and He thing It's bug of python (I think he is right). Below, I put my letters to Bram and his answer. ===8<==============Bram Moonlenaar wrote:=============== Eugene Minkovskii wrote: > I see one bug in the vim. > So I typing in the vim: > > :py import sys > :py print sys.maxint > 2147483647 > :py print sys.maxint + 1 > Traceback (most recent call last): > File "", line 1, in ? > File "C:\Python23\Lib\warnings.py", line 53, in warn > filename = sys.argv[0] > AttributeError: 'module' object has no attribute 'argv' > :py print sys.maxint + 1L > 2147483648 This looks like a Python bug to me. It attempts to access sys.argv[0] while it doesn't exist. I could solve it by patching the Python library: *** /usr/local/lib/python2.3/warnings.py~ Mon Nov 10 11:27:00 2003 --- /usr/local/lib/python2.3/warnings.py Mon Nov 10 11:27:05 2003 *************** *** 49,55 **** if fnl.endswith(".pyc") or fnl.endswith(".pyo"): filename = filename[:-1] else: ! if module == "__main__": filename = sys.argv[0] if not filename: filename = module --- 49,55 ---- if fnl.endswith(".pyc") or fnl.endswith(".pyo"): filename = filename[:-1] else: ! if module == "__main__" and sys.__dict__.has_key("argv"): filename = sys.argv[0] if not filename: filename = module > 2) Now, the Python automatically correct this problem, by converting > numbers in longinteger format. > >>> sys.maxint + 1 > 2147483648L Apparently it also generates a warning message. After applying the above patch the result is printed as expected. > I think, really this is only one error: vim, for some strange reason, > generate wrong exception and Python can't catch them. No, the Python library accesses a member of the sys module that doesn't exist. -- ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 09:58 Message: Logged In: YES user_id=33168 Duplicate of 839151. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839200&group_id=5470 From noreply at sourceforge.net Mon Nov 10 10:02:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 10:02:19 2003 Subject: [ python-Bugs-839151 ] attempt to access sys.argv when it doesn't exist Message-ID: Bugs item #839151, was opened at 2003-11-10 05:56 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: attempt to access sys.argv when it doesn't exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 10:02 Message: Logged In: YES user_id=33168 Just to provide a reference, 839200 was a duplicate of this report. I closed 839200. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 From noreply at sourceforge.net Mon Nov 10 11:43:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 11:43:58 2003 Subject: [ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1 Message-ID: Bugs item #835145, was opened at 2003-11-03 12:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] zipfile test failure on AIX 5.1 Initial Comment: $ cd /opt/build/Python-2.3.2 $ ./python -E -tt Lib/test/test_zipfile.py Traceback (most recent call last): File "Lib/test/test_zipfile.py", line 35, in ? zipTest(file, zipfile.ZIP_STORED, writtenData) File "Lib/test/test_zipfile.py", line 13, in zipTest zip.close() File "/opt/build/Python-2.3.2/Lib/zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert Exception exceptions.OverflowError: 'long int too large to convert' in > ignored The test passes just fine on AIX 4.3.2. This is against a Python built with the IBM v6 C compiler and GCC 3.3.2. I added some debugging print statements to Lib/zipfile.py and it seems that zinfo.external_attr is out of whack. On AIX 4.3.2, the value for this variable is "2176057344" while on AIX 5.1 it is "10765991936". I tracked this back to the following line in the write method of Lib/zipfile.py: zinfo.external_attr = st[0] << 16L # Unix attributes On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is 164276. In python 2.2.x, it was '<< 16' which resulted in a signed value on AIX 5.1. I really don't think you can use the 16L as mode_t on AIX is unsigned int. Ditto for other platforms. Why not just store st[0] unchanged? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-10 11:43 Message: Logged In: YES user_id=6380 It looks like what is happening is that the mode returned by stat() has a bit beyond the 16th set. I'm guessing that those extra bits should be ignored -- there is no room for them in the header it seems. Could you try replacing st[0] with (st[0] & 0xffff) in that expression and then try again? (Hm, I wonder why the Unix mode is left-shifted 16 bits. Maybe the real definition of "external attributes" is a bit different? What is supposed to be stored in those lower 16 bits that always appear to be zero? I don't have time to research this.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 From noreply at sourceforge.net Mon Nov 10 15:42:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 15:42:46 2003 Subject: [ python-Bugs-839496 ] SimpleHTTPServer reports wrong content-length for text files Message-ID: Bugs item #839496, was opened at 2003-11-10 21:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839496&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleHTTPServer reports wrong content-length for text files Initial Comment: (Python 2.3.2 on Windows) SimpleHTTPServer reports the size of the file on disk as Content-Length. This works except for text files. If the content type starts with "text/" it is opening the file in 'text' mode rather than 'binary' mode. At least on Windows this causes newline translations, thereby making the actual size of the content transmitted *less* than the content-length! I don't know why SimpleHTTPServer is reading text files with text mode. The included patch removes this distinction so all files are opened in binary mode (and, also on windows, the actual size transmitted is the same as the reported content-length). --Irmen de Jong ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839496&group_id=5470 From noreply at sourceforge.net Mon Nov 10 16:32:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 16:32:50 2003 Subject: [ python-Bugs-839548 ] Bug in type's GC handling causes segfaults Message-ID: Bugs item #839548, was opened at 2003-11-10 21: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=839548&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in type's GC handling causes segfaults Initial Comment: type has a bug in it's GC "clear" function, type_clear. It sets tp->mro to NULL, but other code (especially PyObject_GenericGetAttr) assumes that tp_mro cannot be null. A class participating in a cycle may have clear called while there are still instances around. If someone tries to do a getattr on such an instance, python will crach with a segfault or with an assertion error. A simple fix is for clear to set tp_mro to an empty tuple, which breaks the cycle without breaking the invariant. A patch is attached. I encountered this in Zope 3 after adding a new interface implementation that made heavy use of weakrefs. Often Zope 3 would segfault when exiting. The patch fixes this. Unfortunately, I was not able, in the time available, to come up with a simpler test case. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 From noreply at sourceforge.net Mon Nov 10 16:35:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 16:35:48 2003 Subject: [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-16 12:31 Message generated for change (Comment added) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library >Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Ben Gertzfield (che_fox) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2003-11-11 08:35 Message: Logged In: YES user_id=6405 Hurm. This issue has been lost to the void, but it's as valid today as it ever was. I've just had another user of Roundup run into the same thing: RE: [issue51] Mails being delayed [assignedto=stuartm;priority=medium] (that should be one long line) became RE: [issue51] Mails being delayed [assignedto=stuartm;priority=me dium] when sent by Outlook. Note that the current code reconstructs that line as "me\ndium" which is about as wrong as it can get, as there's no way for my code to determine whether that *should* be "me dium" or "medium" since the other whitespace has been stripped (so just stripping out the newline, as my code currently does, doesn't help). I stand by my original post, requesting that the code be fixed as stated. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-16 03:28 Message: Logged In: YES user_id=12800 There is some value in not unfolding long lines by default. FWIW, the email package also retains the line breaks for such multi-line headers. The advantage to retaining this is that message input/output can be idempotent (i.e. you get the same thing in as you get out). This can be useful when using the message to generate a hash value, and for other user-friendly reasons. That being said, there is also some use in providing a way to return the unfolded line. I don't see a lot of benefit in adding such a feature to the rfc822 module, but I could see adding it to the email package. Specifically, I would propose to add it to the email.Header.Header class, either as a separate method (e.g. Header.unfold()) or as a default argument to the Header.encode() method (e.g. Header.encode(self, unfold=0)). If we did the latter, then I'd change Header.__str__() to call .encode(unfold=1). Assigning to Ben to get his feedback. Ben, feel free to comment and re-assign this bug to me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-16 23:14 Message: Logged In: YES user_id=21627 Even though it might not matter, I don't think changing it would hurt, either, and the change brings it definitely closer to following the word of RFC 2822. If no case is brought forward where it matters, fixing it for 2.3 alone should be sufficient. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2002-01-16 23:12 Message: Logged In: YES user_id=6405 Yes, we had someone submit a bug report on the roundup users mailing list because someone had sent a message to the roundup mail gateway which was split. The client was extra-specially broken, since it split in the middle of a word (which is not to spec), but the more general case of folding on whitespace will cause roundup problems since I hadn't expected there to be any newlines in the header. I can modify roundup to strip out the newline, but it'd be nice to have rfc822.Message not put it in there... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-16 13:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply at sourceforge.net Mon Nov 10 16:35:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 16:35:50 2003 Subject: [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-16 12:31 Message generated for change (Settings changed) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Ben Gertzfield (che_fox) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-11-11 08:35 Message: Logged In: YES user_id=6405 Hurm. This issue has been lost to the void, but it's as valid today as it ever was. I've just had another user of Roundup run into the same thing: RE: [issue51] Mails being delayed [assignedto=stuartm;priority=medium] (that should be one long line) became RE: [issue51] Mails being delayed [assignedto=stuartm;priority=me dium] when sent by Outlook. Note that the current code reconstructs that line as "me\ndium" which is about as wrong as it can get, as there's no way for my code to determine whether that *should* be "me dium" or "medium" since the other whitespace has been stripped (so just stripping out the newline, as my code currently does, doesn't help). I stand by my original post, requesting that the code be fixed as stated. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-16 03:28 Message: Logged In: YES user_id=12800 There is some value in not unfolding long lines by default. FWIW, the email package also retains the line breaks for such multi-line headers. The advantage to retaining this is that message input/output can be idempotent (i.e. you get the same thing in as you get out). This can be useful when using the message to generate a hash value, and for other user-friendly reasons. That being said, there is also some use in providing a way to return the unfolded line. I don't see a lot of benefit in adding such a feature to the rfc822 module, but I could see adding it to the email package. Specifically, I would propose to add it to the email.Header.Header class, either as a separate method (e.g. Header.unfold()) or as a default argument to the Header.encode() method (e.g. Header.encode(self, unfold=0)). If we did the latter, then I'd change Header.__str__() to call .encode(unfold=1). Assigning to Ben to get his feedback. Ben, feel free to comment and re-assign this bug to me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-16 23:14 Message: Logged In: YES user_id=21627 Even though it might not matter, I don't think changing it would hurt, either, and the change brings it definitely closer to following the word of RFC 2822. If no case is brought forward where it matters, fixing it for 2.3 alone should be sufficient. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2002-01-16 23:12 Message: Logged In: YES user_id=6405 Yes, we had someone submit a bug report on the roundup users mailing list because someone had sent a message to the roundup mail gateway which was split. The client was extra-specially broken, since it split in the middle of a word (which is not to spec), but the more general case of folding on whitespace will cause roundup problems since I hadn't expected there to be any newlines in the header. I can modify roundup to strip out the newline, but it'd be nice to have rfc822.Message not put it in there... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-16 13:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply at sourceforge.net Mon Nov 10 17:04:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 17:04:46 2003 Subject: [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-15 20:31 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Ben Gertzfield (che_fox) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-10 17:04 Message: Logged In: YES user_id=12800 Since this was never addressed in the email package either, perhaps you'd like to bring it up in the email-sig? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-11-10 16:35 Message: Logged In: YES user_id=6405 Hurm. This issue has been lost to the void, but it's as valid today as it ever was. I've just had another user of Roundup run into the same thing: RE: [issue51] Mails being delayed [assignedto=stuartm;priority=medium] (that should be one long line) became RE: [issue51] Mails being delayed [assignedto=stuartm;priority=me dium] when sent by Outlook. Note that the current code reconstructs that line as "me\ndium" which is about as wrong as it can get, as there's no way for my code to determine whether that *should* be "me dium" or "medium" since the other whitespace has been stripped (so just stripping out the newline, as my code currently does, doesn't help). I stand by my original post, requesting that the code be fixed as stated. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-15 13:28 Message: Logged In: YES user_id=12800 There is some value in not unfolding long lines by default. FWIW, the email package also retains the line breaks for such multi-line headers. The advantage to retaining this is that message input/output can be idempotent (i.e. you get the same thing in as you get out). This can be useful when using the message to generate a hash value, and for other user-friendly reasons. That being said, there is also some use in providing a way to return the unfolded line. I don't see a lot of benefit in adding such a feature to the rfc822 module, but I could see adding it to the email package. Specifically, I would propose to add it to the email.Header.Header class, either as a separate method (e.g. Header.unfold()) or as a default argument to the Header.encode() method (e.g. Header.encode(self, unfold=0)). If we did the latter, then I'd change Header.__str__() to call .encode(unfold=1). Assigning to Ben to get his feedback. Ben, feel free to comment and re-assign this bug to me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-16 07:14 Message: Logged In: YES user_id=21627 Even though it might not matter, I don't think changing it would hurt, either, and the change brings it definitely closer to following the word of RFC 2822. If no case is brought forward where it matters, fixing it for 2.3 alone should be sufficient. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2002-01-16 07:12 Message: Logged In: YES user_id=6405 Yes, we had someone submit a bug report on the roundup users mailing list because someone had sent a message to the roundup mail gateway which was split. The client was extra-specially broken, since it split in the middle of a word (which is not to spec), but the more general case of folding on whitespace will cause roundup problems since I hadn't expected there to be any newlines in the header. I can modify roundup to strip out the newline, but it'd be nice to have rfc822.Message not put it in there... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-15 21:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply at sourceforge.net Mon Nov 10 17:11:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 17:11:28 2003 Subject: [ python-Bugs-839585 ] String formatting operator % badly documented Message-ID: Bugs item #839585, was opened at 2003-11-10 23:11 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=839585&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: String formatting operator % badly documented Initial Comment: Hello everyone! The % operator works with strings, but this is hard to find in the documentation (Library Reference 2.2.6.2). Really bad is, that an operator should be documented in the Language Reference, where it isn't. Lang-Ref "5.6 Binary arithmetic operations" is labeled wrong, as it also describes the non-arithmetic operations of + and * but seems to know nothing about % under that aspect... It is actually indirectly saying that there is no further non-arithmetic operation - but there is: %. Rob ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470 From noreply at sourceforge.net Mon Nov 10 17:28:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 17:28:48 2003 Subject: [ python-Bugs-504152 ] rfc822 long header continuation broken Message-ID: Bugs item #504152, was opened at 2002-01-16 12:31 Message generated for change (Comment added) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Ben Gertzfield (che_fox) Summary: rfc822 long header continuation broken Initial Comment: I don't believe this is fixed in 2.1.2 or 2.2, but haven't checked. The code in rfc822.Message.readheaders incorrectly unfolds long message headers. The relevant information from rfc2822 is in section 2.2.3. In short: """ The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. """ This means that the code in readheaders: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = (self.dict[headerseen] + "\n " + line.strip()) self.dict[headerseen] = x.strip() continue should be: if headerseen and line[0] in ' \t': # It's a continuation line. list.append(line) x = self.dict[headerseen] + line self.dict[headerseen] = x.strip() continue ie. no stripping of the leading whitespace and no adding the newline. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2003-11-11 09:28 Message: Logged In: YES user_id=6405 OK, I've sent a message, but I don't have the time to sign up to the list. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-11 09:04 Message: Logged In: YES user_id=12800 Since this was never addressed in the email package either, perhaps you'd like to bring it up in the email-sig? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-11-11 08:35 Message: Logged In: YES user_id=6405 Hurm. This issue has been lost to the void, but it's as valid today as it ever was. I've just had another user of Roundup run into the same thing: RE: [issue51] Mails being delayed [assignedto=stuartm;priority=medium] (that should be one long line) became RE: [issue51] Mails being delayed [assignedto=stuartm;priority=me dium] when sent by Outlook. Note that the current code reconstructs that line as "me\ndium" which is about as wrong as it can get, as there's no way for my code to determine whether that *should* be "me dium" or "medium" since the other whitespace has been stripped (so just stripping out the newline, as my code currently does, doesn't help). I stand by my original post, requesting that the code be fixed as stated. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-16 03:28 Message: Logged In: YES user_id=12800 There is some value in not unfolding long lines by default. FWIW, the email package also retains the line breaks for such multi-line headers. The advantage to retaining this is that message input/output can be idempotent (i.e. you get the same thing in as you get out). This can be useful when using the message to generate a hash value, and for other user-friendly reasons. That being said, there is also some use in providing a way to return the unfolded line. I don't see a lot of benefit in adding such a feature to the rfc822 module, but I could see adding it to the email package. Specifically, I would propose to add it to the email.Header.Header class, either as a separate method (e.g. Header.unfold()) or as a default argument to the Header.encode() method (e.g. Header.encode(self, unfold=0)). If we did the latter, then I'd change Header.__str__() to call .encode(unfold=1). Assigning to Ben to get his feedback. Ben, feel free to comment and re-assign this bug to me. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-01-16 23:14 Message: Logged In: YES user_id=21627 Even though it might not matter, I don't think changing it would hurt, either, and the change brings it definitely closer to following the word of RFC 2822. If no case is brought forward where it matters, fixing it for 2.3 alone should be sufficient. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2002-01-16 23:12 Message: Logged In: YES user_id=6405 Yes, we had someone submit a bug report on the roundup users mailing list because someone had sent a message to the roundup mail gateway which was split. The client was extra-specially broken, since it split in the middle of a word (which is not to spec), but the more general case of folding on whitespace will cause roundup problems since I hadn't expected there to be any newlines in the header. I can modify roundup to strip out the newline, but it'd be nice to have rfc822.Message not put it in there... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-16 13:47 Message: Logged In: YES user_id=6380 Richard, have you found a situation where it matters? I thought that usually the next phase calls for normalizing whitespace by squashing repeated spaces/tabs and removing them from front and back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470 From noreply at sourceforge.net Mon Nov 10 21:47:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 10 21:47:36 2003 Subject: [ python-Bugs-839709 ] Windows non-MS compiler doc updates Message-ID: Bugs item #839709, was opened at 2003-11-10 19:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Brown (mike_j_brown) Assigned to: Nobody/Anonymous (nobody) Summary: Windows non-MS compiler doc updates Initial Comment: Documents affected: http://www.python.org/doc/2.3.2/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3.1/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.3/inst/tweak-flags.html sec. 6.2.2 http://www.python.org/doc/2.2.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.3/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.2/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1.1/inst/non-ms- compilers.html sec. 3.1.2 http://www.python.org/doc/2.1/inst/tweak-flags.html sec. 3.1.2 1. Filenames in the examples are way out of date. It is also not clear to the reader that python23.dll is located in %SystemRoot%\System32. I suggest that you change the pexports command line example to pexports \Windows\System32\python23.dll > python23.def In the Python 2.2 docs, use python22.dll and python22.def. In the Python 2.1 docs, use python21.dll and python21.def. 2. It's not clear to the reader where dlltool is. dlltool can also output directly to the right directory. I suggest that you change the dlltool command line example to \cygwin\bin\dlltool --dllname python23.dll --def python23.def --output-lib \Python23\Libs\libpython23.a In the Python 2.2 docs, use python22.dll, python22.def, and libpython22.a. In the Python 2.1 docs, use python21.dll, python21.def and libpython21.a. 3. Another filename out of date. I suggest that you change "The resulting library has to be placed in the same directory as python20.lib." to "The resulting library has to be placed in the same directory as python23.lib." In the Python 2.2 docs, use python22.lib. In the Python 2.1 docs, use python21.lib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839709&group_id=5470 From noreply at sourceforge.net Tue Nov 11 05:51:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 05:51:54 2003 Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 21:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 11:51 Message: Logged In: YES user_id=45365 Bob, I'm confused. As far as I know Python never unloads extension modules... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Tue Nov 11 06:21:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 06:21:33 2003 Subject: [ python-Bugs-839865 ] MacPython installer: disk image does not mount from NFS Message-ID: Bugs item #839865, was opened at 2003-11-11 12: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=839865&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython installer: disk image does not mount from NFS Initial Comment: Bill Janssen reports that the MacPython installer disk images (.dmg files) fail to mount, with error -199. It turns out his home directory is NFS-mounted. Other dmg files pose no problems. It could be that this has to do with the fact that we use our own tool to create the dmg images in stead of Apple's tools. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839865&group_id=5470 From noreply at sourceforge.net Tue Nov 11 09:20:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 09:20:50 2003 Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 15:44 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2003-11-11 09:20 Message: Logged In: YES user_id=139309 it does if you del sys.modules['somemodule'] and somemodule's reference count goes to zero. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 05:51 Message: Logged In: YES user_id=45365 Bob, I'm confused. As far as I know Python never unloads extension modules... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Tue Nov 11 10:16:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 10:17:07 2003 Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 21:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 16:16 Message: Logged In: YES user_id=45365 I'm surprised that it does the unload:-) I think the correct solution would be for the module itself (or someone close to it) to stash away a reference. As this is only a problem for some modules (those containing ObjC code) I don't think a general change is in order. The real problem is that the "last reference" as Python sees it isn't really the last reference: the ObjC runtime also has references to stuff in there. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-11 15:20 Message: Logged In: YES user_id=139309 it does if you del sys.modules['somemodule'] and somemodule's reference count goes to zero. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 11:51 Message: Logged In: YES user_id=45365 Bob, I'm confused. As far as I know Python never unloads extension modules... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Tue Nov 11 10:41:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 10:41:23 2003 Subject: [ python-Feature Requests-840034 ] additions to commands lib Message-ID: Feature Requests item #840034, was opened at 2003-11-11 09:41 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=840034&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hattarki (mindfunk) Assigned to: Nobody/Anonymous (nobody) Summary: additions to commands lib Initial Comment: There currently is a function, commands.getstatusoutput. This, simply, runs a command, returns it's exit code and and output. The problem is, stderr and stdout are mixed. There are many real world examples where this is not desirable. In fact, I've written the following function in various forms many, many times: def run_cmd(cmd): pipe = popen2.Popen3(cmd, 1) ret = pipe.wait() return (ret, pipe.fromchild.readlines(-1), pipe.childerr.readlines(-1)) This is a very simple command. Anyone could write it. But, I still think is should be added because there is a function that is very similar to it (getstatusoutput) that comes extremely close, but does something that renders it useless if one wants to separate the two. It would be a useful addition to the commands lib. Also, I wouldn't nessesarily name it "run_cmd" if added to the lib. I suppose one could have it throw exceptions as well: def getouterr(cmd): if not os.path.exists((cmd.split(' '))[0]): raise ATSCommandPath(cmd, "command not found") return run_cmd(cmd) ... obviously, one could do better error checking (searching $PATH, etc). But, that is the basic point. If you guys/gals will allow it, I would also like to submit the patch. namaste, Mark Bugs item #840065, was opened at 2003-11-11 08: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=840065&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Evans (jrevans) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect shared library build Initial Comment: The shared library is built and linked incorrectly resulting in errors. The proper method for linking a shared library is to link it against all libraries it is dependant upon. This puts entries into a shared library's dependency table (which can be seen using 'ldd' on linux or 'objdump' on other systems). The result of this is that any application that is linked againg a particular library does not need to be aware of any of its dependencies at link time, it merely links against what it is directly dependant upon. This can be thought of as building a dependancy tree. Getting a full list of all libraries an executable (or shared library) are dependant upon is as simple as using 'ldd' as this will list the full dependancy tree. The problem with the python shared library is that it is not linked during your build process against any of the libraries it is dependant upon. For example when building with the tk, readline, and expat modules compiled into python, the library needs to be linked against the respective libraries. In this way the shared library resolves all of its own dependancies. This is something that I have been doing for several years, including always having rebuilding the python library as a shread library by hand. For example: > ar -x libpythonX.X.a > g++ -shared *.o -o libpythonX.X.so -L/path/to/libs - lexpat -lreadline -ltk however since you have introduced the configure flag for shared library support (finally) it would be nice to be able to use it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840065&group_id=5470 From noreply at sourceforge.net Tue Nov 11 12:03:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 12:05:05 2003 Subject: [ python-Bugs-831747 ] httplib hardcodes Accept-Encoding Message-ID: Bugs item #831747, was opened at 2003-10-28 14:38 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hardcodes Accept-Encoding Initial Comment: in httplib.py the request() method adds a hardcoded Accept-Encoding header with the 'identity' value. This should at least be optional, since I have several programs supporting encodings like 'gzip' or 'deflate' and I want to be able to specify my own Accept-Encoding header. I suggest adding (similar to skip_host) a skip_accept_encoding optional argument. ---------------------------------------------------------------------- >Comment By: Bastian Kleineidam (calvin) Date: 2003-11-11 18:03 Message: Logged In: YES user_id=9205 Here is a patch against CVS adding skip_accept_encoding and documentation. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2003-10-31 15:55 Message: Logged In: YES user_id=9205 Yes, in a few days. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:45 Message: Logged In: YES user_id=21627 Can you provide a patch (including documentation changes)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 From noreply at sourceforge.net Tue Nov 11 15:12:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 15:12:25 2003 Subject: [ 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 (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470 Category: Threads Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Martin v. L?wis (loewis) 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. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-11 21:12 Message: Logged In: YES user_id=21627 This cannot be implemented for Python. It requires the receiving thread to expect the script being sent, which, in turn, requires an event loop, which Python does not have. If you are willing to invoke an event loop, you could easily implement a send function yourself. Just put triples (callable, *args, **kw) into a Queue, and send an event to the receiving thread to fetch that triple from the Queue; the receiving thread would then invoke the callable. In Python, we can share objects across threads, so passing script source code is not necessary (although easily possible - just pass eval as the callable, and a string as argument) Closing this as "Works for me", as the original request is implemented. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-11-09 19:28 Message: Logged In: YES user_id=572001 Would you like to support that python scripts can be sent to a target thread like that can be done with the TCL function "thread::send"? http://cvs.sourceforge.net/viewcvs.py/*checkout*/tcl/thread/doc/html/thread.html?rev=1.10 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:07 Message: Logged In: YES user_id=21627 That feature is already available. You can easily provide a module-global mutex that is used to protect all entry points of some library. See _tkinter for one example, and socketmodule.c for another. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-09-07 15:02 Message: Logged In: YES user_id=572001 I am looking for a monitor implementation that has got the scope of a library or package and not a single synchronized method or block like it is in Java. A function object will get this monitor as a parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470 From noreply at sourceforge.net Tue Nov 11 15:14:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 15:14:45 2003 Subject: [ python-Bugs-840065 ] Incorrect shared library build Message-ID: Bugs item #840065, was opened at 2003-11-11 17:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840065&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Evans (jrevans) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect shared library build Initial Comment: The shared library is built and linked incorrectly resulting in errors. The proper method for linking a shared library is to link it against all libraries it is dependant upon. This puts entries into a shared library's dependency table (which can be seen using 'ldd' on linux or 'objdump' on other systems). The result of this is that any application that is linked againg a particular library does not need to be aware of any of its dependencies at link time, it merely links against what it is directly dependant upon. This can be thought of as building a dependancy tree. Getting a full list of all libraries an executable (or shared library) are dependant upon is as simple as using 'ldd' as this will list the full dependancy tree. The problem with the python shared library is that it is not linked during your build process against any of the libraries it is dependant upon. For example when building with the tk, readline, and expat modules compiled into python, the library needs to be linked against the respective libraries. In this way the shared library resolves all of its own dependancies. This is something that I have been doing for several years, including always having rebuilding the python library as a shread library by hand. For example: > ar -x libpythonX.X.a > g++ -shared *.o -o libpythonX.X.so -L/path/to/libs - lexpat -lreadline -ltk however since you have introduced the configure flag for shared library support (finally) it would be nice to be able to use it. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-11 21:14 Message: Logged In: YES user_id=21627 Would you be willing to contribute a patch? This feature is essentially unmaintained, and only updated when users contribute updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840065&group_id=5470 From noreply at sourceforge.net Tue Nov 11 17:38:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 17:39:38 2003 Subject: [ python-Bugs-840065 ] Incorrect shared library build Message-ID: Bugs item #840065, was opened at 2003-11-11 08:29 Message generated for change (Comment added) made by jrevans You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840065&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Evans (jrevans) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect shared library build Initial Comment: The shared library is built and linked incorrectly resulting in errors. The proper method for linking a shared library is to link it against all libraries it is dependant upon. This puts entries into a shared library's dependency table (which can be seen using 'ldd' on linux or 'objdump' on other systems). The result of this is that any application that is linked againg a particular library does not need to be aware of any of its dependencies at link time, it merely links against what it is directly dependant upon. This can be thought of as building a dependancy tree. Getting a full list of all libraries an executable (or shared library) are dependant upon is as simple as using 'ldd' as this will list the full dependancy tree. The problem with the python shared library is that it is not linked during your build process against any of the libraries it is dependant upon. For example when building with the tk, readline, and expat modules compiled into python, the library needs to be linked against the respective libraries. In this way the shared library resolves all of its own dependancies. This is something that I have been doing for several years, including always having rebuilding the python library as a shread library by hand. For example: > ar -x libpythonX.X.a > g++ -shared *.o -o libpythonX.X.so -L/path/to/libs - lexpat -lreadline -ltk however since you have introduced the configure flag for shared library support (finally) it would be nice to be able to use it. ---------------------------------------------------------------------- >Comment By: James Evans (jrevans) Date: 2003-11-11 14:38 Message: Logged In: YES user_id=158456 Okay, I'll take a crack at it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-11 12:14 Message: Logged In: YES user_id=21627 Would you be willing to contribute a patch? This feature is essentially unmaintained, and only updated when users contribute updates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840065&group_id=5470 From noreply at sourceforge.net Tue Nov 11 19:18:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 19:18:56 2003 Subject: [ python-Bugs-816627 ] file read() forgets some bytes Message-ID: Bugs item #816627, was opened at 2003-10-02 10:54 Message generated for change (Comment added) made by jfdutcher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: file read() forgets some bytes Initial Comment: It seems the python miscalculates the size of a file. This is on windows, with python 2.2.2 from ActiveState E:\work\jayacard\inkit\demo>python ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array, os >>> fname = "current_img.jpg" >>> print len(open(fname).read()) 41 >>> print os.stat(fname).st_size 693 As you can see, there some mismatch here. 693 is indeed the size reported by the windows explorer. >>> a = array.array('B') >>> a.fromfile( open(fname), 693) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 42) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 41) >>> a = array.array('B') >>> a.fromfile(open(fname), 41) >>> len(a) 41 I attach the nasty file This is a very serious bug for me. ---------------------------------------------------------------------- Comment By: JohnF Dutcher (jfdutcher) Date: 2003-11-11 19:18 Message: Logged In: YES user_id=906889 Despite 'tim-one's assertion to the contrary, my own experience confirms that fromfile and array do NOT work properly when importing (fromfile) and exporting (tofile) to even binary files ( I use no other kind than binary). The tofile (or even the write command) appears to properly increment the file pointer after a given tofile is issued. A subsequent fromfile (or a read) will NOT read fromthe same byte location in the file where the previous write terminated.....thus destroying file integrity, and also leading to inappropriate EOF messages. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 14:11 Message: Logged In: YES user_id=31435 Text files must be opened in text mode in order to (at least) hide platform differences in how line endings are represented. For example, on Linux a line ends with \n, on Windows with \r\n, and on classic Macintoshes with \r. Python has no control over what the native operating system conventions are. But when a text file is opened in text mode, Python hides the platform differences, making all lines *appear* as if they ended with \n on input. On output to a file opened in text mode, Python changes \n to whatever the platform convention is for ending a line. If it didn't do this, text files created with Python would be unusable by non-Python programs on your system, and text files created by non- Python programs on your system would be unusable by Python. The distinction between text mode and binary mode didn't originate with Python, and all you can do is try to live with it. The distinction is simply a reality on most non-Unix systems (Unix treats text and binary mode exactly the same). Note that it's not possible either to guess whether a file is *intended* to be text mode or binary mode by staring at its contents. The distinction is in the mind of the programmer who created the file. So it goes. Portability isn't hard despite all this: always open binary files in binary mode, and always open text files in text mode. That's it. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-10-05 13:31 Message: Logged In: YES user_id=233844 Thanks a lot for the answer. But is there any advantage in opening a file in ascii mode ? Why not open every windows file in binary mode by default, and treat it internall as an ascii file later on, if it turns out to be one ? With python returning always strings, the distinction makes very little sense. This is the kind of thing that will unfortunately make a program more difficult to port. I guess it is too late to change this behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 11:02 Message: Logged In: YES user_id=31435 Windows makes a distinction between binary-mode and text- mode files. open() defaults to text-mode. A .jpg is certainly a binary file, so on Windows you *must* open with it in binary mode. That means changing your open(fname) to open(fname, 'rb') Your problem will go away then. It's unfortunate, but that's the way Windows works -- it's not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 From noreply at sourceforge.net Tue Nov 11 19:29:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 11 19:29:52 2003 Subject: [ python-Bugs-816627 ] file read() forgets some bytes Message-ID: Bugs item #816627, was opened at 2003-10-02 11:54 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: file read() forgets some bytes Initial Comment: It seems the python miscalculates the size of a file. This is on windows, with python 2.2.2 from ActiveState E:\work\jayacard\inkit\demo>python ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array, os >>> fname = "current_img.jpg" >>> print len(open(fname).read()) 41 >>> print os.stat(fname).st_size 693 As you can see, there some mismatch here. 693 is indeed the size reported by the windows explorer. >>> a = array.array('B') >>> a.fromfile( open(fname), 693) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 42) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 41) >>> a = array.array('B') >>> a.fromfile(open(fname), 41) >>> len(a) 41 I attach the nasty file This is a very serious bug for me. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-11 19:29 Message: Logged In: YES user_id=31435 Why are you attaching your complaint to a closed bug report? Nobody is going to see it here. If the OP wasn't happy with the resolution, he's had 5 weeks to say so. If you have a new problem, open a new bug report. Also include basic information: which version of Python, which OS, and a minimal executable program that shows the bad behavior. Because the OP did give that information, it was obvious he was opening a binary file on Windows in text mode. Your problem may be just as shallow. Let me guess: you cannot switch between reading and writing without doing a seek in between. That's the way C's standard I/O works on all platforms. No exception is raised if you neglect to seek, but the results are undefined. Python inherits that behavior from the platform C library. If you're not seeking when switching between reading and writing, that's the cause of your problem. ---------------------------------------------------------------------- Comment By: JohnF Dutcher (jfdutcher) Date: 2003-11-11 19:18 Message: Logged In: YES user_id=906889 Despite 'tim-one's assertion to the contrary, my own experience confirms that fromfile and array do NOT work properly when importing (fromfile) and exporting (tofile) to even binary files ( I use no other kind than binary). The tofile (or even the write command) appears to properly increment the file pointer after a given tofile is issued. A subsequent fromfile (or a read) will NOT read fromthe same byte location in the file where the previous write terminated.....thus destroying file integrity, and also leading to inappropriate EOF messages. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 15:11 Message: Logged In: YES user_id=31435 Text files must be opened in text mode in order to (at least) hide platform differences in how line endings are represented. For example, on Linux a line ends with \n, on Windows with \r\n, and on classic Macintoshes with \r. Python has no control over what the native operating system conventions are. But when a text file is opened in text mode, Python hides the platform differences, making all lines *appear* as if they ended with \n on input. On output to a file opened in text mode, Python changes \n to whatever the platform convention is for ending a line. If it didn't do this, text files created with Python would be unusable by non-Python programs on your system, and text files created by non- Python programs on your system would be unusable by Python. The distinction between text mode and binary mode didn't originate with Python, and all you can do is try to live with it. The distinction is simply a reality on most non-Unix systems (Unix treats text and binary mode exactly the same). Note that it's not possible either to guess whether a file is *intended* to be text mode or binary mode by staring at its contents. The distinction is in the mind of the programmer who created the file. So it goes. Portability isn't hard despite all this: always open binary files in binary mode, and always open text files in text mode. That's it. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-10-05 14:31 Message: Logged In: YES user_id=233844 Thanks a lot for the answer. But is there any advantage in opening a file in ascii mode ? Why not open every windows file in binary mode by default, and treat it internall as an ascii file later on, if it turns out to be one ? With python returning always strings, the distinction makes very little sense. This is the kind of thing that will unfortunately make a program more difficult to port. I guess it is too late to change this behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 12:02 Message: Logged In: YES user_id=31435 Windows makes a distinction between binary-mode and text- mode files. open() defaults to text-mode. A .jpg is certainly a binary file, so on Windows you *must* open with it in binary mode. That means changing your open(fname) to open(fname, 'rb') Your problem will go away then. It's unfortunate, but that's the way Windows works -- it's not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 From noreply at sourceforge.net Wed Nov 12 12:05:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 12 12:05:52 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 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=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 12 12:07:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 12 12:07:19 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 9 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-12 18:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 12 12:08:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 12 12:08:50 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-12 18:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 12 14:54:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 12 14:54:48 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) >Assigned to: Tim Peters (tim_one) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 12 15:47:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 12 15:47:25 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-12 15:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 12 23:31:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 12 23:37:09 2003 Subject: [ python-Bugs-841180 ] incorrect Debian info in FAQ Message-ID: Bugs item #841180, was opened at 2003-11-12 23: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=841180&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ivan Nestlerode (nestler) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect Debian info in FAQ Initial Comment: In the Extending/Embedding FAQ at http://www.python.org/doc/faq/extending.html, under question 14 (I want to compile a Python module on my Linux system...), you say: For Debian, run apt-get install python-devel The problem is that Debian's Python development package is called python-dev, not python-devel. -Ivan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841180&group_id=5470 From noreply at sourceforge.net Thu Nov 13 02:49:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 02:49:58 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) >Assigned to: Tim Peters (tim_one) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-13 08:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 21:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 20:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Thu Nov 13 08:56:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 08:58:49 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-13 08:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 02:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 15:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Thu Nov 13 14:11:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 14:11:49 2003 Subject: [ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1 Message-ID: Bugs item #835145, was opened at 2003-11-03 12:06 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] zipfile test failure on AIX 5.1 Initial Comment: $ cd /opt/build/Python-2.3.2 $ ./python -E -tt Lib/test/test_zipfile.py Traceback (most recent call last): File "Lib/test/test_zipfile.py", line 35, in ? zipTest(file, zipfile.ZIP_STORED, writtenData) File "Lib/test/test_zipfile.py", line 13, in zipTest zip.close() File "/opt/build/Python-2.3.2/Lib/zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert Exception exceptions.OverflowError: 'long int too large to convert' in > ignored The test passes just fine on AIX 4.3.2. This is against a Python built with the IBM v6 C compiler and GCC 3.3.2. I added some debugging print statements to Lib/zipfile.py and it seems that zinfo.external_attr is out of whack. On AIX 4.3.2, the value for this variable is "2176057344" while on AIX 5.1 it is "10765991936". I tracked this back to the following line in the write method of Lib/zipfile.py: zinfo.external_attr = st[0] << 16L # Unix attributes On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is 164276. In python 2.2.x, it was '<< 16' which resulted in a signed value on AIX 5.1. I really don't think you can use the 16L as mode_t on AIX is unsigned int. Ditto for other platforms. Why not just store st[0] unchanged? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-13 14:11 Message: Logged In: YES user_id=6380 So Albert, any luck with my suggestion? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-10 11:43 Message: Logged In: YES user_id=6380 It looks like what is happening is that the mode returned by stat() has a bit beyond the 16th set. I'm guessing that those extra bits should be ignored -- there is no room for them in the header it seems. Could you try replacing st[0] with (st[0] & 0xffff) in that expression and then try again? (Hm, I wonder why the Unix mode is left-shifted 16 bits. Maybe the real definition of "external attributes" is a bit different? What is supposed to be stored in those lower 16 bits that always appear to be zero? I don't have time to research this.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 From noreply at sourceforge.net Thu Nov 13 14:51:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 14:51:14 2003 Subject: [ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1 Message-ID: Bugs item #835145, was opened at 2003-11-03 08:06 Message generated for change (Comment added) made by tww-china You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] zipfile test failure on AIX 5.1 Initial Comment: $ cd /opt/build/Python-2.3.2 $ ./python -E -tt Lib/test/test_zipfile.py Traceback (most recent call last): File "Lib/test/test_zipfile.py", line 35, in ? zipTest(file, zipfile.ZIP_STORED, writtenData) File "Lib/test/test_zipfile.py", line 13, in zipTest zip.close() File "/opt/build/Python-2.3.2/Lib/zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert Exception exceptions.OverflowError: 'long int too large to convert' in > ignored The test passes just fine on AIX 4.3.2. This is against a Python built with the IBM v6 C compiler and GCC 3.3.2. I added some debugging print statements to Lib/zipfile.py and it seems that zinfo.external_attr is out of whack. On AIX 4.3.2, the value for this variable is "2176057344" while on AIX 5.1 it is "10765991936". I tracked this back to the following line in the write method of Lib/zipfile.py: zinfo.external_attr = st[0] << 16L # Unix attributes On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is 164276. In python 2.2.x, it was '<< 16' which resulted in a signed value on AIX 5.1. I really don't think you can use the 16L as mode_t on AIX is unsigned int. Ditto for other platforms. Why not just store st[0] unchanged? ---------------------------------------------------------------------- >Comment By: The Written Word (Albert Chin) (tww-china) Date: 2003-11-13 10:51 Message: Logged In: YES user_id=119770 The suggestion works. I want to look through the zip-2.3 source though. I'll do so this weekend. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-13 10:11 Message: Logged In: YES user_id=6380 So Albert, any luck with my suggestion? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-10 07:43 Message: Logged In: YES user_id=6380 It looks like what is happening is that the mode returned by stat() has a bit beyond the 16th set. I'm guessing that those extra bits should be ignored -- there is no room for them in the header it seems. Could you try replacing st[0] with (st[0] & 0xffff) in that expression and then try again? (Hm, I wonder why the Unix mode is left-shifted 16 bits. Maybe the real definition of "external attributes" is a bit different? What is supposed to be stored in those lower 16 bits that always appear to be zero? I don't have time to research this.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 From noreply at sourceforge.net Thu Nov 13 15:42:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 15:42:54 2003 Subject: [ python-Feature Requests-814689 ] sendmsg operation for unix sockets Message-ID: Feature Requests item #814689, was opened at 2003-09-29 19:58 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=814689&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: sendmsg operation for unix sockets Initial Comment: The socket module doesn't seem to support the sendmsg operation for AF_UNIX sockets, at least in Python 2.2.2 under Linux. This is needed to send ancillary messages to sockets. Those in turn allow a process to see the user id of its peer, allows sending file descriptors to other processes (needed for anything like User Mode Linux so that non-root processes can open privileged ports), and so forth. ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2003-11-13 20:42 Message: Logged In: YES user_id=72053 I may see about putting a patch together but don't hold your breath. Main purpose of this RFE is to track the item. It's not urgent for me right now. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 21:02 Message: Logged In: YES user_id=21627 Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=814689&group_id=5470 From noreply at sourceforge.net Thu Nov 13 15:56:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 15:56:36 2003 Subject: [ python-Feature Requests-841728 ] urllib and cookie module improvements Message-ID: Feature Requests item #841728, was opened at 2003-11-13 20:56 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=841728&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: urllib and cookie module improvements Initial Comment: 1. The Cookie module should do a better job parsing real- world cookies (the stuff that comes from http servers following Set-cookie: headers) and should also have a documented way to emit a client-side cookie (i.e. generate a correct Cookie: header from a cookie object). 2. Urllib or urllib2 should be enhanced to read incoming cookie headers and send back the appropriate cookies in the event of an HTTP redirect. Many sites set a cookie then redirect to some other location which tries to read the cookie; if the cookie isn't there, the new location bounces back to the original one to set the cookie, so you get a redirection loop. 3. The scheme of having urllib.urlopen() return the http headers in a dictionary-like object doesn't quite work: for example, there can be several Set-cookie headers in a single http response. I don't know if the opener currently combines them or discards some; neither way is really satisfactory. There really should be a list for each header type, but that would mess up the existing published interface, so maybe a new 'urllib3' is needed. I'm just starting to explore this stuff but it seems to me like a serious urllib module needs to do quite a bit more than the existing ones do. The Perl LWP documentation might be a good place to look for inspiration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=841728&group_id=5470 From noreply at sourceforge.net Thu Nov 13 16:06:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 16:06:14 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-13 22:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 14:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 08:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 21:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 20:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Thu Nov 13 16:13:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 16:13:31 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-13 22:13 Message: Logged In: YES user_id=11105 Applied your patch, very cool! This problem doesn't occur any more, it seems. But this was only after a short test with my application. I will patch the 2.3 branch and test more extensively with this one tomorrow. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 22:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 14:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 08:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 21:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 20:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Thu Nov 13 16:43:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 16:43:39 2003 Subject: [ python-Bugs-841757 ] xmlrpclib chokes on Unicode keys Message-ID: Bugs item #841757, was opened at 2003-11-13 22: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=841757&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib chokes on Unicode keys Initial Comment: the type check in dump_struct is too strict; I suggest changing the loop to: for k, v in value.items(): write("\n") if type(k) is UnicodeType: k = k.encode(self.encoding) elif type(k) is not StringType: raise TypeError, "dictionary key must be string" write("%s\n" % escape(k)) dump(v, write) write("\n") ths applies to all Python versions since 2.2. backport as necessary. regards /F ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 From noreply at sourceforge.net Thu Nov 13 17:00:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 17:01:04 2003 Subject: [ python-Bugs-841757 ] xmlrpclib chokes on Unicode keys Message-ID: Bugs item #841757, was opened at 2003-11-13 22:43 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib chokes on Unicode keys Initial Comment: the type check in dump_struct is too strict; I suggest changing the loop to: for k, v in value.items(): write("\n") if type(k) is UnicodeType: k = k.encode(self.encoding) elif type(k) is not StringType: raise TypeError, "dictionary key must be string" write("%s\n" % escape(k)) dump(v, write) write("\n") ths applies to all Python versions since 2.2. backport as necessary. regards /F ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-11-13 23:00 Message: Logged In: YES user_id=38376 to avoid a performance hit for existing code, the type test is better written as: if type(k) is not StringType: if unicode and type(k) is UnicodeType: k = k.encode(self.encoding) else: raise TypeError, "dictionary key must be string" (this also works under 1.5.2) (see attachment for a more readable "patch"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 From noreply at sourceforge.net Thu Nov 13 17:10:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 17:11:02 2003 Subject: [ python-Bugs-841757 ] xmlrpclib chokes on Unicode keys Message-ID: Bugs item #841757, was opened at 2003-11-13 15:43 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Skip Montanaro (montanaro) Summary: xmlrpclib chokes on Unicode keys Initial Comment: the type check in dump_struct is too strict; I suggest changing the loop to: for k, v in value.items(): write("\n") if type(k) is UnicodeType: k = k.encode(self.encoding) elif type(k) is not StringType: raise TypeError, "dictionary key must be string" write("%s\n" % escape(k)) dump(v, write) write("\n") ths applies to all Python versions since 2.2. backport as necessary. regards /F ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-11-13 16:10 Message: Logged In: YES user_id=44345 I long ago got tired of Dave Wiener's stance on the XML-RPC protocol and got off any mailing lists he participated in, but I seem to recall that he was adamant about not allowing anything but ASCII characters. Accordingly, either Unicode encodings would be verboten or some other transformation should be applied to them to make them truly ASCII (like % encoding them). Has Dave's position on whether or not to accept non-ASCII on the wire changed? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-11-13 16:00 Message: Logged In: YES user_id=38376 to avoid a performance hit for existing code, the type test is better written as: if type(k) is not StringType: if unicode and type(k) is UnicodeType: k = k.encode(self.encoding) else: raise TypeError, "dictionary key must be string" (this also works under 1.5.2) (see attachment for a more readable "patch"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 From noreply at sourceforge.net Thu Nov 13 17:23:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 17:24:03 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:23 Message: Logged In: YES user_id=31435 Good! I hoped it would fix it, but it's not the best way to fix it. I've checked in a better way, so please test against the current CVS trunk. I'll backport that to the 2.3 maint branch too, but later today. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:13 Message: Logged In: YES user_id=11105 Applied your patch, very cool! This problem doesn't occur any more, it seems. But this was only after a short test with my application. I will patch the 2.3 branch and test more extensively with this one tomorrow. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 08:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 02:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 15:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Thu Nov 13 17:29:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 17:30:53 2003 Subject: [ python-Bugs-841757 ] xmlrpclib chokes on Unicode keys Message-ID: Bugs item #841757, was opened at 2003-11-13 22:43 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Skip Montanaro (montanaro) Summary: xmlrpclib chokes on Unicode keys Initial Comment: the type check in dump_struct is too strict; I suggest changing the loop to: for k, v in value.items(): write("\n") if type(k) is UnicodeType: k = k.encode(self.encoding) elif type(k) is not StringType: raise TypeError, "dictionary key must be string" write("%s\n" % escape(k)) dump(v, write) write("\n") ths applies to all Python versions since 2.2. backport as necessary. regards /F ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-11-13 23:29 Message: Logged In: YES user_id=38376 The XML-RPC specification wasn't exactly clear on this issue, and was changed earlier this year. See http://www.effbot.org/zone/xmlrpc-errata.htm http://www.effbot.org/zone/xmlrpc-ascii.htm And even if the spec hadn't been changed, xmlrpclib has always "done the right thing" with Unicode strings in all other cases. Trust me, I wrote the code, so I should know ;-) ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-11-13 23:10 Message: Logged In: YES user_id=44345 I long ago got tired of Dave Wiener's stance on the XML-RPC protocol and got off any mailing lists he participated in, but I seem to recall that he was adamant about not allowing anything but ASCII characters. Accordingly, either Unicode encodings would be verboten or some other transformation should be applied to them to make them truly ASCII (like % encoding them). Has Dave's position on whether or not to accept non-ASCII on the wire changed? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-11-13 23:00 Message: Logged In: YES user_id=38376 to avoid a performance hit for existing code, the type test is better written as: if type(k) is not StringType: if unicode and type(k) is UnicodeType: k = k.encode(self.encoding) else: raise TypeError, "dictionary key must be string" (this also works under 1.5.2) (see attachment for a more readable "patch"). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841757&group_id=5470 From noreply at sourceforge.net Thu Nov 13 17:55:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 17:57:10 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:55 Message: Logged In: YES user_id=31435 What I hope is the last fix for this class of bug has been checked in on release23-maint too, so feel free to use that for testing instead. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:23 Message: Logged In: YES user_id=31435 Good! I hoped it would fix it, but it's not the best way to fix it. I've checked in a better way, so please test against the current CVS trunk. I'll backport that to the 2.3 maint branch too, but later today. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:13 Message: Logged In: YES user_id=11105 Applied your patch, very cool! This problem doesn't occur any more, it seems. But this was only after a short test with my application. I will patch the 2.3 branch and test more extensively with this one tomorrow. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 08:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 02:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 15:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Thu Nov 13 17:57:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 17:57:50 2003 Subject: [ python-Bugs-841180 ] incorrect Debian info in FAQ Message-ID: Bugs item #841180, was opened at 2003-11-12 23:31 Message generated for change (Comment added) made by nestler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841180&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ivan Nestlerode (nestler) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect Debian info in FAQ Initial Comment: In the Extending/Embedding FAQ at http://www.python.org/doc/faq/extending.html, under question 14 (I want to compile a Python module on my Linux system...), you say: For Debian, run apt-get install python-devel The problem is that Debian's Python development package is called python-dev, not python-devel. -Ivan ---------------------------------------------------------------------- >Comment By: Ivan Nestlerode (nestler) Date: 2003-11-13 17:57 Message: Logged In: YES user_id=424120 This has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841180&group_id=5470 From noreply at sourceforge.net Thu Nov 13 18:00:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 13 18:00:57 2003 Subject: [ python-Bugs-841800 ] -O breaks bundlebuilder --standalone Message-ID: Bugs item #841800, was opened at 2003-11-13 18: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=841800&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Swerdlow (swerdlow) Assigned to: Jack Jansen (jackjansen) Summary: -O breaks bundlebuilder --standalone Initial Comment: Just van Rossum suggested I file this bug report: When building with python -O buildapp.py -v --standalone -- package=encodings --package=_strpTime --packag e=urllib2 build I got these errors: 'import site' failed; use -v for traceback Traceback(most recent call last): file "./build/MyApp.app/Contents/Resources/myapp.py", line 6, in ? import copy ImportError: No module named copy The "import copy" problem is simply cascaded off the "import site" problem. A site.pyo file was generated in the /build/MyApp.app/Contents/Resources/folder, but it is obviously not being used properly. To get it to work, I first built the application without the -O flag, saved the site.pyc file, then built it again with the -O flag and restored the site.pyc file. With this hack, the application works fine. Just responded: I think you need to hack the bootstrap script by adding sys.argv.insert(1, "-O") after this line: sys.argv.insert(1, mainprogram) He also asked if -O was really worth the trouble, but that should be the programmer's decision, not the framework's. bundlebuilder should support --standalone with -O. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841800&group_id=5470 From noreply at sourceforge.net Fri Nov 14 04:12:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 04:13:01 2003 Subject: [ python-Bugs-841800 ] -O breaks bundlebuilder --standalone Message-ID: Bugs item #841800, was opened at 2003-11-14 00:00 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841800&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Swerdlow (swerdlow) >Assigned to: Just van Rossum (jvr) Summary: -O breaks bundlebuilder --standalone Initial Comment: Just van Rossum suggested I file this bug report: When building with python -O buildapp.py -v --standalone -- package=encodings --package=_strpTime --packag e=urllib2 build I got these errors: 'import site' failed; use -v for traceback Traceback(most recent call last): file "./build/MyApp.app/Contents/Resources/myapp.py", line 6, in ? import copy ImportError: No module named copy The "import copy" problem is simply cascaded off the "import site" problem. A site.pyo file was generated in the /build/MyApp.app/Contents/Resources/folder, but it is obviously not being used properly. To get it to work, I first built the application without the -O flag, saved the site.pyc file, then built it again with the -O flag and restored the site.pyc file. With this hack, the application works fine. Just responded: I think you need to hack the bootstrap script by adding sys.argv.insert(1, "-O") after this line: sys.argv.insert(1, mainprogram) He also asked if -O was really worth the trouble, but that should be the programmer's decision, not the framework's. bundlebuilder should support --standalone with -O. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=841800&group_id=5470 From noreply at sourceforge.net Fri Nov 14 05:40:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 05:40:59 2003 Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 21:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-14 11:40 Message: Logged In: YES user_id=45365 I think that either the module itself, or the package responsible for the module, should forestall unloading (by tucking away an extra reference somewhere). The root of the problem is that the Python refcount doesn't reflect the all references to the module: ObjC keeps references too. OTOH: if all modules containing ObjC code have this problem, and it is easy to detect whether a module contains ObjC code then adding a safety net to the import code might be a prudent course of action. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 16:16 Message: Logged In: YES user_id=45365 I'm surprised that it does the unload:-) I think the correct solution would be for the module itself (or someone close to it) to stash away a reference. As this is only a problem for some modules (those containing ObjC code) I don't think a general change is in order. The real problem is that the "last reference" as Python sees it isn't really the last reference: the ObjC runtime also has references to stuff in there. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-11 15:20 Message: Logged In: YES user_id=139309 it does if you del sys.modules['somemodule'] and somemodule's reference count goes to zero. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 11:51 Message: Logged In: YES user_id=45365 Bob, I'm confused. As far as I know Python never unloads extension modules... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Fri Nov 14 08:58:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 08:58:19 2003 Subject: [ python-Bugs-842116 ] PackMan database for panther misses devtools dep Message-ID: Bugs item #842116, was opened at 2003-11-14 14: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=842116&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan database for panther misses devtools dep Initial Comment: On Panther the Python headers are part of the BSD SDK. The PackMan database currently only checks for the devtools core being installed, it should also check the BSD SDK, which include Python.h and the other include files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842116&group_id=5470 From noreply at sourceforge.net Fri Nov 14 10:38:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 10:39:01 2003 Subject: [ python-Bugs-842170 ] logging.shutdown() exception Message-ID: Bugs item #842170, was opened at 2003-11-14 15: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=842170&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: j vickroy (jvickroy) Assigned to: Nobody/Anonymous (nobody) Summary: logging.shutdown() exception Initial Comment: Python version: Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Operating System: MS Windows 2000 Professional with all latest patches Synopsis: When reassigning a handler (RotatingFileSystem) to a logger during execution, close() must be invoked against the current handler. Failure to do so causes the following exception to be raised: Traceback (most recent call last): File "C:\Python23\lib\site- packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "E:\\experimental\Py Logging\t_xc.py", line 61, in ? log.error('testing Python logging module') File "C:\Python23\lib\logging\__init__.py", line 923, in error apply(self._log, (ERROR, msg, args), kwargs) File "C:\Python23\lib\logging\__init__.py", line 994, in _log self.handle(record) File "C:\Python23\lib\logging\__init__.py", line 1004, in handle self.callHandlers(record) File "C:\Python23\lib\logging\__init__.py", line 1037, in callHandlers hdlr.handle(record) File "C:\Python23\lib\logging\__init__.py", line 592, in handle self.emit(record) File "C:\Python23\lib\logging\handlers.py", line 105, in emit self.doRollover() File "C:\Python23\lib\logging\handlers.py", line 90, in doRollover os.rename(self.baseFilename, dfn) OSError: [Errno 13] Permission denied If close() is applied to each handler, except the final assigned handler, then logging.shutdown() raises the following exception when it is applied prior to application termination: Traceback (most recent call last): File "D:\\experimental\Py Logging\t_xb.py", line 63, in ? shutdown() File "C:\Python23\lib\logging\__init__.py", line 1195, in shutdown h.flush() File "C:\Python23\lib\logging\__init__.py", line 661, in flush self.stream.flush() ValueError: I/O operation on closed file apparently, because it is attempting to close previously- closed handlers. Please, see attachment for a relevant script. If it is agreed that this is an appropriate use of the logging system (and I think it is ), I would be willing to attempt a patch if that is preferable. Thanks for your time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842170&group_id=5470 From noreply at sourceforge.net Fri Nov 14 10:44:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 10:44:46 2003 Subject: [ python-Bugs-842171 ] Digital Unix build fails to create ccpython.o Message-ID: Bugs item #842171, was opened at 2003-11-14 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Janet Goldstein (perlgrrl) Assigned to: Nobody/Anonymous (nobody) Summary: Digital Unix build fails to create ccpython.o Initial Comment: I am attempting to install Python 2.3.2 on Digital Unix V40.E (Revision 1091). The make goes nearly all the way through, then crashes: Can't open Modules/ccpython.o (No such file or directory) The same thing happens with Python 2.3.1 and 2.1.3. The configure command I used was ./configure --with-cxx=/usr/bin/cc --without-gcc (I know what you're thinking: try it with gcc. Well, I tried building gcc, and it gave me even more problems than Python.) The Makefile is attached. Thank you for any enlightenment you can provide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 From noreply at sourceforge.net Fri Nov 14 11:33:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 11:33:34 2003 Subject: [ python-Bugs-842213 ] optparser help formatting nit Message-ID: Bugs item #842213, was opened at 2003-11-14 11:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842213&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Greg Ward (gward) Summary: optparser help formatting nit Initial Comment: When printing help from an optparse.OptParser in a XEmacs shell buffer, the option text is wrapped one character too wide. I've taken to doing something like this in my code: parser.formatter.width -= 1 parser.formatter.help_width -= 1 which is ugly. I think the default is to wrap to 80 characters. It should wrap to 79 characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842213&group_id=5470 From noreply at sourceforge.net Fri Nov 14 19:17:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 19:18:21 2003 Subject: [ python-Bugs-210698 ] strptime gives format mismatch when time zone present (PR#164) Message-ID: Bugs item #210698, was opened at 2000-07-31 14:29 Message generated for change (Comment added) made by trewitt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=210698&group_id=5470 Category: None Group: Platform-specific Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: strptime gives format mismatch when time zone present (PR#164) Initial Comment: Jitterbug-Id: 164 Submitted-By: python-bugreport@derf.net Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST) Version: 1.5.2 OS: RedHat 5.2; Linux 2.2.12 time.strptime() seems to fail when the time zone ('%Z') appears in the format string. when it is omitted from the format string (and from the string being parsed), strptime() works fine. here is a sample script which demonstrates the bug: ------ #!/usr/bin/python import time timetuple0 = time.localtime(time.time()) print timetuple0 format1 = '%a %b %d %H:%M:%S %Y' timestring1 = time.strftime( format1 , timetuple0 ) print timestring1 timetuple1 = time.strptime( timestring1 , format1 ) print timetuple1 format2 = '%a %b %d %H:%M:%S %Z %Y' timestring2 = time.strftime( format2 , timetuple0 ) print timestring2 timetuple2 = time.strptime( timestring2 , format2 ) print timetuple2 ------ when i run the above, i get the following output: ------ (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 1999 (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 PST 1999 Traceback (innermost last): File "./test.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ------ ==================================================================== Audit trail: Tue Dec 21 11:47:04 1999 guido changed notes Tue Dec 21 11:47:05 1999 guido moved from incoming to platformbug ---------------------------------------------------------------------- Comment By: Glenn Trewitt (trewitt) Date: 2003-11-14 16:17 Message: Logged In: YES user_id=230628 I get the same error *for some builds*. I'm using Redhat 9, and the bug shows up in (I think) the stock Python 2.2. If I compile 2.3.2 from source, it works fine. (2003, 11, 14, 16, 3, 22, 4, 318, 0) Fri Nov 14 16:03:22 2003 (2003, 11, 14, 16, 3, 22, 4, 318, 0) Fri Nov 14 16:03:22 PST 2003 Traceback (most recent call last): File "timep.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-08 09:13 Message: Closed it, as it's not a Python bug but a bug in the platform libc (if a non-std fnc can be called "buggy" at all ...). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2000-09-08 05:27 Message: FYI, you could check out mxDateTime which provides a parser for various date/time formats instead of waiting for your strptime() C API to get fixed. mxDateTime is available at http://starship.python.net/~lemburg/. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:06 Message: Please do triage on this bug. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:03 Message: The C library strptime() needs fixin'. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:03 Message: From: Guido van Rossum Subject: Re: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164) Date: Tue, 21 Dec 1999 09:12:15 -0500 > time.strptime() seems to fail when the time zone ('%Z') appears in > the format string. when it is omitted from the format string (and > from the string being parsed), strptime() works fine. Reporting this as a Python bug is not going to fix it. The time.strptime() function in Python is a very thin wrapper around the strptime() function in the C library. We get a lot of complaints about this, but there's no way that we're able to fix this -- it's the C strptime() function that needs to be fixed. Write to your friendly Linux support people! --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=210698&group_id=5470 From noreply at sourceforge.net Fri Nov 14 23:04:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 23:04:31 2003 Subject: [ python-Bugs-210698 ] strptime gives format mismatch when time zone present (PR#164) Message-ID: Bugs item #210698, was opened at 2000-07-31 14:29 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=210698&group_id=5470 Category: None Group: Platform-specific Status: Closed Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: strptime gives format mismatch when time zone present (PR#164) Initial Comment: Jitterbug-Id: 164 Submitted-By: python-bugreport@derf.net Date: Tue, 21 Dec 1999 08:27:27 -0500 (EST) Version: 1.5.2 OS: RedHat 5.2; Linux 2.2.12 time.strptime() seems to fail when the time zone ('%Z') appears in the format string. when it is omitted from the format string (and from the string being parsed), strptime() works fine. here is a sample script which demonstrates the bug: ------ #!/usr/bin/python import time timetuple0 = time.localtime(time.time()) print timetuple0 format1 = '%a %b %d %H:%M:%S %Y' timestring1 = time.strftime( format1 , timetuple0 ) print timestring1 timetuple1 = time.strptime( timestring1 , format1 ) print timetuple1 format2 = '%a %b %d %H:%M:%S %Z %Y' timestring2 = time.strftime( format2 , timetuple0 ) print timestring2 timetuple2 = time.strptime( timestring2 , format2 ) print timetuple2 ------ when i run the above, i get the following output: ------ (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 1999 (1999, 12, 21, 5, 25, 35, 1, 355, 0) Tue Dec 21 05:25:35 PST 1999 Traceback (innermost last): File "./test.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ------ ==================================================================== Audit trail: Tue Dec 21 11:47:04 1999 guido changed notes Tue Dec 21 11:47:05 1999 guido moved from incoming to platformbug ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-11-14 20:04 Message: Logged In: YES user_id=357491 2.3 switched over to a pure Python implementation of strptime that makes the behavior predictable and testable. Thanks for the info anyway, trewitt. ---------------------------------------------------------------------- Comment By: Glenn Trewitt (trewitt) Date: 2003-11-14 16:17 Message: Logged In: YES user_id=230628 I get the same error *for some builds*. I'm using Redhat 9, and the bug shows up in (I think) the stock Python 2.2. If I compile 2.3.2 from source, it works fine. (2003, 11, 14, 16, 3, 22, 4, 318, 0) Fri Nov 14 16:03:22 2003 (2003, 11, 14, 16, 3, 22, 4, 318, 0) Fri Nov 14 16:03:22 PST 2003 Traceback (most recent call last): File "timep.py", line 17, in ? timetuple2 = time.strptime( timestring2 , format2 ) ValueError: format mismatch ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-08 09:13 Message: Closed it, as it's not a Python bug but a bug in the platform libc (if a non-std fnc can be called "buggy" at all ...). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2000-09-08 05:27 Message: FYI, you could check out mxDateTime which provides a parser for various date/time formats instead of waiting for your strptime() C API to get fixed. mxDateTime is available at http://starship.python.net/~lemburg/. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2000-09-07 15:06 Message: Please do triage on this bug. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:03 Message: The C library strptime() needs fixin'. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-01 14:03 Message: From: Guido van Rossum Subject: Re: [Python-bugs-list] strptime gives format mismatch when time zone present (PR#164) Date: Tue, 21 Dec 1999 09:12:15 -0500 > time.strptime() seems to fail when the time zone ('%Z') appears in > the format string. when it is omitted from the format string (and > from the string being parsed), strptime() works fine. Reporting this as a Python bug is not going to fix it. The time.strptime() function in Python is a very thin wrapper around the strptime() function in the C library. We get a lot of complaints about this, but there's no way that we're able to fix this -- it's the C strptime() function that needs to be fixed. Write to your friendly Linux support people! --Guido van Rossum (home page: http://www.python.org/~guido/) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=210698&group_id=5470 From noreply at sourceforge.net Fri Nov 14 23:46:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 14 23:46:53 2003 Subject: [ python-Bugs-842600 ] xmlrpclib and backward compatibility Message-ID: Bugs item #842600, was opened at 2003-11-15 13:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842600&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: xmlrpclib and backward compatibility Initial Comment: This bug is related to patch #531629 "Add multicall support to xmlrpclib" http://www.python.org/sf/531629 His applied patch includes 'yield' statement. Is this OK? I think xmlrpclib.py needs to keep compatible with older Python. On the top of xmlrpclib.py there is a note: # this version is designed to work with Python 1.5.2 or newer. I attached a patch to avoid 'yield' but this is a quick fix. I'm not sure if this is the right approach. There should be a better solution. I've also changed the coding style of the previous change to be consistent with other parts of this script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842600&group_id=5470 From noreply at sourceforge.net Sat Nov 15 02:44:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 15 02:44:52 2003 Subject: [ python-Bugs-842629 ] Windows mis-installs to network drive Message-ID: Bugs item #842629, was opened at 2003-11-14 23:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Sloyer (dsloyer) Assigned to: Nobody/Anonymous (nobody) Summary: Windows mis-installs to network drive Initial Comment: Installing: python-2.3.2-1.exe /S where the current working directory is on a network drive causes Python 2.3 to mis-install on the network drive, instead of the system drive (C:). The installation takes a long time to run. I observed this on Windows XP SP1, with all current security patches applied (thru MS03-049). The problem occurred on multiple machines. The servers is both cases were Windows 2000 servers, sharing a drive with the workstation. Python 2.3 shows up in Add/Remove Programs, but cannot be removed, except by hand. Copying the installer to the local C: drive, and running the command from there, was successful in silently, and correctly, installing Python 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 From noreply at sourceforge.net Sat Nov 15 10:14:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 15 10:14:10 2003 Subject: [ python-Bugs-842171 ] Digital Unix build fails to create ccpython.o Message-ID: Bugs item #842171, was opened at 2003-11-14 10:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Janet Goldstein (perlgrrl) Assigned to: Nobody/Anonymous (nobody) Summary: Digital Unix build fails to create ccpython.o Initial Comment: I am attempting to install Python 2.3.2 on Digital Unix V40.E (Revision 1091). The make goes nearly all the way through, then crashes: Can't open Modules/ccpython.o (No such file or directory) The same thing happens with Python 2.3.1 and 2.1.3. The configure command I used was ./configure --with-cxx=/usr/bin/cc --without-gcc (I know what you're thinking: try it with gcc. Well, I tried building gcc, and it gave me even more problems than Python.) The Makefile is attached. Thank you for any enlightenment you can provide. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-15 10:14 Message: Logged In: YES user_id=33168 Did you try either of these: ./configure --without-gcc ./configure --without-cxx --without-gcc ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 From noreply at sourceforge.net Sun Nov 16 14:29:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 14:29:19 2003 Subject: [ python-Bugs-843293 ] inconsistent popen[2-4]() docs Message-ID: Bugs item #843293, was opened at 2003-11-16 19: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=843293&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Velichansky (hmaon) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent popen[2-4]() docs Initial Comment: http://python.org/doc/current/lib/module-popen2.html and http://python.org/doc/current/lib/os-newstreams.html#os-newstreams apparently list different arguments for popen2(), popen3(), popen4() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843293&group_id=5470 From noreply at sourceforge.net Sun Nov 16 18:05:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 18:05:19 2003 Subject: [ python-Bugs-843385 ] help(obj) should use __doc__ when available Message-ID: Bugs item #843385, was opened at 2003-11-16 15:05 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=843385&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Robert Kern (kern) Assigned to: Nobody/Anonymous (nobody) Summary: help(obj) should use __doc__ when available Initial Comment: Suppose one makes a C extension type that is callable and has a __doc__ attribute. Currently, calling help() on the object yields something like the following: >>> help(scipy.linalg._flinalg.slu_c) Help on fortran: >>> hasattr(scipy.linalg._flinalg.slu_c, '__doc__') True >>> help() could give more useful information by modifying pydoc.TextDoc.docother to check for a __doc__ attribute and add it (just as docother checks for the 'doc' keyword). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843385&group_id=5470 From noreply at sourceforge.net Sun Nov 16 22:23:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 22:23:05 2003 Subject: [ python-Bugs-839548 ] Bug in type's GC handling causes segfaults Message-ID: Bugs item #839548, was opened at 2003-11-10 16:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim Fulton (dcjim) >Assigned to: Tim Peters (tim_one) Summary: Bug in type's GC handling causes segfaults Initial Comment: type has a bug in it's GC "clear" function, type_clear. It sets tp->mro to NULL, but other code (especially PyObject_GenericGetAttr) assumes that tp_mro cannot be null. A class participating in a cycle may have clear called while there are still instances around. If someone tries to do a getattr on such an instance, python will crach with a segfault or with an assertion error. A simple fix is for clear to set tp_mro to an empty tuple, which breaks the cycle without breaking the invariant. A patch is attached. I encountered this in Zope 3 after adding a new interface implementation that made heavy use of weakrefs. Often Zope 3 would segfault when exiting. The patch fixes this. Unfortunately, I was not able, in the time available, to come up with a simpler test case. :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-16 22:23 Message: Logged In: YES user_id=31435 Assigned to me. Please see patch 843455, which should repair the problem, but via a different route: the underlying problem is that gc never expected that arbitrary Python code could run while gc is running. A lot of bad things can go wrong. But weakref callbacks have enough nice exploitable properties that I think it's possible for gc to run them if it's made acutely aware of them, and the patch does that, ensuring that a callback (or even later Python code, if a callback resurrects dead objects in cycles) never sees an object on which tp_clear() has been run. In particular, then, in your callback the __mro__ won't be NULL -- or anything else surprising (it will be what you expect the class's __mro__ to be). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 From noreply at sourceforge.net Sun Nov 16 23:36:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 23:36:29 2003 Subject: [ python-Bugs-828049 ] Idle fails on loading .idlerc if Home path changes. Message-ID: Bugs item #828049, was opened at 2003-10-22 02:57 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828049&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Frithiof Andreas Jensen (fajensen) >Assigned to: Kurt B. Kaiser (kbk) Summary: Idle fails on loading .idlerc if Home path changes. Initial Comment: I have a Windows laptop. Normally it resides in a docking station, meaing my Home directory is referenced from a network drive labelled 'H:' When I Eject the labtop my home directory by scripted magick becomes referenced off 'C:' If I have Idle running already and start a new Idle window, the new window will fail, raising a FileError exception over not finding the '.idlerc' at 'H:' - which it cannot because it disapeared. If I do not have Idle running and start it after undocking, it will fail silently never bringing up a window. I suspect for the same reason: The home drive changes but the change is not reflected in the information available to Python/Idle. Maybe it is possible to search for a valid path when the first (cached?) attempt fails - or maybe a workaround could be to raise a Warning instead of an Exception, letting the user decide? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:36 Message: Logged In: YES user_id=149084 Hm, changing the system config underneath IDLE? I'm not surprised it gets confused :-) Although this is a rather special case, I think that you should be able to make IDLE do what you want by modifying configHandler.py:IdleConf.GetUserCfgDir() to "do the right thing." I'm a little more mystified by the second case where IDLE isn't running when you undock. If it can't find .idlerc it should create it. You say IDLE never starts at all? Please start IDLE from a command window and see what error messages are printed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828049&group_id=5470 From noreply at sourceforge.net Sun Nov 16 23:56:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 16 23:56:09 2003 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 19:27 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 23:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Mon Nov 17 04:29:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 04:29:05 2003 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 20:29 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=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Mon Nov 17 05:12:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 05:12:11 2003 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 10:29 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-17 11:12 Message: Logged In: YES user_id=38388 Are you sure ? The decoded string you give does not look like anything readable... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Mon Nov 17 05:47:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 05:47:29 2003 Subject: [ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman' Message-ID: Feature Requests item #843590, was opened at 2003-11-17 20:29 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: 'macintosh' encoding alias for 'mac_roman' Initial Comment: OS X's Mail.app can generate Subject lines like: Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?= (Which decodes to '\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb c') This appears to be what Python calls the mac_roman encoding. I suggest adding 'macintosh' as an alias to 'mac_roman' to encodings/aliases.py to allow the email package to decode these headers. ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-11-17 21:47 Message: Logged In: YES user_id=46639 The test was just a sequence of random high-bit characters: ?????????????? (lets see if the web interface lets that through). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-11-17 21:12 Message: Logged In: YES user_id=38388 Are you sure ? The decoded string you give does not look like anything readable... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=843590&group_id=5470 From noreply at sourceforge.net Mon Nov 17 08:38:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 08:38:54 2003 Subject: [ python-Bugs-842171 ] Digital Unix build fails to create ccpython.o Message-ID: Bugs item #842171, was opened at 2003-11-14 10:44 Message generated for change (Comment added) made by perlgrrl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Janet Goldstein (perlgrrl) Assigned to: Nobody/Anonymous (nobody) Summary: Digital Unix build fails to create ccpython.o Initial Comment: I am attempting to install Python 2.3.2 on Digital Unix V40.E (Revision 1091). The make goes nearly all the way through, then crashes: Can't open Modules/ccpython.o (No such file or directory) The same thing happens with Python 2.3.1 and 2.1.3. The configure command I used was ./configure --with-cxx=/usr/bin/cc --without-gcc (I know what you're thinking: try it with gcc. Well, I tried building gcc, and it gave me even more problems than Python.) The Makefile is attached. Thank you for any enlightenment you can provide. ---------------------------------------------------------------------- >Comment By: Janet Goldstein (perlgrrl) Date: 2003-11-17 08:38 Message: Logged In: YES user_id=908617 The build finally worked when I used the second configure command you recommended: ./configure --without-cxx --without-gcc Thank you for your help! This is what happened when I ran make test: 212 tests OK. 10 tests failed: test_fcntl test_format test_nis test_openpty test_poll test_popen test_popen2 test_pty test_select test_tempfile 33 tests skipped: test_aepack test_al test_audioop test_bsddb test_bsddb3 test_bz2 test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imageop test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_normalization test_ossaudiodev test_pep277 test_plistlib test_rgbimg test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on osf1V4. *** Exit 1 Stop. Fortunately, make install worked anyway. Thanks again! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-15 10:14 Message: Logged In: YES user_id=33168 Did you try either of these: ./configure --without-gcc ./configure --without-cxx --without-gcc ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 From noreply at sourceforge.net Mon Nov 17 11:04:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 11:06:08 2003 Subject: [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 16:27 Message generated for change (Comment added) made by urnerk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- >Comment By: Kirby Urner (urnerk) Date: 2003-11-17 08:04 Message: Logged In: YES user_id=191709 I'm using WinXP Pro. Given this has not previously been reported, I will do my best to gather data on your questions as I continue to use IDLE. Ideally, I will be able to duplicate it at will. We shall see. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-16 20:56 Message: Logged In: YES user_id=149084 I haven't observed this behavior, nor heard of it before. What version of Windows are you using? The keybindings are established in Tk just after IDLE starts and are subsequently intercepted and handled by the Tk library. Do all the Ctrl bindings fail? Even Tk defaults like Ctrl-E, which goes to end of line? What about Alt bindings? Do the Ctrl keys work in other applications after they stop working in IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Mon Nov 17 16:29:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 16:29:42 2003 Subject: [ python-Bugs-843999 ] tkFileDialog.Open is broken Message-ID: Bugs item #843999, was opened at 2003-11-17 13:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843999&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.Open is broken Initial Comment: tkFileDialog.Open is broken, apparently due to the new object interface. Try the following: >>> import Tkinter >>> import tkFileDialog >>> root = Tkinter.Tk() >>> tkFileDialog.askopenfilename() Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFileDialog.py", line 89, in _fixresult if not widget.tk.wantobjects() and "multiple" in self.options: TypeError: wantobjects() takes exactly 1 argument (0 given) >>> Looking at the code, tkFileDialog.Open _fixresult is calling widget.tk.wantobjects() and apparently that function always wants an argument (though one would not necessarily think so from the function name, so the bug is not surprising). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843999&group_id=5470 From noreply at sourceforge.net Mon Nov 17 21:14:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 21:14:34 2003 Subject: [ python-Bugs-844123 ] "up" instead of "down" in turtle module documentation Message-ID: Bugs item #844123, was opened at 2003-11-17 20: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=844123&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: "up" instead of "down" in turtle module documentation Initial Comment: At: http://www.python.org/doc/current/lib/module-turtle.html it says: down() Move the pen up -- draw when moving. which should be "Move the pen down...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844123&group_id=5470 From noreply at sourceforge.net Mon Nov 17 23:42:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 17 23:42:35 2003 Subject: [ python-Bugs-843999 ] tkFileDialog.Open is broken Message-ID: Bugs item #843999, was opened at 2003-11-17 16:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843999&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Martin v. L?wis (loewis) Summary: tkFileDialog.Open is broken Initial Comment: tkFileDialog.Open is broken, apparently due to the new object interface. Try the following: >>> import Tkinter >>> import tkFileDialog >>> root = Tkinter.Tk() >>> tkFileDialog.askopenfilename() Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFileDialog.py", line 119, in askopenfilename return Open(**options).show() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/lib-tk/tkFileDialog.py", line 89, in _fixresult if not widget.tk.wantobjects() and "multiple" in self.options: TypeError: wantobjects() takes exactly 1 argument (0 given) >>> Looking at the code, tkFileDialog.Open _fixresult is calling widget.tk.wantobjects() and apparently that function always wants an argument (though one would not necessarily think so from the function name, so the bug is not surprising). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-17 23:42 Message: Logged In: YES user_id=33168 What version of Python are you using? I just looked at the code for 2.3.2 and tested it. 2.3.2 works fine. Perhaps this bug has already been fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=843999&group_id=5470 From noreply at sourceforge.net Tue Nov 18 07:32:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 07:32:21 2003 Subject: [ python-Bugs-844336 ] urllib2 fails its builtin test Message-ID: Bugs item #844336, was opened at 2003-11-18 07: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=844336&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 From noreply at sourceforge.net Tue Nov 18 08:30:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 08:30:42 2003 Subject: [ python-Bugs-842171 ] Digital Unix build fails to create ccpython.o Message-ID: Bugs item #842171, was opened at 2003-11-14 10:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Janet Goldstein (perlgrrl) Assigned to: Nobody/Anonymous (nobody) Summary: Digital Unix build fails to create ccpython.o Initial Comment: I am attempting to install Python 2.3.2 on Digital Unix V40.E (Revision 1091). The make goes nearly all the way through, then crashes: Can't open Modules/ccpython.o (No such file or directory) The same thing happens with Python 2.3.1 and 2.1.3. The configure command I used was ./configure --with-cxx=/usr/bin/cc --without-gcc (I know what you're thinking: try it with gcc. Well, I tried building gcc, and it gave me even more problems than Python.) The Makefile is attached. Thank you for any enlightenment you can provide. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-18 08:30 Message: Logged In: YES user_id=33168 Is there anything that should be done or can this bug report be closed? As for the failed tests, it looks like socket and select modules didn't build. Probably others. I doubt anyone has access to a box with dec unix 4. So you will probably need to resolve these problems yourself. ---------------------------------------------------------------------- Comment By: Janet Goldstein (perlgrrl) Date: 2003-11-17 08:38 Message: Logged In: YES user_id=908617 The build finally worked when I used the second configure command you recommended: ./configure --without-cxx --without-gcc Thank you for your help! This is what happened when I ran make test: 212 tests OK. 10 tests failed: test_fcntl test_format test_nis test_openpty test_poll test_popen test_popen2 test_pty test_select test_tempfile 33 tests skipped: test_aepack test_al test_audioop test_bsddb test_bsddb3 test_bz2 test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imageop test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_normalization test_ossaudiodev test_pep277 test_plistlib test_rgbimg test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on osf1V4. *** Exit 1 Stop. Fortunately, make install worked anyway. Thanks again! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-15 10:14 Message: Logged In: YES user_id=33168 Did you try either of these: ./configure --without-gcc ./configure --without-cxx --without-gcc ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 From noreply at sourceforge.net Tue Nov 18 08:34:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 08:34:55 2003 Subject: [ python-Bugs-842171 ] Digital Unix build fails to create ccpython.o Message-ID: Bugs item #842171, was opened at 2003-11-15 02:44 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Janet Goldstein (perlgrrl) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Digital Unix build fails to create ccpython.o Initial Comment: I am attempting to install Python 2.3.2 on Digital Unix V40.E (Revision 1091). The make goes nearly all the way through, then crashes: Can't open Modules/ccpython.o (No such file or directory) The same thing happens with Python 2.3.1 and 2.1.3. The configure command I used was ./configure --with-cxx=/usr/bin/cc --without-gcc (I know what you're thinking: try it with gcc. Well, I tried building gcc, and it gave me even more problems than Python.) The Makefile is attached. Thank you for any enlightenment you can provide. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-19 00:34 Message: Logged In: YES user_id=29957 Pretty sure there's a Digital Unix 4.0 box in the HP testdrive farm. I'll look into it in a few weeks if no-one gets to it before then. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-19 00:30 Message: Logged In: YES user_id=33168 Is there anything that should be done or can this bug report be closed? As for the failed tests, it looks like socket and select modules didn't build. Probably others. I doubt anyone has access to a box with dec unix 4. So you will probably need to resolve these problems yourself. ---------------------------------------------------------------------- Comment By: Janet Goldstein (perlgrrl) Date: 2003-11-18 00:38 Message: Logged In: YES user_id=908617 The build finally worked when I used the second configure command you recommended: ./configure --without-cxx --without-gcc Thank you for your help! This is what happened when I ran make test: 212 tests OK. 10 tests failed: test_fcntl test_format test_nis test_openpty test_poll test_popen test_popen2 test_pty test_select test_tempfile 33 tests skipped: test_aepack test_al test_audioop test_bsddb test_bsddb3 test_bz2 test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imageop test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_normalization test_ossaudiodev test_pep277 test_plistlib test_rgbimg test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on osf1V4. *** Exit 1 Stop. Fortunately, make install worked anyway. Thanks again! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-16 02:14 Message: Logged In: YES user_id=33168 Did you try either of these: ./configure --without-gcc ./configure --without-cxx --without-gcc ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 From noreply at sourceforge.net Tue Nov 18 09:05:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 09:10:53 2003 Subject: [ python-Bugs-842171 ] Digital Unix build fails to create ccpython.o Message-ID: Bugs item #842171, was opened at 2003-11-14 10:44 Message generated for change (Comment added) made by perlgrrl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Janet Goldstein (perlgrrl) Assigned to: Anthony Baxter (anthonybaxter) Summary: Digital Unix build fails to create ccpython.o Initial Comment: I am attempting to install Python 2.3.2 on Digital Unix V40.E (Revision 1091). The make goes nearly all the way through, then crashes: Can't open Modules/ccpython.o (No such file or directory) The same thing happens with Python 2.3.1 and 2.1.3. The configure command I used was ./configure --with-cxx=/usr/bin/cc --without-gcc (I know what you're thinking: try it with gcc. Well, I tried building gcc, and it gave me even more problems than Python.) The Makefile is attached. Thank you for any enlightenment you can provide. ---------------------------------------------------------------------- >Comment By: Janet Goldstein (perlgrrl) Date: 2003-11-18 09:05 Message: Logged In: YES user_id=908617 The one Python script that we really needed to get running worked fine after the install, so at this point I'm not worried about whatever modules didn't build. Thanks again for all the help. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-18 08:34 Message: Logged In: YES user_id=29957 Pretty sure there's a Digital Unix 4.0 box in the HP testdrive farm. I'll look into it in a few weeks if no-one gets to it before then. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-18 08:30 Message: Logged In: YES user_id=33168 Is there anything that should be done or can this bug report be closed? As for the failed tests, it looks like socket and select modules didn't build. Probably others. I doubt anyone has access to a box with dec unix 4. So you will probably need to resolve these problems yourself. ---------------------------------------------------------------------- Comment By: Janet Goldstein (perlgrrl) Date: 2003-11-17 08:38 Message: Logged In: YES user_id=908617 The build finally worked when I used the second configure command you recommended: ./configure --without-cxx --without-gcc Thank you for your help! This is what happened when I ran make test: 212 tests OK. 10 tests failed: test_fcntl test_format test_nis test_openpty test_poll test_popen test_popen2 test_pty test_select test_tempfile 33 tests skipped: test_aepack test_al test_audioop test_bsddb test_bsddb3 test_bz2 test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imageop test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_mpz test_normalization test_ossaudiodev test_pep277 test_plistlib test_rgbimg test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on osf1V4. *** Exit 1 Stop. Fortunately, make install worked anyway. Thanks again! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-15 10:14 Message: Logged In: YES user_id=33168 Did you try either of these: ./configure --without-gcc ./configure --without-cxx --without-gcc ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842171&group_id=5470 From noreply at sourceforge.net Tue Nov 18 10:48:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 10:48:28 2003 Subject: [ python-Bugs-844336 ] urllib2 fails its builtin test Message-ID: Bugs item #844336, was opened at 2003-11-18 21:32 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-19 00:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 From noreply at sourceforge.net Tue Nov 18 12:22:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 12:22:49 2003 Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug Message-ID: Bugs item #844561, was opened at 2003-11-18 11: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=844561&group_id=5470 Category: Unicode Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.open().readlines(sizehint) bug Initial Comment: codecs.open().readlines(sizehint) can return truncated lines. The attached script, which uses readlines(sizehint) to count the number of lines in a file, demonstrates the problem. Correct output would be 1000 in both cases, but different values are returned depending on sizehint because of the truncated lines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470 From noreply at sourceforge.net Tue Nov 18 12:28:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 12:28:50 2003 Subject: [ python-Bugs-844561 ] codecs.open().readlines(sizehint) bug Message-ID: Bugs item #844561, was opened at 2003-11-18 11:22 Message generated for change (Comment added) made by jepler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470 Category: Unicode Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: M.-A. Lemburg (lemburg) Summary: codecs.open().readlines(sizehint) bug Initial Comment: codecs.open().readlines(sizehint) can return truncated lines. The attached script, which uses readlines(sizehint) to count the number of lines in a file, demonstrates the problem. Correct output would be 1000 in both cases, but different values are returned depending on sizehint because of the truncated lines. ---------------------------------------------------------------------- >Comment By: Jeff Epler (jepler) Date: 2003-11-18 11:28 Message: Logged In: YES user_id=2772 The script triggers the assertion error using at least python 2.3.2 (locally compiled) and python 2.2.2 (redhat 9 RPM) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844561&group_id=5470 From noreply at sourceforge.net Tue Nov 18 15:36:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 15:36:49 2003 Subject: [ python-Bugs-844676 ] PackageManager: deselect show hidden: indexerror Message-ID: Bugs item #844676, was opened at 2003-11-18 21:36 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=844676&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martina Oefelein (oefe) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager: deselect show hidden: indexerror Initial Comment: Select "Show hidden". Select the last package in the list Deselect "Show hidden": IndexError: list index out of range Traceback: File "Wapplication.py", line 45, in mainloop self.do1event(mask, wait) File "FrameWork.py", line 194, in do1event self.dispatch(event) File "FrameWork.py", line 227, in dispatch handler(event) File "FrameWork.py", line 289, in do_mouseDown handler(partcode, wid, event) File "FrameWork.py", line 836, in do_inContent self.do_contentclick(local, modifiers, event) File "Wwindows.py", line 336, in do_contentclick widget.click(point, modifiers) File "Wcontrols.py", line 241, in click Wbase.CallbackCall(self._callback, 0, self.get()) File "Wbase.py", line 684, in CallbackCall return callback() File "PackageManager.py", line 386, in updatestatus installed, message = self.getstatus(sel) File "PackageManager.py", line 316, in getstatus pkg = self.packages[number] Mac OS X 10.3.1, MacPython 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844676&group_id=5470 From noreply at sourceforge.net Tue Nov 18 17:04:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 17:04:21 2003 Subject: [ python-Bugs-844336 ] urllib2 fails its builtin test Message-ID: Bugs item #844336, was opened at 2003-11-18 07:32 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 fails its builtin test Initial Comment: >python -u "ftplib.py" Traceback (most recent call last): File "ftplib.py", line 803, in ? test() File "ftplib.py", line 762, in test while sys.argv[1] == '-d': IndexError: list index out of range >Exit code: 1 >python -u "urllib2.py" gopher://gopher.lib.ncsu.edu/11/library/stacks/Alex socket.error: (7, 'getaddrinfo failed') gopher://gopher.vt.edu:10010/10/33 socket.error: (7, 'getaddrinfo failed') file:/etc/passwd Traceback (most recent call last): File "urllib2.py", line 1154, in ? f = urlopen(url, req) File "urllib2.py", line 136, in urlopen return _opener.open(url, data) File "urllib2.py", line 333, in open '_open', req) File "urllib2.py", line 313, in _call_chain result = func(*args) File "urllib2.py", line 928, in file_open return self.open_local_file(req) File "urllib2.py", line 943, in open_local_file stats = os.stat(localfile) OSError: [Errno 2] No such file or directory: '\etc\passwd' >Exit code: 1 ---------------------------------------------------------------------- >Comment By: Colin J. Williams (cjwhrh) Date: 2003-11-18 17:04 Message: Logged In: YES user_id=285587 This is a response to quiver. Thanks for pointing out the correct usage of ftlib, I am slowly sorting out how to use ftplib from a script. Unfortunately my report did not make it clear that there is a problem with the operation of the test function. Usually, a test function gives some assurance that the main code of the module is functional. In this case, the test fails. That, I suggest, indicates a bug. The bug could be in test function or the module being exercised. You are probably right that a host needs to be specified. I suggest that the test function should be responsible for this. Incidentally, it would be very helpful to the potential user if the documentation made the names and roles of the various cmds's clearer. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-18 10:48 Message: Logged In: YES user_id=671362 For the first one, you need to specify a host to run the test. For expample, >python ftplib.py ftp.python.org -l This gives drwxrwxr-x 5 webmaster webmaster 512 Jan 25 2003 pub There is a usage on the test in the script: '''Test program. Usage: ftp [-d] [-r[file]] host [-l[dir]] [-d[dir]] [-p] [file] ...''' I think this is not a bug. For the second one, catching OSError along with IOError might be needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844336&group_id=5470 From noreply at sourceforge.net Tue Nov 18 17:41:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 17:44:39 2003 Subject: [ 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: Closed >Resolution: Fixed 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-11-18 23:41 Message: Logged In: YES user_id=92689 Fixed without moving to "U", should be good enough for now. Rev. 1.44, will backport to the 2.3 maintainance branch. ---------------------------------------------------------------------- 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 Tue Nov 18 17:48:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 17:48:44 2003 Subject: [ python-Bugs-607816 ] IDE Preferences Message-ID: Bugs item #607816, was opened at 2002-09-11 15:28 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607816&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE Preferences Initial Comment: The IDe preferences need to go behind a single "Preferences" command, in the application menu. The simplest implementation is probably to have that window show the current settings for the prefs, with buttons leading off to the existing dialogs to change the preferences. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-11-18 23:48 Message: Logged In: YES user_id=92689 Sorry, closing this as "won't fix". PythonIDE is doomed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=607816&group_id=5470 From noreply at sourceforge.net Tue Nov 18 18:09:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 18:10:20 2003 Subject: [ python-Bugs-803498 ] plat-mac/applesingle.py needs cosmetic changes Message-ID: Bugs item #803498, was opened at 2003-09-10 01:34 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803498&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: plat-mac/applesingle.py needs cosmetic changes Initial Comment: 1) it uses a string exception 2) it has a warning every time you use it: /Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/plat-mac/applesingle.py:40: FutureWarning: %u/ %o/%x/%X of negative int will return a signed string in Python 2.4 and up 3) its decode function overloads __builtin__ names (input, id) and uses type(input) == type('') when it really means: isinstance(input, basestring).. or maybe even better: not hasattr(input, 'read') 4) it can be useful on platforms other than MacOS (bub-n- bob uses it for example) Attached is a revamped and backwards compatible version. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-19 00:09 Message: Logged In: YES user_id=45365 Accepted for 2.4 as rev. 1.3 (with minor changes by me, to make it pass the new test_applesingle test), but not for 2.3: it seems the one thing that would make this a bug fix (point 2) doesn't happen for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=803498&group_id=5470 From noreply at sourceforge.net Tue Nov 18 21:39:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 18 21:39:29 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-18 21:39 Message: Logged In: YES user_id=31435 Ping. Any progress, Thomas? Reduced priority a notch due to inactivity. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:55 Message: Logged In: YES user_id=31435 What I hope is the last fix for this class of bug has been checked in on release23-maint too, so feel free to use that for testing instead. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:23 Message: Logged In: YES user_id=31435 Good! I hoped it would fix it, but it's not the best way to fix it. I've checked in a better way, so please test against the current CVS trunk. I'll backport that to the 2.3 maint branch too, but later today. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:13 Message: Logged In: YES user_id=11105 Applied your patch, very cool! This problem doesn't occur any more, it seems. But this was only after a short test with my application. I will patch the 2.3 branch and test more extensively with this one tomorrow. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 08:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 02:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 15:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 19 00:22:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 00:22:07 2003 Subject: [ python-Bugs-839151 ] attempt to access sys.argv when it doesn't exist Message-ID: Bugs item #839151, was opened at 2003-11-10 02:56 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: attempt to access sys.argv when it doesn't exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:22 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File "", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 07:02 Message: Logged In: YES user_id=33168 Just to provide a reference, 839200 was a duplicate of this report. I closed 839200. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 From noreply at sourceforge.net Wed Nov 19 00:23:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 00:23:48 2003 Subject: [ python-Bugs-839151 ] attempt to access sys.argv when it doesn't exist Message-ID: Bugs item #839151, was opened at 2003-11-10 02:56 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: attempt to access sys.argv when it doesn't exist Initial Comment: When using Python as an extension to another program, giving a warning message attempts to access sys.argv while it doesn't exist. The problem can be reproduced with Vim when compiled with Python 2.3. Use these two commands: :py import sys :py print sys.maxint + 1 The problem is caused by the warnings module. In line 53 it accesses sys.argv[0], but for an embedded interpreter this doesn't exist. The suggested fix does an explicit test for the existence of sys.argv. That seems to be the cleanest solution to me. This problem also existed in Python 2.2. I didn't try other versions. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:23 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File "", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-11-18 21:22 Message: Logged In: NO Much simplier test: >>> import sys >>> del sys.argv >>> sys.maxint+1 Traceback (most recent call last): File "", line 1, in ? File "D:\development\python22\lib\warnings.py", line 38, in warn filename = sys.argv[0] AttributeError: 'module' object has no attribute 'argv' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-10 07:02 Message: Logged In: YES user_id=33168 Just to provide a reference, 839200 was a duplicate of this report. I closed 839200. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839151&group_id=5470 From noreply at sourceforge.net Wed Nov 19 04:59:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 04:59:22 2003 Subject: [ python-Bugs-845025 ] Symbols not exported in windows python23 dll Message-ID: Bugs item #845025, was opened at 2003-11-19 09: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=845025&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Arnaud Charlet (charlet) Assigned to: Thomas Heller (theller) Summary: Symbols not exported in windows python23 dll Initial Comment: When trying to link with python23.lib to use python23.dll under Windows, I am getting undefined symbols: undefined reference to `_imp__PyString_Type' undefined reference to `_imp__PyInt_Type' undefined reference to `_imp__PyFunction_Type' etc... This is apparently due to the fact that these global symbols are properly marked as dllexport/import in the header file (stringobject.h), but are not marked as such in the C file (stringobject.c), therefore these variables are not exported in the DLL under Windows, due to the special handling of global variables in DLLs. Arno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845025&group_id=5470 From noreply at sourceforge.net Wed Nov 19 05:27:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 05:29:11 2003 Subject: [ python-Bugs-845037 ] Symbols not exported in windows python23 dll Message-ID: Bugs item #845037, was opened at 2003-11-19 10:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845037&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Arnaud Charlet (charlet) Assigned to: Thomas Heller (theller) Summary: Symbols not exported in windows python23 dll Initial Comment: When trying to link with python23.lib to use python23.dll under Windows, I am getting undefined symbols: undefined reference to `_imp__PyString_Type' undefined reference to `_imp__PyInt_Type' undefined reference to `_imp__PyFunction_Type' etc... This is apparently due to the fact that these global symbols are properly marked as dllexport/import in the header file (stringobject.h), but are not marked as such in the C file (stringobject.c), therefore these variables are not exported in the DLL under Windows, due to the special handling of global variables in DLLs. Arno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845037&group_id=5470 From noreply at sourceforge.net Wed Nov 19 05:39:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 05:39:17 2003 Subject: [ python-Bugs-845037 ] Symbols not exported in windows python23 dll Message-ID: Bugs item #845037, was opened at 2003-11-19 10:27 Message generated for change (Comment added) made by charlet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845037&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Arnaud Charlet (charlet) Assigned to: Thomas Heller (theller) Summary: Symbols not exported in windows python23 dll Initial Comment: When trying to link with python23.lib to use python23.dll under Windows, I am getting undefined symbols: undefined reference to `_imp__PyString_Type' undefined reference to `_imp__PyInt_Type' undefined reference to `_imp__PyFunction_Type' etc... This is apparently due to the fact that these global symbols are properly marked as dllexport/import in the header file (stringobject.h), but are not marked as such in the C file (stringobject.c), therefore these variables are not exported in the DLL under Windows, due to the special handling of global variables in DLLs. Arno ---------------------------------------------------------------------- >Comment By: Arnaud Charlet (charlet) Date: 2003-11-19 10:39 Message: Logged In: YES user_id=912669 Sorry for the duplicate (of 845025), it was not intended. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845037&group_id=5470 From noreply at sourceforge.net Wed Nov 19 11:58:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 11:58:15 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 18:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-19 17:58 Message: Logged In: YES user_id=11105 The problem doesn't seem to occur anymore in a release23-maint build. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-19 03:39 Message: Logged In: YES user_id=31435 Ping. Any progress, Thomas? Reduced priority a notch due to inactivity. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 23:55 Message: Logged In: YES user_id=31435 What I hope is the last fix for this class of bug has been checked in on release23-maint too, so feel free to use that for testing instead. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 23:23 Message: Logged In: YES user_id=31435 Good! I hoped it would fix it, but it's not the best way to fix it. I've checked in a better way, so please test against the current CVS trunk. I'll backport that to the 2.3 maint branch too, but later today. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 22:13 Message: Logged In: YES user_id=11105 Applied your patch, very cool! This problem doesn't occur any more, it seems. But this was only after a short test with my application. I will patch the 2.3 branch and test more extensively with this one tomorrow. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 22:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 14:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 08:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 21:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 20:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 18:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 19 12:05:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 12:05:32 2003 Subject: [ python-Bugs-845025 ] Symbols not exported in windows python23 dll Message-ID: Bugs item #845025, was opened at 2003-11-19 09:59 Message generated for change (Comment added) made by charlet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845025&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Arnaud Charlet (charlet) Assigned to: Thomas Heller (theller) Summary: Symbols not exported in windows python23 dll Initial Comment: When trying to link with python23.lib to use python23.dll under Windows, I am getting undefined symbols: undefined reference to `_imp__PyString_Type' undefined reference to `_imp__PyInt_Type' undefined reference to `_imp__PyFunction_Type' etc... This is apparently due to the fact that these global symbols are properly marked as dllexport/import in the header file (stringobject.h), but are not marked as such in the C file (stringobject.c), therefore these variables are not exported in the DLL under Windows, due to the special handling of global variables in DLLs. Arno ---------------------------------------------------------------------- >Comment By: Arnaud Charlet (charlet) Date: 2003-11-19 17:05 Message: Logged In: YES user_id=912669 My comment about not using dllexport/import in the C files was misleading, since having it in the header file is enough. After investigation, it appears that you cannot link with python23.lib since the global variables are not exported there, but linking with python23.dll directly works fine, so I will close this report. Arno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845025&group_id=5470 From noreply at sourceforge.net Wed Nov 19 12:42:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 12:42:46 2003 Subject: [ python-Bugs-842629 ] Windows mis-installs to network drive Message-ID: Bugs item #842629, was opened at 2003-11-15 08:44 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Sloyer (dsloyer) Assigned to: Nobody/Anonymous (nobody) Summary: Windows mis-installs to network drive Initial Comment: Installing: python-2.3.2-1.exe /S where the current working directory is on a network drive causes Python 2.3 to mis-install on the network drive, instead of the system drive (C:). The installation takes a long time to run. I observed this on Windows XP SP1, with all current security patches applied (thru MS03-049). The problem occurred on multiple machines. The servers is both cases were Windows 2000 servers, sharing a drive with the workstation. Python 2.3 shows up in Add/Remove Programs, but cannot be removed, except by hand. Copying the installer to the local C: drive, and running the command from there, was successful in silently, and correctly, installing Python 2.3 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-19 18:42 Message: Logged In: YES user_id=11105 I can reproduce this behaviour, and confirm that this is a bug. Not even does it install to the network drive, also the paths in the registry are wrong - they do not contain a drive letter. It has probably to do with the fact that our default installation directory is "\Python23" (note that this does *not* contain a drive letter). The installer seems to do the right things when run interactively, but fails when run in silent mode. I see three possible solutions: - Install some magic into the wise script to determine the system drive (however this is defined), it may be difficult because wise doesn't have commands to determine the drive letter of a given path. - Enable the 'read from values files' option for the MAINDIR variable, this allows to create a file before installation which will supply values to the installer. I have never used this feature, so I do not know whether it works or not. - Live with the current state and say: silent installs do not work. Assigning to Tim. Tim, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 From noreply at sourceforge.net Wed Nov 19 12:43:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 12:43:10 2003 Subject: [ python-Bugs-842629 ] Windows mis-installs to network drive Message-ID: Bugs item #842629, was opened at 2003-11-15 08:44 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Sloyer (dsloyer) >Assigned to: Tim Peters (tim_one) Summary: Windows mis-installs to network drive Initial Comment: Installing: python-2.3.2-1.exe /S where the current working directory is on a network drive causes Python 2.3 to mis-install on the network drive, instead of the system drive (C:). The installation takes a long time to run. I observed this on Windows XP SP1, with all current security patches applied (thru MS03-049). The problem occurred on multiple machines. The servers is both cases were Windows 2000 servers, sharing a drive with the workstation. Python 2.3 shows up in Add/Remove Programs, but cannot be removed, except by hand. Copying the installer to the local C: drive, and running the command from there, was successful in silently, and correctly, installing Python 2.3 ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-19 18:42 Message: Logged In: YES user_id=11105 I can reproduce this behaviour, and confirm that this is a bug. Not even does it install to the network drive, also the paths in the registry are wrong - they do not contain a drive letter. It has probably to do with the fact that our default installation directory is "\Python23" (note that this does *not* contain a drive letter). The installer seems to do the right things when run interactively, but fails when run in silent mode. I see three possible solutions: - Install some magic into the wise script to determine the system drive (however this is defined), it may be difficult because wise doesn't have commands to determine the drive letter of a given path. - Enable the 'read from values files' option for the MAINDIR variable, this allows to create a file before installation which will supply values to the installer. I have never used this feature, so I do not know whether it works or not. - Live with the current state and say: silent installs do not work. Assigning to Tim. Tim, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 From noreply at sourceforge.net Wed Nov 19 12:47:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 12:48:01 2003 Subject: [ python-Bugs-845025 ] Symbols not exported in windows python23 dll Message-ID: Bugs item #845025, was opened at 2003-11-19 10:59 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845025&group_id=5470 Category: Windows Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Arnaud Charlet (charlet) Assigned to: Thomas Heller (theller) Summary: Symbols not exported in windows python23 dll Initial Comment: When trying to link with python23.lib to use python23.dll under Windows, I am getting undefined symbols: undefined reference to `_imp__PyString_Type' undefined reference to `_imp__PyInt_Type' undefined reference to `_imp__PyFunction_Type' etc... This is apparently due to the fact that these global symbols are properly marked as dllexport/import in the header file (stringobject.h), but are not marked as such in the C file (stringobject.c), therefore these variables are not exported in the DLL under Windows, due to the special handling of global variables in DLLs. Arno ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-19 18:47 Message: Logged In: YES user_id=11105 The best way to build extensions is to use distutils - it always does it correct. IMO. ---------------------------------------------------------------------- Comment By: Arnaud Charlet (charlet) Date: 2003-11-19 18:05 Message: Logged In: YES user_id=912669 My comment about not using dllexport/import in the C files was misleading, since having it in the header file is enough. After investigation, it appears that you cannot link with python23.lib since the global variables are not exported there, but linking with python23.dll directly works fine, so I will close this report. Arno ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845025&group_id=5470 From noreply at sourceforge.net Wed Nov 19 12:55:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 12:56:41 2003 Subject: [ python-Feature Requests-535450 ] documentation in CHM format Message-ID: Feature Requests item #535450, was opened at 2002-03-26 17:23 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535450&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: G?bor Lipt?k (gliptak) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: documentation in CHM format Initial Comment: Please add html-help-2.2.chm to the sf.net downloadables. Thanks ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-11-19 12:55 Message: Logged In: YES user_id=3066 This is now available as part of the Windows installer starting with Python 2.3.2. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-04-12 22:48 Message: Logged In: YES user_id=3066 These are provided by contributors for most releases, but should be integrated with the Windows installer from PythonLabs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=535450&group_id=5470 From noreply at sourceforge.net Wed Nov 19 14:30:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 14:30:46 2003 Subject: [ python-Bugs-845342 ] os.exec* and first 'arg' Message-ID: Bugs item #845342, was opened at 2003-11-19 19: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=845342&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander Schmolck (aschmolck) Assigned to: Nobody/Anonymous (nobody) Summary: os.exec* and first 'arg' Initial Comment: The current I'd suggest the following change to the docstrings for the exec* functions, because I think it's quite easy to get bitten: execv(...) execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings (NOTE: the first argument is analoguous to sys.argv[0], *not* sys.argv[1]!) instead of: execv(...) execv(path, args) Execute an executable path with arguments, replacing current process. path: path of executable file args: tuple or list of strings ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845342&group_id=5470 From noreply at sourceforge.net Wed Nov 19 14:43:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 14:49:06 2003 Subject: [ python-Bugs-842600 ] xmlrpclib and backward compatibility Message-ID: Bugs item #842600, was opened at 2003-11-15 05:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842600&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Fredrik Lundh (effbot) Summary: xmlrpclib and backward compatibility Initial Comment: This bug is related to patch #531629 "Add multicall support to xmlrpclib" http://www.python.org/sf/531629 His applied patch includes 'yield' statement. Is this OK? I think xmlrpclib.py needs to keep compatible with older Python. On the top of xmlrpclib.py there is a note: # this version is designed to work with Python 1.5.2 or newer. I attached a patch to avoid 'yield' but this is a quick fix. I'm not sure if this is the right approach. There should be a better solution. I've also changed the coding style of the previous change to be consistent with other parts of this script. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-19 20:43 Message: Logged In: YES user_id=21627 Assigning to Fredrik, as he is listed as the maintainer in PEP 291. My proposal would be to drop xmlrpclib from PEP 291, and closing this report as "Won't fix". I don't see the need for this backwards compatibility. Fredrik, if you consider compatibility with 1.5.2 still desirable, please indicate so, and assign it back to me so I can fix the new feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842600&group_id=5470 From noreply at sourceforge.net Wed Nov 19 14:52:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 14:52:28 2003 Subject: [ python-Bugs-831747 ] httplib hardcodes Accept-Encoding Message-ID: Bugs item #831747, was opened at 2003-10-28 14:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hardcodes Accept-Encoding Initial Comment: in httplib.py the request() method adds a hardcoded Accept-Encoding header with the 'identity' value. This should at least be optional, since I have several programs supporting encodings like 'gzip' or 'deflate' and I want to be able to specify my own Accept-Encoding header. I suggest adding (similar to skip_host) a skip_accept_encoding optional argument. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-19 20:52 Message: Logged In: YES user_id=21627 Thanks for the patch. Applied as libhttplib.tex 1.36 httplib.py 1.82 NEWS 1.895 ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2003-11-11 18:03 Message: Logged In: YES user_id=9205 Here is a patch against CVS adding skip_accept_encoding and documentation. ---------------------------------------------------------------------- Comment By: Bastian Kleineidam (calvin) Date: 2003-10-31 15:55 Message: Logged In: YES user_id=9205 Yes, in a few days. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:45 Message: Logged In: YES user_id=21627 Can you provide a patch (including documentation changes)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 From noreply at sourceforge.net Wed Nov 19 14:57:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 14:57:08 2003 Subject: [ python-Bugs-824565 ] bad value of INSTSONAME in Makefile Message-ID: Bugs item #824565, was opened at 2003-10-16 07:05 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824565&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kyle Lanclos (lanclos) Assigned to: Nobody/Anonymous (nobody) Summary: bad value of INSTSONAME in Makefile Initial Comment: With the 2.3.2 source on a Solaris 9 machine and the following configure: ./configure --prefix=/opt/python-2.3.2 --enable-shared 'make; make install' will result in an error when the Makefile tries to link the .so file, because INSTSONAME = LDLIBRARY = libpython$(VERSION).so, and the linker tries to do: $(INSTALL_SHARED) libpython$(VERSION)$(SO) $(DESTDIR)$(LIBDIR)/$(INSTSONAME); (cd $(DESTDIR)$(LIBDIR); $(LN) -sf $(INSTSONAME) libpython$(VERSION)$(SO)); This is all fine and good, except that libpython$(VERSION)$(SO) is the same as INSTSONAME, and you end up doing: ln -sf libpython2.3.so libpython2.3.so ...which rightfully returns an error. Looking at the generated Makefile on Linux, the value of INSTSONAME is: INSTSONAME= libpython$(VERSION).so.1.0 ...instead of this value from Solaris: INSTSONAME= $(LDLIBRARY) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-19 20:57 Message: Logged In: YES user_id=21627 This is fixed with patch #841807. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824565&group_id=5470 From noreply at sourceforge.net Wed Nov 19 15:05:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 15:05:41 2003 Subject: [ python-Bugs-842629 ] Windows mis-installs to network drive Message-ID: Bugs item #842629, was opened at 2003-11-15 02:44 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Sloyer (dsloyer) >Assigned to: Thomas Heller (theller) Summary: Windows mis-installs to network drive Initial Comment: Installing: python-2.3.2-1.exe /S where the current working directory is on a network drive causes Python 2.3 to mis-install on the network drive, instead of the system drive (C:). The installation takes a long time to run. I observed this on Windows XP SP1, with all current security patches applied (thru MS03-049). The problem occurred on multiple machines. The servers is both cases were Windows 2000 servers, sharing a drive with the workstation. Python 2.3 shows up in Add/Remove Programs, but cannot be removed, except by hand. Copying the installer to the local C: drive, and running the command from there, was successful in silently, and correctly, installing Python 2.3 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-19 15:05 Message: Logged In: YES user_id=31435 Sorry, I never tried a network install or a silent install. I always figured people who wanted gonzo installation gimmicks would be much happier with ActiveState's MSI-based installer anyway. Of course Wise is closed-source, so we can't look at their code to figure out what it's doing. The things of this ilk I had to fix in the past therefore required hanging out in the Wise tech support forums. Sometimes it was easy to get a good answer, more often impossible. If your copy of Wise is still in its support period, you could ask Wise directly what's up with the odd /S behavior. Otherwise it requires thrashing in the dark. Personally, if I had to piss away time on that again, I'd rather spend it moving to an open-source installer (which may have bugs too, but at least then you can figure out exactly why, and probably even get them fixed). In the version of Wise I had, I never did find a way to determine "the system drive", short of writing an external DLL for the install script to invoke; under InnoSetup, the system drive is the value of a predefined variable . ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-19 12:42 Message: Logged In: YES user_id=11105 I can reproduce this behaviour, and confirm that this is a bug. Not even does it install to the network drive, also the paths in the registry are wrong - they do not contain a drive letter. It has probably to do with the fact that our default installation directory is "\Python23" (note that this does *not* contain a drive letter). The installer seems to do the right things when run interactively, but fails when run in silent mode. I see three possible solutions: - Install some magic into the wise script to determine the system drive (however this is defined), it may be difficult because wise doesn't have commands to determine the drive letter of a given path. - Enable the 'read from values files' option for the MAINDIR variable, this allows to create a file before installation which will supply values to the installer. I have never used this feature, so I do not know whether it works or not. - Live with the current state and say: silent installs do not work. Assigning to Tim. Tim, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 From noreply at sourceforge.net Wed Nov 19 15:12:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 15:12:46 2003 Subject: [ python-Bugs-805200 ] _tkinter compilation fails Message-ID: Bugs item #805200, was opened at 2003-09-12 19:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Samson Abramsky (bobrowski) Assigned to: Nobody/Anonymous (nobody) Summary: _tkinter compilation fails Initial Comment: Building Python 2.3 on Linux. At make stage: _tkinter compilation fails: libtk8.4.so no such file of directory with gcc arguments -L/usr/local/lib -ltk8.4 However, /usr/local/lib/libtk8.4.so does exist.! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-19 21:12 Message: Logged In: YES user_id=21627 This is not a bug, but a misconfiguration of the system. Setting LD_LIBRARY_PATH is not necessary. Alternatively, one could edit /etc/ld.so.conf, or set LD_RUN_PATH at compile time. ---------------------------------------------------------------------- Comment By: Robin Friedrich (robinf1) Date: 2003-11-05 23:03 Message: Logged In: YES user_id=404550 I'm seeing this same link error. Python 2.3.2 / Red Hat Linux 7.3. I configure tcl/tk with a --prefix in configure and install. Works. I configure Python with same prefix; build fails to link saying it can't find libtk8.4.so when it indeed there. (the link line has the right -L and -l) For comparison I build a clean Python 2.2.3 from scratch with the same configure options and it compiled/linked/installed fine against this same exact .so. PS> Is LD_LIBRARY_PATH really necessary? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-09-12 20:35 Message: Logged In: YES user_id=33168 Are you sure libtk8.4.so isn't a sym link to a non-existent file? Is /usr/local/lib configured in ld.so? Is LD_LIBRARY_PATH set properly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805200&group_id=5470 From noreply at sourceforge.net Wed Nov 19 15:17:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 15:17:54 2003 Subject: [ python-Bugs-842629 ] Windows mis-installs to network drive Message-ID: Bugs item #842629, was opened at 2003-11-15 08:44 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: David Sloyer (dsloyer) Assigned to: Thomas Heller (theller) Summary: Windows mis-installs to network drive Initial Comment: Installing: python-2.3.2-1.exe /S where the current working directory is on a network drive causes Python 2.3 to mis-install on the network drive, instead of the system drive (C:). The installation takes a long time to run. I observed this on Windows XP SP1, with all current security patches applied (thru MS03-049). The problem occurred on multiple machines. The servers is both cases were Windows 2000 servers, sharing a drive with the workstation. Python 2.3 shows up in Add/Remove Programs, but cannot be removed, except by hand. Copying the installer to the local C: drive, and running the command from there, was successful in silently, and correctly, installing Python 2.3 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-19 21:17 Message: Logged In: YES user_id=11105 Ok, in this case I would say "don't do this". Python 2.4 will most probably use a different installer, so I'm closing this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-19 21:05 Message: Logged In: YES user_id=31435 Sorry, I never tried a network install or a silent install. I always figured people who wanted gonzo installation gimmicks would be much happier with ActiveState's MSI-based installer anyway. Of course Wise is closed-source, so we can't look at their code to figure out what it's doing. The things of this ilk I had to fix in the past therefore required hanging out in the Wise tech support forums. Sometimes it was easy to get a good answer, more often impossible. If your copy of Wise is still in its support period, you could ask Wise directly what's up with the odd /S behavior. Otherwise it requires thrashing in the dark. Personally, if I had to piss away time on that again, I'd rather spend it moving to an open-source installer (which may have bugs too, but at least then you can figure out exactly why, and probably even get them fixed). In the version of Wise I had, I never did find a way to determine "the system drive", short of writing an external DLL for the install script to invoke; under InnoSetup, the system drive is the value of a predefined variable . ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-19 18:42 Message: Logged In: YES user_id=11105 I can reproduce this behaviour, and confirm that this is a bug. Not even does it install to the network drive, also the paths in the registry are wrong - they do not contain a drive letter. It has probably to do with the fact that our default installation directory is "\Python23" (note that this does *not* contain a drive letter). The installer seems to do the right things when run interactively, but fails when run in silent mode. I see three possible solutions: - Install some magic into the wise script to determine the system drive (however this is defined), it may be difficult because wise doesn't have commands to determine the drive letter of a given path. - Enable the 'read from values files' option for the MAINDIR variable, this allows to create a file before installation which will supply values to the installer. I have never used this feature, so I do not know whether it works or not. - Live with the current state and say: silent installs do not work. Assigning to Tim. Tim, any comments? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842629&group_id=5470 From noreply at sourceforge.net Wed Nov 19 16:57:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 16:57:43 2003 Subject: [ python-Bugs-840829 ] weakref callbacks and gc corrupt memory Message-ID: Bugs item #840829, was opened at 2003-11-12 12:05 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Thomas Heller (theller) >Assigned to: Tim Peters (tim_one) Summary: weakref callbacks and gc corrupt memory Initial Comment: This program crashes the Python interpreter in a debug build, and probably corrupts memory in release build (on Windows, at least): """ import weakref import gc _boundMethods = weakref.WeakKeyDictionary() def safeRef(object): selfkey = object.im_self funckey = object.im_func _boundMethods[selfkey] = weakref.WeakKeyDictionary() _boundMethods[selfkey][funckey] = BoundMethodWeakref(object) class BoundMethodWeakref: def __init__(self, boundMethod): def remove(object): gc.collect() self.weakSelf = weakref.ref(boundMethod.im_self, remove) class X(object): def test(self): pass def test(): print "A" safeRef(X().test) print "B" if __name__ == "__main__": test() """ See also these messages: http://mail.python.org/pipermail/python-dev/2003-November/040189.html http://mail.python.org/pipermail/python-dev/2003-November/040191.html ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-19 16:57 Message: Logged In: YES user_id=31435 Thank you! Closing as fixed. Note that even funkier changes to fix (other) weakref bugs are in the queue, so I hope you try this particular app against 2.3 maint again (maybe next week). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-19 11:58 Message: Logged In: YES user_id=11105 The problem doesn't seem to occur anymore in a release23-maint build. Thanks. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-18 21:39 Message: Logged In: YES user_id=31435 Ping. Any progress, Thomas? Reduced priority a notch due to inactivity. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:55 Message: Logged In: YES user_id=31435 What I hope is the last fix for this class of bug has been checked in on release23-maint too, so feel free to use that for testing instead. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 17:23 Message: Logged In: YES user_id=31435 Good! I hoped it would fix it, but it's not the best way to fix it. I've checked in a better way, so please test against the current CVS trunk. I'll backport that to the 2.3 maint branch too, but later today. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:13 Message: Logged In: YES user_id=11105 Applied your patch, very cool! This problem doesn't occur any more, it seems. But this was only after a short test with my application. I will patch the 2.3 branch and test more extensively with this one tomorrow. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 16:06 Message: Logged In: YES user_id=11105 > When you say "what helped for me was ...", do you mean > that cured *all* the problems you're seeing, or just that "it > helped", in the ordinary sense that it cured more of the > problems, but not all of the problems. Well, it seemed to help "completely", I never observed the crash with this workaround. For the patch to subtype_dealloc, I will try your suggestion and report. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-13 08:56 Message: Logged In: YES user_id=31435 Thanks! There's more than one bug here, of course. When you say "what helped for me was ...", do you mean that cured *all* the problems you're seeing, or just that "it helped", in the ordinary sense that it cured more of the problems, but not all of the problems. Since I don't have a failing program I can run at this point, I can't test any other ideas. You can, though: In typeobject.c's subtype_dealloc, on the trunk, right before the comment /* Clear slots up to the nearest base with a different tp_dealloc */ try inserting this line: self->ob_refcnt = 1; and right after the /* Call the base tp_dealloc() */ comment insert assert(self->ob_refcnt == 1); self->ob_refcnt = 0; That should cure the more-complicated (than in your original report) bug in the new stacktrace. However, it *may* cause some other code to die with an assert, bitching about the suddenly non-zero refcnt. I can't guess whether it will; my best guess is that it won't. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-13 02:49 Message: Logged In: YES user_id=11105 Thanks for the fast response, Tim, but this doesn't seem to be the (complete) solution. The debug build crashes far less than before, but it still occurs, and in the same way. I attach a complete MSVC6 stack dump. The function names you do not know come from the ctypes extension. Back to you again :-( Oh, what helped for me was to disable gc in the weakref callback functions. Don't know if that is an option for the C code... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 15:47 Message: Logged In: YES user_id=31435 Back to you, Thomas! Please check your real app against current CVS Python. I checked in a putative fix as Lib/test/test_weakref.py; new revision: 1.29 Misc/NEWS; new revision: 1.890 Objects/typeobject.c; new revision: 2.251 The new test case in test_weakref.py is very much simpler than what you've been running, so I want confirmation that the real problem is fixed too before closing this. Please record what happens here, then assign back to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-12 14:54 Message: Logged In: YES user_id=31435 I agree this is a critical bug; assigned to me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:08 Message: Logged In: YES user_id=11105 Attached the script triggering the error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-12 12:07 Message: Logged In: YES user_id=11105 IMO this is a serious problem because it renders weakref callbacks basically unusable - gc can occur at any time. So I raised the priority to 9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=840829&group_id=5470 From noreply at sourceforge.net Wed Nov 19 23:01:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 23:01:10 2003 Subject: [ python-Bugs-845560 ] imaplib: traceback from _checkquote with empty string Message-ID: Bugs item #845560, was opened at 2003-11-20 17: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=845560&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: imaplib: traceback from _checkquote with empty string Initial Comment: Python 2.3.2 and also 18/11/03 CVS; Windows XP. If _checkquote is passed the empty string, it raises and exception (because it tries to get an index into the string). The easiest way to reproduce this is: >>> import imaplib >>> i = imaplib.IMAP4('server.name') >>> i.login("username", "password") >>> i.select("") [Traceback here] While it's unlikely that there's a folder called "", this should really give the 'invalid folder name' error, rather than an exception. The attached diff fixes this, simply by checking for the empty string in _checkquote. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845560&group_id=5470 From noreply at sourceforge.net Wed Nov 19 23:44:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Nov 19 23:44:41 2003 Subject: [ python-Bugs-838938 ] Typos in the docs (Extending/Embedding + Python/C API) Message-ID: Bugs item #838938, was opened at 2003-11-09 18:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838938&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Florent Rougon (frougon) >Assigned to: Raymond Hettinger (rhettinger) Summary: Typos in the docs (Extending/Embedding + Python/C API) Initial Comment: Hi, I read a bit of the Extending/Embedding and Python/C API docs during the last weeks and gathered several typos during this process. This relates to Python 2.3.2. I attached a patch for the .tex files. Here follows the list of the problems (all minor) addressed by this patch. Thanks! Doc/api/abstract.tex: "Call the method named \var{m} of object \var{o}" should be replaced by "Call the method named \var{method} of object \var{o}". Doc/api/newtypes.tex: "The specific fields it expands to depends on" ^ "in Python 2.2.1 and later it will be initialized to the \member{ob_type} field of the base class" -> "it _is_ initialized" if the forecast was correct :-) There is a paragraph that reads "PyObject_HEAD_INIT" alone by itself, just before the "\begin{ctypedesc}{PyCFunction}". I think at least an "XXX" (as used later in the same file) is missing. "Pointer to an additional structure contains fields" -> "Pointer to an additional structure that contains fields" Doc/api/exceptions.tex: "that identifies where the context in which the unraisable exception occurred" -> "where" should be suppressed Doc/ext/newtypes.tex: "Note that used the \constant{METH_NOARGS} flag" ^ we "It's reference count" should be replaced by "Its reference count". Doc/tut/tut.tex: "When importing the package, Python searchs" -> "When importing the package, Python searches" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838938&group_id=5470 From noreply at sourceforge.net Thu Nov 20 08:01:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 08:01:49 2003 Subject: [ python-Bugs-835255 ] new.function() docs out of date Message-ID: Bugs item #835255, was opened at 2003-11-03 15:26 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Jeremy Hylton (jhylton) Summary: new.function() docs out of date Initial Comment: The argument list for new.function() has grown to accomodate new runtime features (closure info, for example), but the docs have not kept up. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-11-20 08:01 Message: Logged In: YES user_id=3066 Assigned to Jeremy since he made the changes and can explain what the new arguments are for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835255&group_id=5470 From noreply at sourceforge.net Thu Nov 20 08:13:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 08:13:13 2003 Subject: [ python-Bugs-811070 ] Py2.2.3: Problem with Expat/XML/Zope on MacOSX 10.2.8 Message-ID: Bugs item #811070, was opened at 2003-09-23 06:00 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811070&group_id=5470 Category: XML Group: Python 2.2.3 >Status: Pending Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Py2.2.3: Problem with Expat/XML/Zope on MacOSX 10.2.8 Initial Comment: Trying to run Python 2.2.3 under MacOSX with Zope fails: Python has been built against the latest Expat Sources (1.96.6) Traceback (most recent call last): File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/Zope/Startup/run.py", line 14, in ? run() File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/Zope/Startup/run.py", line 8, in run opts.realize() File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/zdaemon/zdoptions.py", line 257, in realize self.load_schema() File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/zdaemon/zdoptions.py", line 298, in load_schema self.schema = ZConfig.loadSchema(self.schemafile) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py", line 36, in loadSchema return SchemaLoader().loadURL(url) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py", line 70, in loadURL return self.loadResource(r) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py", line 134, in loadResource self.registry, self) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/schema.py", line 42, in parseResource xml.sax.parse(resource.file, parser) File "/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/__init__.py", line 31, in parse parser.parse(filename_or_stream) File "/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 106, in parse self.reset() File "/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 261, in reset self._parser = expat.ParserCreate(intern = self._interning) TypeError: 'intern' is an invalid keyword argument for this function ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-11-20 08:13 Message: Logged In: YES user_id=3066 It looks like you have a broken PyXML installation, but it's difficult to tell. What version of PyXML do you have installed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811070&group_id=5470 From noreply at sourceforge.net Thu Nov 20 08:57:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 08:57:20 2003 Subject: [ python-Bugs-845802 ] Python crashes when __init__.py is a directory. Message-ID: Bugs item #845802, was opened at 2003-11-20 16: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=845802&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kerim Borchaev (warkid) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes when __init__.py is a directory. Initial Comment: If package/__init__.py is a directory then this code crashes under Windows XP: ### import sys#or os or maybe something else;-) import package#package/__init__.py is DIRECTORY! '\n'.join([]) ### Test case attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845802&group_id=5470 From noreply at sourceforge.net Thu Nov 20 16:20:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 16:20:38 2003 Subject: [ python-Bugs-839548 ] Bug in type's GC handling causes segfaults Message-ID: Bugs item #839548, was opened at 2003-11-10 16:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 8 Submitted By: Jim Fulton (dcjim) Assigned to: Tim Peters (tim_one) Summary: Bug in type's GC handling causes segfaults Initial Comment: type has a bug in it's GC "clear" function, type_clear. It sets tp->mro to NULL, but other code (especially PyObject_GenericGetAttr) assumes that tp_mro cannot be null. A class participating in a cycle may have clear called while there are still instances around. If someone tries to do a getattr on such an instance, python will crach with a segfault or with an assertion error. A simple fix is for clear to set tp_mro to an empty tuple, which breaks the cycle without breaking the invariant. A patch is attached. I encountered this in Zope 3 after adding a new interface implementation that made heavy use of weakrefs. Often Zope 3 would segfault when exiting. The patch fixes this. Unfortunately, I was not able, in the time available, to come up with a simpler test case. :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-20 16:20 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-16 22:23 Message: Logged In: YES user_id=31435 Assigned to me. Please see patch 843455, which should repair the problem, but via a different route: the underlying problem is that gc never expected that arbitrary Python code could run while gc is running. A lot of bad things can go wrong. But weakref callbacks have enough nice exploitable properties that I think it's possible for gc to run them if it's made acutely aware of them, and the patch does that, ensuring that a callback (or even later Python code, if a callback resurrects dead objects in cycles) never sees an object on which tp_clear() has been run. In particular, then, in your callback the __mro__ won't be NULL -- or anything else surprising (it will be what you expect the class's __mro__ to be). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 From noreply at sourceforge.net Thu Nov 20 16:24:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 16:24:33 2003 Subject: [ python-Bugs-839548 ] Bug in type's GC handling causes segfaults Message-ID: Bugs item #839548, was opened at 2003-11-10 16:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jim Fulton (dcjim) Assigned to: Tim Peters (tim_one) Summary: Bug in type's GC handling causes segfaults Initial Comment: type has a bug in it's GC "clear" function, type_clear. It sets tp->mro to NULL, but other code (especially PyObject_GenericGetAttr) assumes that tp_mro cannot be null. A class participating in a cycle may have clear called while there are still instances around. If someone tries to do a getattr on such an instance, python will crach with a segfault or with an assertion error. A simple fix is for clear to set tp_mro to an empty tuple, which breaks the cycle without breaking the invariant. A patch is attached. I encountered this in Zope 3 after adding a new interface implementation that made heavy use of weakrefs. Often Zope 3 would segfault when exiting. The patch fixes this. Unfortunately, I was not able, in the time available, to come up with a simpler test case. :) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-20 16:24 Message: Logged In: YES user_id=31435 Fixed, via Include/weakrefobject.h; new revision: 1.4 Lib/test/test_weakref.py; new revision: 1.32 Misc/NEWS; new revision: 1.896 Modules/gc_weakref.txt: new file Modules/gcmodule.c; new revision: 2.74 Objects/weakrefobject.c; new revision: 1.14 I'll backport those to 2.3 maint too. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-20 16:20 Message: Logged In: YES user_id=31435 Boosted priority. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-16 22:23 Message: Logged In: YES user_id=31435 Assigned to me. Please see patch 843455, which should repair the problem, but via a different route: the underlying problem is that gc never expected that arbitrary Python code could run while gc is running. A lot of bad things can go wrong. But weakref callbacks have enough nice exploitable properties that I think it's possible for gc to run them if it's made acutely aware of them, and the patch does that, ensuring that a callback (or even later Python code, if a callback resurrects dead objects in cycles) never sees an object on which tp_clear() has been run. In particular, then, in your callback the __mro__ won't be NULL -- or anything else surprising (it will be what you expect the class's __mro__ to be). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839548&group_id=5470 From noreply at sourceforge.net Thu Nov 20 16:27:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 16:27:18 2003 Subject: [ python-Bugs-846133 ] os.chmod does not work with a unicode filename Message-ID: Bugs item #846133, was opened at 2003-11-20 16:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: M.-A. Lemburg (lemburg) Summary: os.chmod does not work with a unicode filename Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Thu Nov 20 17:44:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 17:44:47 2003 Subject: [ python-Bugs-845802 ] Python crashes when __init__.py is a directory. Message-ID: Bugs item #845802, was opened at 2003-11-20 08:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845802&group_id=5470 >Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kerim Borchaev (warkid) Assigned to: Nobody/Anonymous (nobody) Summary: Python crashes when __init__.py is a directory. Initial Comment: If package/__init__.py is a directory then this code crashes under Windows XP: ### import sys#or os or maybe something else;-) import package#package/__init__.py is DIRECTORY! '\n'.join([]) ### Test case attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-20 17:44 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux, so I'm assuming it's Windows specific. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=845802&group_id=5470 From noreply at sourceforge.net Thu Nov 20 19:07:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 20 19:07:30 2003 Subject: [ python-Bugs-846133 ] os.chmod does not work with a unicode filename Message-ID: Bugs item #846133, was opened at 2003-11-21 06:27 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: M.-A. Lemburg (lemburg) Summary: os.chmod does not work with a unicode filename Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 09:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Fri Nov 21 06:36:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 06:36:54 2003 Subject: [ python-Bugs-846521 ] error in python's grammar Message-ID: Bugs item #846521, was opened at 2003-11-21 11:36 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=846521&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: error in python's grammar Initial Comment: Python sometimes prints messages like 'expecting a , got a ' This is not English. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 From noreply at sourceforge.net Fri Nov 21 07:31:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 07:31:18 2003 Subject: [ python-Bugs-846544 ] error in python's grammar Message-ID: Bugs item #846544, was opened at 2003-11-21 12: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=846544&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: error in python's grammar Initial Comment: Python sometimes prints messages like 'expecting a , got a ' This is not English. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846544&group_id=5470 From noreply at sourceforge.net Fri Nov 21 07:48:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 07:48:17 2003 Subject: [ python-Feature Requests-846553 ] Addition to break and continue Message-ID: Feature Requests item #846553, was opened at 2003-11-21 12:48 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=846553&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: Addition to break and continue Initial Comment: It would be great if one could use "break for", "break while", "continue for" or "continue while". A silly example: for i in range(100): counter = 0 while 1+1 == 2: counter += 1 if counter > 5: break for "break for" should here jump out of the for-loop, as opposed to just "break" that would jump out of just the while loop. Using "break for" and friends will make code a lot more readable and explicit, and avoid using exception throwing and catching, and other acrobatics. I believe this suggestion is in sync with the Python Design guidelines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470 From noreply at sourceforge.net Fri Nov 21 07:49:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 07:49:27 2003 Subject: [ python-Bugs-846544 ] error in python's grammar Message-ID: Bugs item #846544, was opened at 2003-11-21 12:31 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846544&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: error in python's grammar Initial Comment: Python sometimes prints messages like 'expecting a , got a ' This is not English. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846544&group_id=5470 From noreply at sourceforge.net Fri Nov 21 07:50:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 07:53:15 2003 Subject: [ python-Bugs-846521 ] error in python's grammar Message-ID: Bugs item #846521, was opened at 2003-11-21 11:36 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: error in python's grammar Initial Comment: Python sometimes prints messages like 'expecting a , got a ' This is not English. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-21 12:50 Message: Logged In: YES user_id=6656 Speaking just for myself, I find it pretty hard to care. Are you interested in working on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 From noreply at sourceforge.net Fri Nov 21 07:53:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 07:53:56 2003 Subject: [ python-Feature Requests-846553 ] Addition to break and continue Message-ID: Feature Requests item #846553, was opened at 2003-11-21 12:48 Message generated for change (Settings changed) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: Addition to break and continue Initial Comment: It would be great if one could use "break for", "break while", "continue for" or "continue while". A silly example: for i in range(100): counter = 0 while 1+1 == 2: counter += 1 if counter > 5: break for "break for" should here jump out of the for-loop, as opposed to just "break" that would jump out of just the while loop. Using "break for" and friends will make code a lot more readable and explicit, and avoid using exception throwing and catching, and other acrobatics. I believe this suggestion is in sync with the Python Design guidelines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470 From noreply at sourceforge.net Fri Nov 21 08:02:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 08:02:49 2003 Subject: [ python-Feature Requests-846560 ] Slicing infinity Message-ID: Feature Requests item #846560, was opened at 2003-11-21 13: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=846560&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: Slicing infinity Initial Comment: It would be great to be able to use extended slices instead of range. Here's an example: >>> for i in [0:10:2]: ... print i ... 0 2 4 6 8 A more explicit (but longer) way to write this, could be: for i in infinity[0:10:2]: print i One could alternatively write something like: infinity = range(1000) (but this range is too small) or infinity = range(sys.maxint) (but this gives me a memory-error) or infinity = xrange(sys.maxint) (but xrange cannot be sliced) I've also tried experimenting with iterators and generators, but that would exclude slicing "in thin air" like: for i in [0:10:2]: print i ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 From noreply at sourceforge.net Fri Nov 21 08:08:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 08:08:44 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 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=846564&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Fri Nov 21 08:18:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 08:18:43 2003 Subject: [ python-Feature Requests-846568 ] All numbers are bitarrays too Message-ID: Feature Requests item #846568, was opened at 2003-11-21 13:18 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=846568&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: All numbers are bitarrays too Initial Comment: It would be nice if all numbers could be used as arrays of bits as well. Example: >>> i = 10 >>> i[0] = 1 >>> print i 11 >>> print list(i) [1, 1, 0, 1] >>> "".join(map(lambda b:str(b), l)) '1101' >>> for bit in i: print bit 1 1 0 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846568&group_id=5470 From noreply at sourceforge.net Fri Nov 21 08:25:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 08:25:47 2003 Subject: [ python-Feature Requests-846560 ] Slicing infinity Message-ID: Feature Requests item #846560, was opened at 2003-11-21 13:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Alexander R?dseth (alexanro) >Assigned to: Michael Hudson (mwh) Summary: Slicing infinity Initial Comment: It would be great to be able to use extended slices instead of range. Here's an example: >>> for i in [0:10:2]: ... print i ... 0 2 4 6 8 A more explicit (but longer) way to write this, could be: for i in infinity[0:10:2]: print i One could alternatively write something like: infinity = range(1000) (but this range is too small) or infinity = range(sys.maxint) (but this gives me a memory-error) or infinity = xrange(sys.maxint) (but xrange cannot be sliced) I've also tried experimenting with iterators and generators, but that would exclude slicing "in thin air" like: for i in [0:10:2]: print i ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-21 13:25 Message: Logged In: YES user_id=6656 This is basically PEP 204: http://www.python.org/peps/pep-0204.html which has been rejected. I'm not aware of any compelling reasons to restart the discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 From noreply at sourceforge.net Fri Nov 21 08:29:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 08:29:26 2003 Subject: [ python-Feature Requests-846568 ] All numbers are bitarrays too Message-ID: Feature Requests item #846568, was opened at 2003-11-21 13:18 Message generated for change (Settings changed) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846568&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: All numbers are bitarrays too Initial Comment: It would be nice if all numbers could be used as arrays of bits as well. Example: >>> i = 10 >>> i[0] = 1 >>> print i 11 >>> print list(i) [1, 1, 0, 1] >>> "".join(map(lambda b:str(b), l)) '1101' >>> for bit in i: print bit 1 1 0 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846568&group_id=5470 From noreply at sourceforge.net Fri Nov 21 08:30:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 08:30:57 2003 Subject: [ python-Feature Requests-846560 ] Slicing infinity Message-ID: Feature Requests item #846560, was opened at 2003-11-21 13:02 Message generated for change (Comment added) made by alexanro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 Category: Python Interpreter Core Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Michael Hudson (mwh) Summary: Slicing infinity Initial Comment: It would be great to be able to use extended slices instead of range. Here's an example: >>> for i in [0:10:2]: ... print i ... 0 2 4 6 8 A more explicit (but longer) way to write this, could be: for i in infinity[0:10:2]: print i One could alternatively write something like: infinity = range(1000) (but this range is too small) or infinity = range(sys.maxint) (but this gives me a memory-error) or infinity = xrange(sys.maxint) (but xrange cannot be sliced) I've also tried experimenting with iterators and generators, but that would exclude slicing "in thin air" like: for i in [0:10:2]: print i ---------------------------------------------------------------------- >Comment By: Alexander R?dseth (alexanro) Date: 2003-11-21 13:30 Message: Logged In: YES user_id=679374 Okay, thanks for the checkup! :-) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-21 13:25 Message: Logged In: YES user_id=6656 This is basically PEP 204: http://www.python.org/peps/pep-0204.html which has been rejected. I'm not aware of any compelling reasons to restart the discussion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846560&group_id=5470 From noreply at sourceforge.net Fri Nov 21 09:49:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 09:49:38 2003 Subject: [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-29 16:55 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-11-21 09:49 Message: Logged In: YES user_id=876734 The suggested solution (--without-cxx) did the job. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-11-02 15:01 Message: Logged In: YES user_id=60314 any news on this, i.e., does the --without-cxx solve everything? Just seeing if the bug can be marked as closed... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-03 20:26 Message: Logged In: YES user_id=29957 configure --without-cxx is the magic you probably want. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 10:15 Message: Logged In: YES user_id=876734 I didn't realize that the decision to use g++ as the linker was one that we made here locally (I didn't do the build). We'll try avoiding it and see if things get better. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 10:14 Message: Logged In: YES user_id=21627 I did not suggest to avoid gcc, but to avoid g++ (I'm only guessing here, since you haven't reported the build log, ldd output for pyexpat.so, or similar - but it might be that pyexpat.so was linked with g++, which would explain that it somehow calls __cxa_finalize). pyexpat itself has no C++ in it. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 09:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 09:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Fri Nov 21 11:18:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 11:19:14 2003 Subject: [ python-Bugs-846133 ] os.chmod does not work with a unicode filename Message-ID: Bugs item #846133, was opened at 2003-11-20 16:27 Message generated for change (Comment added) made by meyeet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: M.-A. Lemburg (lemburg) Summary: os.chmod does not work with a unicode filename Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- >Comment By: Eric Meyer (meyeet) Date: 2003-11-21 11:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-20 19:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Fri Nov 21 11:29:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 11:29:42 2003 Subject: [ python-Bugs-824417 ] exception with Message.get_filename() Message-ID: Bugs item #824417, was opened at 2003-10-15 17:39 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824417&group_id=5470 Category: Python Library Group: Python 2.2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: exception with Message.get_filename() Initial Comment: The following scriptlet: -----------t.py----------------- import sys import email msg = email.message_from_file(sys.stdin) for part in msg.walk(): print part.get_params() print part.get_filename() -------------------------------- gets an exception when fed the attached email (extracted from a real life non-spam message). $ python2 t.py Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 11:29 Message: Logged In: YES user_id=12800 This has been fixed in cvs for Python 2.2.4 if that ever gets released. It also works fine for Python 2.3.2. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-15 18:05 Message: Logged In: YES user_id=142072 The documentation for the get_param method suggests the following code when the value is a tuple: param = msg.get_param('foo') if isinstance(param, tuple): param = unicode(param[2], param[0]) The get_filename method follows this advice, but it doesn't work when the encoding is None. I fixed this by changing Message.get_filename to this: def get_filename(self, failobj=None): """Return the filename associated with the payload if present. The filename is extracted from the Content-Disposition header's `filename' parameter, and it is unquoted. """ missing = [] filename = self.get_param('filename', missing, 'content-disposition') if filename is missing: return failobj if isinstance(filename, TupleType): # It's an RFC 2231 encoded parameter newvalue = _unquotevalue(filename) if newvalue[0]: return unicode(newvalue[2], newvalue[0]) return unicode(newvalue[2]) else: newvalue = _unquotevalue(filename.strip()) return newvalue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824417&group_id=5470 From noreply at sourceforge.net Fri Nov 21 11:38:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 11:38:25 2003 Subject: [ python-Bugs-836293 ] email generator can give bad output Message-ID: Bugs item #836293, was opened at 2003-11-05 01:26 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836293&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: John Draper (crunch) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email generator can give bad output Initial Comment: #!/usr/bin/env python #Feedback to crunch@shopip.com #Python 2.3.2 under OpenBSD 3.4 i386 import email print r""" Example of Python email generator bug. If a MIME message is missing the terminating line, the generator creates one for it -only it forgets to add the \n\n to it. This causes the following message to be concatenated to the first. """ #s1 is MIME missing terminating line; #s2 is a proper MIME message. s1="""Received: by spameater (127.0.0.1)... From: "Victor Virus" To: Subject: Unterminated MIME to corrupt your mbox! MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="xxxx" --xxxx Content-Type: text/plain; This is an unterminated MIME, like many viruses generate. I don't care about rights of viruses, but I do care if improper handling of MIME causes following messages to be lost. --xxxx """ s2=s1+"""--xxxx--\n\n""" #Create properly terminator msg1=email.message_from_string(s1) msg2=email.message_from_string(s2) print str(msg1)+str(msg2) print "p.s. Notice how the first message runs into the" print " second message." print " By adding the missing '--', this won't happen." ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 11:38 Message: Logged In: YES user_id=12800 This really isn't a bug in the email package, since it's doing what is expected of it. The MIME RFC actually attaches newlines to the front of any boundary and does not specify any required newlines after the terminator. If you look carefully at msg1 and msg2, you'll find that for the latter, all those extra newlines get assigned to the .epilogue which, like the .preamble is text outside the MIME encapsulation. If you want to use the output of the Generator to create a Unix style mbox format file, you'll need to either add the extra newlines to the epilogue yourself, or checked the str() of msg1 to see if it contains the number of newlines your external (read: mbox) format requires. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=836293&group_id=5470 From noreply at sourceforge.net Fri Nov 21 13:38:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 13:38:29 2003 Subject: [ python-Bugs-826756 ] email/Generator.py: Incorrect header output Message-ID: Bugs item #826756, was opened at 2003-10-20 06:23 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Pronk (mjepronk) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/Generator.py: Incorrect header output Initial Comment: I've found a small bug when using the email/Parser.py classes. When there is a long "Subject" header, it will be wrapped to multiple lines, which are preceded by a tab. This is undesired behaviour, because e-mail clients show this tab in the subject. Especially, Mozilla for Windows shows a strange square symbol. The following code in email/Generator.py (line 180) resolves the problem: else: # Header's got lots of smarts, so use it. if h.lower() == 'subject': cont_ws = ' ' else: cont_ws = '\t' print >> self._fp, Header( v, maxlinelen=self.__maxheaderlen, header_name=h, continuation_ws=cont_ws).encode() For more information you can e-mail me: matthias -at- rubberbiscuit.nl ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 13:38 Message: Logged In: YES user_id=12800 RFC 2822 specifies when and how long headers are supposed to be wrapped, and the default Generator behavior is to be compliant with this standard. I consider it a bug in your mail reader that such long headers are displayed incorrectly (other mail readers display long wrapped headers correctly). Having said this, you have options. You can disable wrapping altogether by passing maxheaderlen=0 to the Generator constructor, or you can create a Generator subclass which overrides the _write_headers() method and passes a different value for continuation_ws. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 From noreply at sourceforge.net Fri Nov 21 14:07:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 14:07:21 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 08:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-21 14:07 Message: Logged In: YES user_id=33168 Ouch! This happens in 2.2 and CVS (I assume 2.3 too). I'll look into this. Fixing this should be a good way to improve performance. :-) Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Fri Nov 21 14:29:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 14:29:32 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 08:08 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-21 14:29 Message: Logged In: YES user_id=31435 Don't panic . "and" doesn't evaluate anything twice. The subtlety here is that "and" and "or" return one of their arguments. If x evaluates to false in "x and y", then "x and y" returns x: >>> class C: ... def __nonzero__(self): return False ... >>> x, y = C(), C() >>> (x and y) is x True >>> (x or y) is y True >>> The second evaluation occurs because "if expr:" has to evaluate expr. That part's got nothing to do with "and", it's entirely to do with "if". None of this is going to change, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-21 14:07 Message: Logged In: YES user_id=33168 Ouch! This happens in 2.2 and CVS (I assume 2.3 too). I'll look into this. Fixing this should be a good way to improve performance. :-) Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Fri Nov 21 14:46:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 14:46:28 2003 Subject: [ python-Bugs-846817 ] control-c is being sent to child thread rather than main Message-ID: Bugs item #846817, was opened at 2003-11-21 19:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846817&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: sheshi sankineni (sheshi) Assigned to: Nobody/Anonymous (nobody) Summary: control-c is being sent to child thread rather than main Initial Comment: Hi All, We just migrated from Python-2.2.1 to Python-2.3.1 and noticed a behavior change with respect to control-c + threads and importing readline module. We have developed a CLI (command line interface) to our hardware using Python (communicating with CORBA). I am providing you with the code (below) which demonstrates the changed behavior in Python-2.3.1 with "import readline" & without "import readline" on Linux Redhat 7.2. The same program works fine on Python- 2.2.1 with or without importing readline and doing control-c ALWAYS trapped by the main program. Any help on this issue will be appreciated thanks -sheshi cli.py ------- import os import signal import sys import cliEngine def handleKeyboardInterrupt(signalNumber, frame) : print 'MAIN THREAD Control-C' def handleSigUsr1(signalNumber, frame) : pass # The main function if __name__ == '__main__': try : # Register a signal handler for ctrl-C, control-z signal.signal(signal.SIGINT, handleKeyboardInterrupt) signal.signal(signal.SIGUSR1, handleSigUsr1) signal.signal(signal.SIGTSTP, signal.SIG_IGN) cliEngine.engine = cliEngine.CliEngine() cliEngine.engine.setPid(os.getpid()) cliEngine.engine.start() while cliEngine.engine.cliEngineRunning : signal.pause() print 'Exiting the main thread' finally : pass cliEngine.py ----------------- import os import signal import sys import threading import readline engine = None class CliEngine(threading.Thread) : # Static members of the class cliEngineRunning = 0 mainThreadPid = 0 def __init__(self) : threading.Thread.__init__(self) self.cliEngineRunning = 1 engine = self def setPid(self, mainPid) : self.mainThreadPid = mainPid def run(self) : print 'calling CliEngine run' self.cliEngineRunning = 1 self.runEngine() def runEngine(self) : while self.cliEngineRunning : try : line = raw_input('# ') if line == "logout" : self.cliEngineRunning = 0 except KeyboardInterrupt : print 'CHILD THREAD Control-C (KeyboardInterrupt)' except EOFError : # ctrl-d to logout from CLI self.cliEngineRunning = 0 except : print 'Unknown Exception' self.cliEngineRunning = 0 print 'Returning from cliEngine.runEngine()' If I remove "import readline" in the above file, control-c is always trapped by the main thread (cli.py) as shown by the output below >>python cli.py calling CliEngine run # MAIN THREAD Control-C # MAIN THREAD Control-C # logout Returning from cliEngine.runEngine() Exiting the main thread If in the above Python file (cliEngine.py), If I include "import readline", control-c will be trapped by the child thread (CliEngine) instead of the main thread, as shown by the output below and the program terminates with segmentation fault >>python cli.py calling CliEngine run # CHILD THREAD Control-C (KeyboardInterrupt) # CHILD THREAD Control-C (KeyboardInterrupt) # # logout Returning from cliEngine.runEngine() Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846817&group_id=5470 From noreply at sourceforge.net Fri Nov 21 14:56:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 14:56:41 2003 Subject: [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 14:56 Message: Logged In: YES user_id=12800 Or at least PyMem_MALLOC, right? See attached patch candidate. If this fixes the problem for you (and if it passes Michael's muster), I'll commit this to the 2.3cvs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-17 07:46 Message: Logged In: YES user_id=6656 Why does binascii call calloc directly? Shouldn't it be calling PyMem_New? ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:14 Message: Logged In: YES user_id=142072 Might as well fix b2a_qp while we are at it: --- ./Modules/binascii.c.aix Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 16:08:25 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } @@ -1206,7 +1206,7 @@ odata = (unsigned char *) calloc(1, odatalen); - if (odata == NULL) { + if (odata == NULL && odatalen > 0) { PyErr_NoMemory(); return NULL; } ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:21:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:22:09 2003 Subject: [ python-Bugs-707707 ] elisp: IM-python menu and newline in function defs Message-ID: Bugs item #707707, was opened at 2003-03-21 14:41 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707707&group_id=5470 Category: None Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Barry A. Warsaw (bwarsaw) Summary: elisp: IM-python menu and newline in function defs Initial Comment: [ forwarded from http://bugs.debian.org/182297 ] the IM-Python menu does not show a function like this: def editor(db, db_name, table_name, #api dbapi,dbapi_exceptions): ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:21 Message: Logged In: YES user_id=12800 Closing after resubmitting on the python-mode project. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-21 15:03 Message: Logged In: YES user_id=12800 assigning to myself although i don't know when i'll have time for python-mode stuff again ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=707707&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:23:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:23:56 2003 Subject: [ python-Bugs-634412 ] RFC 2112 in email package Message-ID: Bugs item #634412, was opened at 2002-11-06 08:14 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634412&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 3 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: RFC 2112 in email package Initial Comment: Figure out if and how to support multipart/related as specified in RFC 2112, in the email package. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:23 Message: Logged In: YES user_id=12800 Moving this to Python 2.4. The email-sig should address this for email 3.0/Python 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634412&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:24:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:24:28 2003 Subject: [ python-Feature Requests-634412 ] RFC 2112 in email package Message-ID: Feature Requests item #634412, was opened at 2002-11-06 08:14 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=634412&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: RFC 2112 in email package Initial Comment: Figure out if and how to support multipart/related as specified in RFC 2112, in the email package. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:24 Message: Logged In: YES user_id=12800 Also moving to Feature Requests ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:23 Message: Logged In: YES user_id=12800 Moving this to Python 2.4. The email-sig should address this for email 3.0/Python 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=634412&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:25:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:25:07 2003 Subject: [ python-Feature Requests-626452 ] Support RFC 2111 in email package Message-ID: Feature Requests item #626452, was opened at 2002-10-21 14:00 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=626452&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 3 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: Support RFC 2111 in email package Initial Comment: Decide whether to support RFC 2111 in the email package. http://www.faqs.org/rfcs/rfc2111.html ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:25 Message: Logged In: YES user_id=12800 Moving this to feature requests for Python 2.4. The email-sig should address this for email 3.0 / Python 2.4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=626452&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:29:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:29:59 2003 Subject: [ python-Bugs-736407 ] Problem With email.MIMEText Package Message-ID: Bugs item #736407, was opened at 2003-05-12 05:41 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Pending Resolution: None Priority: 5 Submitted By: John Abel (judasiscariot) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Problem With email.MIMEText Package Initial Comment: Problem with email.MIMEText. I created a MIMEText message (following the example in the documentation). The problem occurs when as_string() is called. This is the traceback: File "/usr/local/lib/python2.3/email/Message.py", line 113, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/lib/python2.3/email/Generator.py", line 102, in flatten self._write(msg) File "/usr/local/lib/python2.3/email/Generator.py", line 137, in _write self._write_headers(msg) File "/usr/local/lib/python2.3/email/Generator.py", line 183, in _write_headers header_name=h, continuation_ws='\t').encode() File "/usr/local/lib/python2.3/email/Header.py", line 415, in encode return self._encode_chunks(newchunks, maxlinelen) File "/usr/local/lib/python2.3/email/Header.py", line 375, in _encode_chunks _max_append(chunks, s, maxlinelen, extra) File "/usr/local/lib/python2.3/email/quopriMIME.py", line 84, in _max_append L.append(s.lstrip()) AttributeError: 'list' object has no attribute 'lstrip' I'm using 2.3b1, on RH9. The same piece of code works with 2.2.2. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:29 Message: Logged In: YES user_id=12800 There have no follow ups to this message in months, so I'm moving it to Pending status. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-09-03 08:15 Message: Logged In: YES user_id=12800 Sorry, but you're going to have to work harder at trying to boil down the buggy code. When I run ServerMonitor.py, I get an immediate traceback Traceback (most recent call last): File "ServerMonitor.py", line 18, in ? import ThreadUtils, NetMon ImportError: No module named ThreadUtils Here's one thing you can try to do: catch the exception in your code, then pickle the Message object up and post the pickle. I can at least reconstitute the pickle and look at the structure. Also, I'm guessing the problem is somewhere in ProcessMail() in PostITControl.py. Be sure that the mailBody argument is a string and nothing else. ---------------------------------------------------------------------- Comment By: John Abel (judasiscariot) Date: 2003-05-21 04:16 Message: Logged In: YES user_id=221478 The Config.ini will need to modifying to suit your machine settings. Run the ServerMonitor.py, and then run PostITControl.py. PostITControl.py crashes when trying to send a mail. ---------------------------------------------------------------------- Comment By: John Abel (judasiscariot) Date: 2003-05-21 04:13 Message: Logged In: YES user_id=221478 Sorry, been trying to narrow the code down. If I have a bare minimum script, it works, yet the original still fails. I'll upload the required files (3). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-19 15:59 Message: Logged In: YES user_id=12800 I'm moving this to Pending since wthout more information I can't help. This starts the 14 day clock ticking. After 2 weeks this bug report will be closed, unless someone follows up with more information. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-15 10:07 Message: Logged In: YES user_id=12800 Sorry, the attached code sample is incomplete. It is not sufficient for me to reproduce the problem. Please boil down your example to a self-contained -- but as small as possible -- example. ---------------------------------------------------------------------- Comment By: John Abel (judasiscariot) Date: 2003-05-15 05:32 Message: Logged In: YES user_id=221478 Sorry, forgot the comment. When running the script using python2.2 (email 2.4.3), I don't receive any errors, mail gets sent. It only seems to happen with 2.3b. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-05-13 11:45 Message: Logged In: YES user_id=12800 Can you upload the exact code that you wrote that caused this crash? Please don't paste it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:28:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:33:30 2003 Subject: [ python-Bugs-816344 ] Missing import in email example Message-ID: Bugs item #816344, was opened at 2003-10-02 01:05 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816344&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Missing import in email example Initial Comment: The "email-dir.py" example in the email module documentation is missing an import. The MIMEBase is used (when a generic file is found), but MIMEBase is not imported. Putting "from email.MIMEBase import MIMEBase" with the other imports fixes this. This is Python 2.3.1, and also the cvs that anon sf thinks is current. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:28 Message: Logged In: YES user_id=12800 Fixed for both Python 2.3.3a0 and Python 2.4a0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816344&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:36:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:36:11 2003 Subject: [ python-Feature Requests-815563 ] bug with ill-formed rfc822 attachments Message-ID: Feature Requests item #815563, was opened at 2003-09-30 22:32 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Nobody/Anonymous (nobody) Summary: bug with ill-formed rfc822 attachments Initial Comment: The following proglet gets an except with the attached message: -----te.py-------- import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) ------------------ python2 te.py Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:36 Message: Logged In: YES user_id=12800 I'm moving this to a feature request for Python 2.4. There's little that we can do about this in Python 2.3 since the lax parser is only so good at guessing the intent of ill-formed messages. email 2.x can't do what you suggest because that would be a new feature and can't be introduced into Python 2.3. The email-sig is chartered with developing an improved parser for Python 2.4 that might be able to handle this. In the meantime, you could probably derive your own Parser class that might be able to worm around this problem in an application specific way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:42:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:43:02 2003 Subject: [ python-Bugs-794458 ] email bug with message/rfc822 Message-ID: Bugs item #794458, was opened at 2003-08-24 23:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794458&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email bug with message/rfc822 Initial Comment: Attached is a test message that the email module can't even read in andd write back out. It drops a whole section of headers for the message/rfc822 part. The old email modules handle this message correctly. Let me clarify the problem with a short test: ------te.py-------- import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) ------------------- $ python2 te.py test8.out $ diff test8 test8.out .... lots of differences that shouldn't be there .... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:42 Message: Logged In: YES user_id=12800 I believe this bug is out of date. When I tried this in Python 2.3.2, the only differences between the original file and the outputted file are in whitespace and wrapped long lines. That's not unexpected. You could eliminate even these differences by instantiating your own Generator class and using its .flatten() method, rather than relying on the msg.as_string() convenience. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-08-25 22:48 Message: Logged In: YES user_id=142072 Here is a fix for this bug. The problem is that the message attachment is not being decoded before parsing. *** Parser.py Mon Aug 25 22:43:34 2003 --- /usr/lib/python2.2/email/Parser.py Tue Nov 12 16:50:20 2002 *************** *** 249,262 **** elif container.get_main_type() == 'message': # Create a container for the payload, but watch out for there not # being any headers left - container.set_payload(fp.read()) - fp = StringIO(container.get_payload(decode=True)) try: msg = self.parse(fp) except Errors.HeaderParseError: msg = self._class() self._parsebody(msg, fp) ! container.set_payload([msg]) else: container.set_payload(fp.read()) --- 249,260 ---- elif container.get_main_type() == 'message': # Create a container for the payload, but watch out for there not # being any headers left try: msg = self.parse(fp) except Errors.HeaderParseError: msg = self._class() self._parsebody(msg, fp) ! container.attach(msg) else: container.set_payload(fp.read()) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794458&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:45:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:46:01 2003 Subject: [ python-Feature Requests-795081 ] email.Message param parsing problem II Message-ID: Feature Requests item #795081, was opened at 2003-08-25 23:37 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=795081&group_id=5470 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Nobody/Anonymous (nobody) Summary: email.Message param parsing problem II Initial Comment: The enclosed real life (inactivated) virus message causes email.Message to fail to find the multipart attachments. This is because the headers following Content-Type are indented, causing email.Message to properly append them to Content-Type. The trick is that the boundary is quoted, and Outhouse^H^H^H^H^Hlook apparently gets a value of 'bound' for boundary, whereas email.Message gets the value '"bound"\n\tX-Priority...'. email.Utils.unqoute apparently gives up and doesn't remove any quotes. I believe that unqoute should return just what is between the quotes, so that '"abc" def' would be unquoted to 'abc'. In fact, my email filtering software (http://bmsi.com/python/milter.html) works correctly on all kinds of screwy mail using my version of unquote using this heuristic. I believe that header used by the virus is invalid, so a STRICT parser should reject it, but a tolerant parser (such as a virus scanner would use) should use the heuristic. Here is a brief script to show the problem (attached file in test/virus5): ----------t.py---------- import email msg = email.message_from_file(open('test/virus5','r')) print msg.get_params() --------------------- $ python2 t.py [('multipart/mixed', ''), ('boundary', '"bound"\n\tX-Priority: 3\n\tX-MSMail-Priority: Normal\n\tX-Mailer: Microsoft Outlook Express 5.50.4522.1300\n\tX-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1300')] ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:45 Message: Logged In: YES user_id=12800 Moving this to feature requests for Python 2.4. If appropriate, the email-sig should address this in the intended new lax parser for email 3.0 / Python 2.4. We can't add this to the Python 2.3 (or earlier) maintenance releases. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-08-25 23:57 Message: Logged In: YES user_id=142072 Here is a proposed fix for email.Util.unquote (except it should test for a 'strict' mode flag, which is current only in Parser): def unquote(str): """Remove quotes from a string.""" if len(str) > 1: if str.startswith('"'): if str.endswith('"'): str = str[1:-1] else: # remove garbage after trailing quote try: str = str[1:str[1:].index('"')+1] except: return str return str.replace('\\', '\').replace('\"', '"') if str.startswith('<') and str.endswith('>'): return str[1:-1] return str Actually, I replaced only email.Message._unquotevalue for my application to minimize the impact. That would also be a good place to check for a STRICT flag stored with the message object. Perhaps the Parser should set the Message _strict flag from its own _strict flag. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=795081&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:47:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:47:31 2003 Subject: [ python-Bugs-798274 ] absolute import patch breaks external users of test.regrtest Message-ID: Bugs item #798274, was opened at 2003-08-31 17:39 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470 Category: Extension Modules >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Riley (nriley) >Assigned to: Nobody/Anonymous (nobody) Summary: absolute import patch breaks external users of test.regrtest Initial Comment: I've built a test system using Python's test.regrtest mechanism, and it worked very well under Python 2.2. In Python 2.3, the output looks like this: test_inttypes test_inttypes skipped -- No module named test_inttypes test_string test_unittest test_unittest skipped -- No module named test_unittest [...] I've tracked the problem down to a change made about a year ago. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ python/dist/src/Lib/test/regrtest.py.diff?r1=1.91&r2=1.92 test.regrtest is finding the modules, but is failing to import them because it is prepending 'test.' to the module names, in a mistaken assumption that all tests will be in a package named test. As it happened, I had my test modules inside a directory named 'test', and I tried making the directory a module and futzing with sys.path to get it to work, but now test.regrtest can't find the system implementation of test.test_support. I've also now got the problem of namespace pollution - the "test_string" above is Python's version, not my version with the same name. So, it appears non-Python users of test.regrtest are broken by this change in Python 2.3. I was pretty careful to make sure that I was doing something supported - the docstring for test.regrtest.main explicitly refers to non-Python test suite users - and ran into some weird cases like test.* not being installed on Mac OS X by default, but it worked very well otherwise. One potential solution would be that if 'testdir' is specified, test.regrtest.main() does not attempt to prepend 'test.' to the module names. This seems to match pretty well with the spirit of the documentation for that method. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:47 Message: Logged In: YES user_id=12800 I'm relinquishing assignment of this issue and moving it to Python 2.4. ---------------------------------------------------------------------- Comment By: Nicholas Riley (nriley) Date: 2003-09-17 18:53 Message: Logged In: YES user_id=34933 Thanks for the helpful response. Sorry I didn't get around to writing any documentation, but a patch is here: http://sourceforge.net/tracker/index.php? func=detail&aid=808210&group_id=5470&atid=305470 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-09-01 23:54 Message: Logged In: YES user_id=12800 IIRC, this patch was necessary because some tests required absolute imports and we cannot mix relative and absolute imports in the test suite. IMO, regrtest's primary mission in life is to support Python's test suite and any other use is secondary (for example, it isn't documented in the standard library manual). OTOH, you might think about contributing a patch that allows regrtest to be used outside the Python test suite, but doesn't break the absolute import requirement while in the test suite. (You might also consider adding some standard lib documentation to your patch ). The other problems you mention are inherent in Python's import machinery. If you have two packages named "test" on your sys.path, Python will not by default search them both for submodules. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-01 12:51 Message: Logged In: YES user_id=80475 Barry, this was your change. Would you take a look at this bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=798274&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:47:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:48:00 2003 Subject: [ python-Feature Requests-642309 ] pygettext should be installed Message-ID: Feature Requests item #642309, was opened at 2002-11-22 09:28 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=642309&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Nobody/Anonymous (nobody) Summary: pygettext should be installed Initial Comment: Tools/i18n/pygettext.py should be installed as "pygettext", similar to the "idle" script. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=642309&group_id=5470 From noreply at sourceforge.net Fri Nov 21 15:52:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 15:53:16 2003 Subject: [ python-Feature Requests-815563 ] bug with ill-formed rfc822 attachments Message-ID: Feature Requests item #815563, was opened at 2003-09-30 22:32 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: bug with ill-formed rfc822 attachments Initial Comment: The following proglet gets an except with the attached message: -----te.py-------- import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) ------------------ python2 te.py Comment By: Stuart D. Gathman (customdesigned) Date: 2003-11-21 15:52 Message: Logged In: YES user_id=142072 Your disposition makes sense. Since all messages with invalid MIME boundaries are either invalid themselves, or bounces or forwards of invalid messages, my work around is to issue an SMTP reject: if exc_type == email.Errors.BoundaryError: self.setreply('554','5.7.7', 'Boundary error in your message, are you a spammer?') For 2.4, I recommend that rfc822 attachments be parsed independently of the enclosing message. If the attachment is invalid, turn it into a plain rfc822 message object or a string. Although the rfc822 module is deprecated, I find it very useful to represent mail that may or may not correctly follow MIME standards. Examples include forwarded spam (using the new innoculation RFC), and generic mailbox processing. I suggest retaining rfc822 as a 'featureless' message with only headers and body. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:36 Message: Logged In: YES user_id=12800 I'm moving this to a feature request for Python 2.4. There's little that we can do about this in Python 2.3 since the lax parser is only so good at guessing the intent of ill-formed messages. email 2.x can't do what you suggest because that would be a new feature and can't be introduced into Python 2.3. The email-sig is chartered with developing an improved parser for Python 2.4 that might be able to handle this. In the meantime, you could probably derive your own Parser class that might be able to worm around this problem in an application specific way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 From noreply at sourceforge.net Fri Nov 21 16:00:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 16:01:20 2003 Subject: [ python-Feature Requests-815563 ] bug with ill-formed rfc822 attachments Message-ID: Feature Requests item #815563, was opened at 2003-09-30 22:32 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: bug with ill-formed rfc822 attachments Initial Comment: The following proglet gets an except with the attached message: -----te.py-------- import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) ------------------ python2 te.py Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 16:00 Message: Logged In: YES user_id=12800 Note that if you're looking for something that just parses messages into headers and bodies, you might look at the HeaderParser class. You'd have to write a bit of code to get an outer parser that falls back to a HeaderParser on invalid unparseable inner messages. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-11-21 15:52 Message: Logged In: YES user_id=142072 Your disposition makes sense. Since all messages with invalid MIME boundaries are either invalid themselves, or bounces or forwards of invalid messages, my work around is to issue an SMTP reject: if exc_type == email.Errors.BoundaryError: self.setreply('554','5.7.7', 'Boundary error in your message, are you a spammer?') For 2.4, I recommend that rfc822 attachments be parsed independently of the enclosing message. If the attachment is invalid, turn it into a plain rfc822 message object or a string. Although the rfc822 module is deprecated, I find it very useful to represent mail that may or may not correctly follow MIME standards. Examples include forwarded spam (using the new innoculation RFC), and generic mailbox processing. I suggest retaining rfc822 as a 'featureless' message with only headers and body. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 15:36 Message: Logged In: YES user_id=12800 I'm moving this to a feature request for Python 2.4. There's little that we can do about this in Python 2.3 since the lax parser is only so good at guessing the intent of ill-formed messages. email 2.x can't do what you suggest because that would be a new feature and can't be introduced into Python 2.3. The email-sig is chartered with developing an improved parser for Python 2.4 that might be able to handle this. In the meantime, you could probably derive your own Parser class that might be able to worm around this problem in an application specific way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=815563&group_id=5470 From noreply at sourceforge.net Fri Nov 21 16:08:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 16:09:08 2003 Subject: [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2003-11-21 16:08 Message: Logged In: YES user_id=142072 Are you sure that the following code doesn't depend on calloc clearing the memory to 0? Does PyMem_MALLOC clear to 0? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 14:56 Message: Logged In: YES user_id=12800 Or at least PyMem_MALLOC, right? See attached patch candidate. If this fixes the problem for you (and if it passes Michael's muster), I'll commit this to the 2.3cvs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-17 07:46 Message: Logged In: YES user_id=6656 Why does binascii call calloc directly? Shouldn't it be calling PyMem_New? ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:14 Message: Logged In: YES user_id=142072 Might as well fix b2a_qp while we are at it: --- ./Modules/binascii.c.aix Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 16:08:25 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } @@ -1206,7 +1206,7 @@ odata = (unsigned char *) calloc(1, odatalen); - if (odata == NULL) { + if (odata == NULL && odatalen > 0) { PyErr_NoMemory(); return NULL; } ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Fri Nov 21 16:29:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 16:29:18 2003 Subject: [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 16:29 Message: Logged In: YES user_id=12800 Whoops, you're right. I don't think PyMem_MALLOC guarantees that, so the patch isn't quite right (we'd have to zero it out ourselves). ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-11-21 16:08 Message: Logged In: YES user_id=142072 Are you sure that the following code doesn't depend on calloc clearing the memory to 0? Does PyMem_MALLOC clear to 0? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-11-21 14:56 Message: Logged In: YES user_id=12800 Or at least PyMem_MALLOC, right? See attached patch candidate. If this fixes the problem for you (and if it passes Michael's muster), I'll commit this to the 2.3cvs. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-17 07:46 Message: Logged In: YES user_id=6656 Why does binascii call calloc directly? Shouldn't it be calling PyMem_New? ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:14 Message: Logged In: YES user_id=142072 Might as well fix b2a_qp while we are at it: --- ./Modules/binascii.c.aix Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 16:08:25 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } @@ -1206,7 +1206,7 @@ odata = (unsigned char *) calloc(1, odatalen); - if (odata == NULL) { + if (odata == NULL && odatalen > 0) { PyErr_NoMemory(); return NULL; } ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Fri Nov 21 17:06:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 17:06:44 2003 Subject: [ python-Bugs-844123 ] "up" instead of "down" in turtle module documentation Message-ID: Bugs item #844123, was opened at 2003-11-17 21:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844123&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) >Assigned to: Raymond Hettinger (rhettinger) Summary: "up" instead of "down" in turtle module documentation Initial Comment: At: http://www.python.org/doc/current/lib/module-turtle.html it says: down() Move the pen up -- draw when moving. which should be "Move the pen down...." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844123&group_id=5470 From noreply at sourceforge.net Fri Nov 21 17:25:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 17:25:21 2003 Subject: [ python-Bugs-846938 ] email.Parser.Parser doesn't check for valid Content-Type Message-ID: Bugs item #846938, was opened at 2003-11-21 15:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846938&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: email.Parser.Parser doesn't check for valid Content-Type Initial Comment: See the attached traceback illustrating how to reproduce the problem. A sample triggering message is also attached. The problem is that the Content-Type is 'multipour alternative', but the Content-Type field has a valid 'boundary=' parameter. The parser doesn't check that Content-Type is valid; it just creates sub-Message objects for each part it finds that is separated by the boundary. Then, when Generator goes to check Content-Type, it discovers that the content-type *is* invalid and it returns 'text/plain' instead! Generator tries to _handle_text and instead finds the list of sub-Message objects. BOOM! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846938&group_id=5470 From noreply at sourceforge.net Fri Nov 21 17:27:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 17:27:48 2003 Subject: [ python-Bugs-846938 ] email.Parser.Parser doesn't check for valid Content-Type Message-ID: Bugs item #846938, was opened at 2003-11-21 15:25 Message generated for change (Settings changed) made by jasonrm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846938&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Parser.Parser doesn't check for valid Content-Type Initial Comment: See the attached traceback illustrating how to reproduce the problem. A sample triggering message is also attached. The problem is that the Content-Type is 'multipour alternative', but the Content-Type field has a valid 'boundary=' parameter. The parser doesn't check that Content-Type is valid; it just creates sub-Message objects for each part it finds that is separated by the boundary. Then, when Generator goes to check Content-Type, it discovers that the content-type *is* invalid and it returns 'text/plain' instead! Generator tries to _handle_text and instead finds the list of sub-Message objects. BOOM! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846938&group_id=5470 From noreply at sourceforge.net Fri Nov 21 19:51:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 19:52:18 2003 Subject: [ python-Bugs-846133 ] os.chmod does not work with a unicode filename Message-ID: Bugs item #846133, was opened at 2003-11-21 06:27 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: M.-A. Lemburg (lemburg) Summary: os.chmod does not work with a unicode filename Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 09:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-22 01:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 09:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Fri Nov 21 20:43:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 20:46:57 2003 Subject: [ python-Feature Requests-846553 ] Addition to break and continue Message-ID: Feature Requests item #846553, was opened at 2003-11-21 15:48 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexander R?dseth (alexanro) Assigned to: Nobody/Anonymous (nobody) Summary: Addition to break and continue Initial Comment: It would be great if one could use "break for", "break while", "continue for" or "continue while". A silly example: for i in range(100): counter = 0 while 1+1 == 2: counter += 1 if counter > 5: break for "break for" should here jump out of the for-loop, as opposed to just "break" that would jump out of just the while loop. Using "break for" and friends will make code a lot more readable and explicit, and avoid using exception throwing and catching, and other acrobatics. I believe this suggestion is in sync with the Python Design guidelines. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-11-22 04:43 Message: Logged In: YES user_id=39274 What you will do to exit from outer of two for's from inside inner? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470 From noreply at sourceforge.net Fri Nov 21 21:19:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 21:19:27 2003 Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more strict checking Message-ID: Bugs item #847019, was opened at 2003-11-22 05: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=847019&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime initialization needs more strict checking Initial Comment: Friend of mine wrote following program: --------------------------------- import datetime t=datetime.datetime('1995-03-25') print t.ctime() --------------------------------- This is obviously wrong code, but instead of reporting this at second line python crashes on third line (with ctime). Info: Using Python 2.3.2 on Windows 2000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 From noreply at sourceforge.net Fri Nov 21 21:39:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 21:39:46 2003 Subject: [ python-Bugs-847024 ] NotImplemented return value misinterpreted in new classes Message-ID: Bugs item #847024, was opened at 2003-11-22 05: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=847024&group_id=5470 Category: Type/class unification Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: NotImplemented return value misinterpreted in new classes Initial Comment: Following program: ------------------------------ notimpl.py class CClassic: def __add__(self, other): return NotImplemented def __mul__(self, other): return NotImplemented class CNew(object): def __add__(self, other): return NotImplemented def __mul__(self, other): return NotImplemented a=CClassic() try: print a+2 except Exception, e: print e try: print a*2 except Exception, e: print e a=CNew() try: print a+2 except Exception, e: print e try: print a*2 except Exception, e: print e -------------------------------- Output following (correct) under Python 2.2: unsupported operand types for +: 'instance' and 'int' unsupported operand type(s) for *: 'instance' and 'int' unsupported operand types for +: 'CNew' and 'int' unsupported operand type(s) for *: 'CNew' and 'int' And following (wrong) under Python 2.3[.2]: unsupported operand type(s) for +: 'instance' and 'int' unsupported operand type(s) for *: 'instance' and 'int' unsupported operand type(s) for +: 'CNew' and 'int' NotImplemented ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847024&group_id=5470 From noreply at sourceforge.net Fri Nov 21 22:16:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 21 22:16:43 2003 Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more strict checking Message-ID: Bugs item #847019, was opened at 2003-11-21 21:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Michael Dubner (dubnerm) >Assigned to: Guido van Rossum (gvanrossum) Summary: datetime.datetime initialization needs more strict checking Initial Comment: Friend of mine wrote following program: --------------------------------- import datetime t=datetime.datetime('1995-03-25') print t.ctime() --------------------------------- This is obviously wrong code, but instead of reporting this at second line python crashes on third line (with ctime). Info: Using Python 2.3.2 on Windows 2000 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-21 22:16 Message: Logged In: YES user_id=31435 LOL! Assigned to Guido for his amusement. One string argument of exactly size 10 triggers the "secret" backdoor to construct a datetime.datetime from a pickle. The datetime constructed here is insane, and provokes Microsoft's library into crashing. In a debug build, it triggers an assertion error in the datetime module: >>> import datetime [16122 refs] >>> datetime.datetime('1995-03-25') datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973) [16124 refs] >>> _.ctime() Assertion failed: month <= 12, file C:\Code\python\Modules\datetimemodule.c, line 189 Boosted priority since it's a way to crash the interpreter on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 From noreply at sourceforge.net Sat Nov 22 01:42:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 22 01:42:45 2003 Subject: [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-30 06:55 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-22 17:42 Message: Logged In: YES user_id=29957 Closing as not a bug. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-11-22 01:49 Message: Logged In: YES user_id=876734 The suggested solution (--without-cxx) did the job. ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2003-11-03 07:01 Message: Logged In: YES user_id=60314 any news on this, i.e., does the --without-cxx solve everything? Just seeing if the bug can be marked as closed... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 10:26 Message: Logged In: YES user_id=29957 configure --without-cxx is the magic you probably want. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-04 00:15 Message: Logged In: YES user_id=876734 I didn't realize that the decision to use g++ as the linker was one that we made here locally (I didn't do the build). We'll try avoiding it and see if things get better. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 00:14 Message: Logged In: YES user_id=21627 I did not suggest to avoid gcc, but to avoid g++ (I'm only guessing here, since you haven't reported the build log, ldd output for pyexpat.so, or similar - but it might be that pyexpat.so was linked with g++, which would explain that it somehow calls __cxa_finalize). pyexpat itself has no C++ in it. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 23:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 23:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Sat Nov 22 14:12:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 22 14:12:04 2003 Subject: [ python-Bugs-847346 ] textwrap ignoring fix_sentence_endings for single lines Message-ID: Bugs item #847346, was opened at 2003-11-22 19: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=847346&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tom Lynn (tlynn) Assigned to: Nobody/Anonymous (nobody) Summary: textwrap ignoring fix_sentence_endings for single lines Initial Comment: >>> import textwrap >>> t=textwrap. TextWrapper(fix_sentence_endings=True) >>> print t.fill("A short line. Note the single space.") A short line. Note the single space. TextWrapper.wrap() is implemented as: def wrap(self, text): text = self._munge_whitespace(text) indent = self.initial_indent # *** Next line seems to be the bug *** if len(text) + len(indent) <= self.width: return [indent + text] chunks = self._split(text) if self.fix_sentence_endings: self._fix_sentence_endings(chunks) return self._wrap_chunks(chunks) (if sf breaks the indentation, check the actual source!) That early-return "if" clause seems to be an incorrect optimisation which skips fix_sentence_endings. Commenting it out seems to fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847346&group_id=5470 From noreply at sourceforge.net Sun Nov 23 10:21:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 10:21:44 2003 Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Message-ID: Bugs item #847665, was opened at 2003-11-24 02: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=847665&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Initial Comment: from xml.sax.saxutils import XMLGenerator g = XMLGenerator(encoding='utf8') STREAM_NAMESPACE = 'http://etherx.jabber.org/streams' CLIENT_NAMESPACE = 'jabber:client' g.startDocument() g.startPrefixMapping('stream', STREAM_NAMESPACE) g.startPrefixMapping('client', CLIENT_NAMESPACE) g.startElementNS( (STREAM_NAMESPACE, 'stream'), 'stream', {(None,'xmlns'): CLIENT_NAMESPACE} ) Dies with: Traceback (most recent call last): File "tst.py", line 11, in ? g.startElementNS( File "/System/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/xml/sax/saxutils.py", line 124, in startElementNS name = self._current_context[name[0]] + ":" + name[1] KeyError: 'x' Changing the end of XMLGenerator.startElementNS to the following makes it work the way I expect: for (name, value) in attrs.items(): if name[0] is None: name = name[1] else: name = self._current_context[name[0]] + ":" + name[1] self._out.write(' %s=%s' % (name, quoteattr(value))) self._out.write('>') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 From noreply at sourceforge.net Sun Nov 23 13:51:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 13:51:36 2003 Subject: [ python-Bugs-847778 ] Nested scope Message-ID: Bugs item #847778, was opened at 2003-11-23 19: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=847778&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Behran (jojoworks) Assigned to: Nobody/Anonymous (nobody) Summary: Nested scope Initial Comment: I suggest you adding a keyword, say "nested" to explicitly bound the name to the upper level of nested scope. This keyword would be similar to "global", which bounds the name to the top level. See the attachment for the idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847778&group_id=5470 From noreply at sourceforge.net Sun Nov 23 13:53:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 13:53:25 2003 Subject: [ python-Bugs-847778 ] Keyword similar to "global" for nested scopes wanted Message-ID: Bugs item #847778, was opened at 2003-11-23 19:51 Message generated for change (Settings changed) made by jojoworks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847778&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jozef Behran (jojoworks) Assigned to: Nobody/Anonymous (nobody) >Summary: Keyword similar to "global" for nested scopes wanted Initial Comment: I suggest you adding a keyword, say "nested" to explicitly bound the name to the upper level of nested scope. This keyword would be similar to "global", which bounds the name to the top level. See the attachment for the idea. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847778&group_id=5470 From noreply at sourceforge.net Sun Nov 23 15:25:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 15:25:12 2003 Subject: [ python-Bugs-847812 ] 64 bit solaris versus /usr/local/lib Message-ID: Bugs item #847812, was opened at 2003-11-23 15:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847812&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: 64 bit solaris versus /usr/local/lib Initial Comment: setup.py sticks /usr/local/lib in to the link path when building modules. On a 64-bit solaris machine, the libraries in there may well be 32-bit, and not work. There needs to be some provision to control this, I think. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847812&group_id=5470 From noreply at sourceforge.net Sun Nov 23 15:44:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 15:44:13 2003 Subject: [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-29 20:36 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-11-23 15:44 Message: Logged In: YES user_id=876734 I'm running into issues trying to come up with a clean version of this. I'd like to know what you think of some of these before I try to port what I've got into 2.4 and come up with patches. 1) setup.py seems to have no way to be selective about which modules to build. What if I don't want to try (and then fail make install) to build, for example, ssl? 2) setup.py makes assumptions about pathnames. It always puts /usr/local/lib into the build path. On a 64-bit solaris or HP system, this can lead to a mess, if the 64 bit libraries are somewhere else. 3) There is an existing provision to add additional libs to the build in setup.py, but it's disabled if the prefix is /usr. Why? I have this feeling that someone had a plan here that I'm too obtuse to make out which would offer a shorter path to a solution then I'm getting tangled up in, for managing the build of these modules. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 08:42 Message: Logged In: YES user_id=21627 You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-31 07:22 Message: Logged In: YES user_id=876734 To turn my patches into things that anyone else would want, I need to know what to put in the -L that will be required. At the time we're building the main python distro, that's straightforward. When a user builds an individual module, is there a sensible path relative to PYTHONHOME I can use? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 05:05 Message: Logged In: YES user_id=21627 Please do provide patches. Take into account that modules may be built either with distutils, or through Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Sun Nov 23 16:46:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 16:46:44 2003 Subject: [ python-Bugs-847845 ] struct.calcsize mismatch Message-ID: Bugs item #847845, was opened at 2003-11-23 16:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847845&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Marc Schraffenberger (schraf) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize mismatch Initial Comment: Python 2.3 (#2, Sep 2 2003, 14:46:01) [GCC 3.1] on linux2 Python 2.3.2 (#1, Nov 21 2003, 10:31:27) [GCC 3.2.2] on irix6 I was using the struct.calcsize function to get the size of a byte and a long, although I was getting mismatch errors when running the code. I found that calcsize was giving different results when changing the order of the format. example: struct.calcsize('BL') -> 8 struct.calcsize('LB') -> 5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847845&group_id=5470 From noreply at sourceforge.net Sun Nov 23 20:36:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 23 20:36:38 2003 Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more strict checking Message-ID: Bugs item #847019, was opened at 2003-11-22 05:19 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Michael Dubner (dubnerm) Assigned to: Guido van Rossum (gvanrossum) Summary: datetime.datetime initialization needs more strict checking Initial Comment: Friend of mine wrote following program: --------------------------------- import datetime t=datetime.datetime('1995-03-25') print t.ctime() --------------------------------- This is obviously wrong code, but instead of reporting this at second line python crashes on third line (with ctime). Info: Using Python 2.3.2 on Windows 2000 ---------------------------------------------------------------------- >Comment By: Michael Dubner (dubnerm) Date: 2003-11-24 04:36 Message: Logged In: YES user_id=39274 Of cause i've seen that backdoor, but from my point of view constructor is not so time-critical that insertion of sanity chechs will slow down in most (sane) scenarios. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-22 06:16 Message: Logged In: YES user_id=31435 LOL! Assigned to Guido for his amusement. One string argument of exactly size 10 triggers the "secret" backdoor to construct a datetime.datetime from a pickle. The datetime constructed here is insane, and provokes Microsoft's library into crashing. In a debug build, it triggers an assertion error in the datetime module: >>> import datetime [16122 refs] >>> datetime.datetime('1995-03-25') datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973) [16124 refs] >>> _.ctime() Assertion failed: month <= 12, file C:\Code\python\Modules\datetimemodule.c, line 189 Boosted priority since it's a way to crash the interpreter on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 From noreply at sourceforge.net Mon Nov 24 00:28:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 00:28:21 2003 Subject: [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: Bugs item #651701, was opened at 2002-12-10 23:10 Message generated for change (Comment added) made by astraw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Fein (pafein) Assigned to: Nobody/Anonymous (nobody) Summary: Bozo getstate w/ slots overrides base Initial Comment: The bozo __getstate__ set automatically on classes defining __slots__ overrides any __getstate__ defined in a base class. This makes writing a mixin to implement this method impossible. ---------------------------------------------------------------------- Comment By: Andrew Straw (astraw) Date: 2003-11-24 05:28 Message: Logged In: YES user_id=210276 I'm experiencing this behavior on Python 2.2.2 and 2.2.3. I don't get it on 2.2(.0) or 2.3(.x). Here's a script that demonstrates: (Sorry SF doesn't seem to have a nice attachment feature for comments.) import sys print 'Python version',sys.version print def recursive_base_class_finder(klass): """A function to find all base classes.""" result = [klass] for base_class in klass.__bases__: for base_base_class in recursive_base_class_finder(base_class): result.append(base_base_class) # Make only a single copy of each class found result2 = [] for r in result: if r not in result2: result2.append(r) return result2 class A(object): __slots__ = ['a'] def __getstate__(self): """support for being pickled""" result = {} classes = recursive_base_class_finder(self.__class__) for klass in classes: if hasattr(klass,'__slots__'): for attr in klass.__slots__: if hasattr(self,attr): result[attr] = getattr(self,attr) return result def __setstate__(self,dict): for attr in dict.keys(): setattr(self,attr,dict[attr]) def __init__(self): self.a='a' class B(A): __slots__ = ['b'] def __init__(self): A.__init__(self) self.b = 'b' a1=A() b1=B() import pickle ap = pickle.dumps(a1) bp = pickle.dumps(b1) a2 = pickle.loads(ap) b2 = pickle.loads(bp) if a2.a == 'a': print 'pickling/unpickling ok' else: print 'WARNING: pickling/unpickling failed' if b2.a == 'a' and b2.b == 'b': print 'pickling/unpickling on derived class ok' else: print 'WARNING: pickling/unpickling on dericed class failed' try: a2.xx = 'x' failed = 0 except: failed = 1 if not failed: print "WARNING: assigned to attribute not in __slots__" try: b2.xx = 'x' failed = 0 except: failed = 1 if not failed: print "WARNING: assigned to attribute in derived class not in __slots__" ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 01:36 Message: Logged In: YES user_id=80475 Peter, is this still an issue? Can you attach a script demonstrating the problem? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 22:15 Message: Logged In: YES user_id=33168 There was an issue with that, IIRC. There was a discussion on python-dev a while ago which Guido talked about the issues. I don't remember when or what the issues were. Probably about 3-6 months ago. I think the code in this area may have changed, so it would be beneficial to test with 2.3b1. ---------------------------------------------------------------------- Comment By: Peter Fein (pafein) Date: 2003-05-22 22:09 Message: Logged In: YES user_id=639329 This issue is that although the base class B defines a __getstate__, the class C2 overrides it b/c it contains __slots__. Basically, I'm suggesting that base classes should be checked for getstate instead of only looking at the class that defines slots before adding the bozo'd version. Unfortunately, I don't have a 2.3* version to play with at the moment. Please let me know if this clarifies things. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 21:58 Message: Logged In: YES user_id=33168 What do you expect to be printed? I'm not sure what you want changed. Have you tested with 2.3b1? Does this meet your needs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 From noreply at sourceforge.net Mon Nov 24 00:39:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 00:39:16 2003 Subject: [ python-Bugs-775353 ] IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Message-ID: Bugs item #775353, was opened at 2003-07-21 18:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 Category: IDLE Group: Python 2.4 Status: Open >Resolution: Fixed Priority: 6 Submitted By: Matthew Shomphe (mshomphe) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Initial Comment: Info: -Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32: 36) [MSC v.1200 32 bit (Intel)] on win32 -IDLE Version:IDLE 1.0rc1 -OS: Windows 2000 SP4 -Source: Installed from Installer on website (http://www. python.org/ftp/python/2.3/Python-2.3c1.exe) Behavior: In the "File" dropdown menu in IDLE, the listed keybind for "Save As" is Ctrl+Shift+S. This does not work. When you hit Ctrl+Shift+S, nothing happens. Additionally, the keybind for "Save Copy As...", Alt+Shift+S, does not work. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-11-24 00:39 Message: Logged In: YES user_id=149084 config-keys.def 1.20 configHandler.py 1.32 keybindingDialog.py 1.12 2.3 Backport Candidate ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:23 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork Bug 755647 None of the bindings with a Shift modifier work because it is then necessary to use the upper case keysym. IDLE is using the lower case. ---------------------------------------------------------------------- Comment By: Matthew Shomphe (mshomphe) Date: 2003-07-21 19:32 Message: Logged In: YES user_id=716326 Checking through the code, it seems that the problem is in the file "configHandler.py". The bindings are assigned with _lowercase_ letters: '<>': [''], '<>': [''], So the keybindings will work when CAPSLOCK is active. Otherwise, it won't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 From noreply at sourceforge.net Mon Nov 24 03:40:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 03:40:42 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 14:08 Message generated for change (Comment added) made by amauryf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- >Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 09:40 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-21 20:29 Message: Logged In: YES user_id=31435 Don't panic . "and" doesn't evaluate anything twice. The subtlety here is that "and" and "or" return one of their arguments. If x evaluates to false in "x and y", then "x and y" returns x: >>> class C: ... def __nonzero__(self): return False ... >>> x, y = C(), C() >>> (x and y) is x True >>> (x or y) is y True >>> The second evaluation occurs because "if expr:" has to evaluate expr. That part's got nothing to do with "and", it's entirely to do with "if". None of this is going to change, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-21 20:07 Message: Logged In: YES user_id=33168 Ouch! This happens in 2.2 and CVS (I assume 2.3 too). I'll look into this. Fixing this should be a good way to improve performance. :-) Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Mon Nov 24 03:41:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 03:41:06 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 14:08 Message generated for change (Comment added) made by amauryf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- >Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 09:41 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 09:40 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-21 20:29 Message: Logged In: YES user_id=31435 Don't panic . "and" doesn't evaluate anything twice. The subtlety here is that "and" and "or" return one of their arguments. If x evaluates to false in "x and y", then "x and y" returns x: >>> class C: ... def __nonzero__(self): return False ... >>> x, y = C(), C() >>> (x and y) is x True >>> (x or y) is y True >>> The second evaluation occurs because "if expr:" has to evaluate expr. That part's got nothing to do with "and", it's entirely to do with "if". None of this is going to change, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-21 20:07 Message: Logged In: YES user_id=33168 Ouch! This happens in 2.2 and CVS (I assume 2.3 too). I'll look into this. Fixing this should be a good way to improve performance. :-) Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Mon Nov 24 06:04:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 06:04:53 2003 Subject: [ python-Bugs-847845 ] struct.calcsize mismatch Message-ID: Bugs item #847845, was opened at 2003-11-23 21:46 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847845&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Marc Schraffenberger (schraf) Assigned to: Nobody/Anonymous (nobody) Summary: struct.calcsize mismatch Initial Comment: Python 2.3 (#2, Sep 2 2003, 14:46:01) [GCC 3.1] on linux2 Python 2.3.2 (#1, Nov 21 2003, 10:31:27) [GCC 3.2.2] on irix6 I was using the struct.calcsize function to get the size of a byte and a long, although I was getting mismatch errors when running the code. I found that calcsize was giving different results when changing the order of the format. example: struct.calcsize('BL') -> 8 struct.calcsize('LB') -> 5 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-24 11:04 Message: Logged In: YES user_id=6656 One word: "padding". I suggest you read the struct module documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847845&group_id=5470 From noreply at sourceforge.net Mon Nov 24 14:36:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 14:37:16 2003 Subject: [ python-Bugs-847665 ] XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Message-ID: Bugs item #847665, was opened at 2003-11-24 02:21 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: XMLGenerator.startElementNS dies on EMPTY_NAMESPACE attribut Initial Comment: from xml.sax.saxutils import XMLGenerator g = XMLGenerator(encoding='utf8') STREAM_NAMESPACE = 'http://etherx.jabber.org/streams' CLIENT_NAMESPACE = 'jabber:client' g.startDocument() g.startPrefixMapping('stream', STREAM_NAMESPACE) g.startPrefixMapping('client', CLIENT_NAMESPACE) g.startElementNS( (STREAM_NAMESPACE, 'stream'), 'stream', {(None,'xmlns'): CLIENT_NAMESPACE} ) Dies with: Traceback (most recent call last): File "tst.py", line 11, in ? g.startElementNS( File "/System/Library/Frameworks/Python.framework/ Versions/2.3/lib/python2.3/xml/sax/saxutils.py", line 124, in startElementNS name = self._current_context[name[0]] + ":" + name[1] KeyError: 'x' Changing the end of XMLGenerator.startElementNS to the following makes it work the way I expect: for (name, value) in attrs.items(): if name[0] is None: name = name[1] else: name = self._current_context[name[0]] + ":" + name[1] self._out.write(' %s=%s' % (name, quoteattr(value))) self._out.write('>') ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-11-25 06:36 Message: Logged In: YES user_id=46639 This method also appears to have trouble emmitting tags without a namespace prefix: import xml.sax import xml.sax.handler import xml.sax.saxutils x = '''''' parser = xml.sax.make_parser() parser.setFeature(xml.sax.handler.feature_namespaces, True) parser.setContentHandler(xml.sax.saxutils.XMLGenerator()) parser.feed(x) dies with: Traceback (most recent call last): File "tst.py", line 30, in ? parser.feed(x) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 207, in feed self._parser.Parse(data, isFinal) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/expatreader.py", line 337, in start_element_ns AttributesNSImpl(newattrs, qnames)) File "/System/Library/Frameworks/Python.framework/Versions/ 2.3/lib/python2.3/xml/sax/saxutils.py", line 116, in startElementNS name = self._current_context[name[0]] + ":" + name[1] TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' I've attached my current replacement startElementNS method which appears to fix both this and the previous issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847665&group_id=5470 From noreply at sourceforge.net Mon Nov 24 14:53:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 14:53:37 2003 Subject: [ python-Bugs-847346 ] textwrap ignoring fix_sentence_endings for single lines Message-ID: Bugs item #847346, was opened at 2003-11-22 14:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847346&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tom Lynn (tlynn) >Assigned to: Greg Ward (gward) Summary: textwrap ignoring fix_sentence_endings for single lines Initial Comment: >>> import textwrap >>> t=textwrap. TextWrapper(fix_sentence_endings=True) >>> print t.fill("A short line. Note the single space.") A short line. Note the single space. TextWrapper.wrap() is implemented as: def wrap(self, text): text = self._munge_whitespace(text) indent = self.initial_indent # *** Next line seems to be the bug *** if len(text) + len(indent) <= self.width: return [indent + text] chunks = self._split(text) if self.fix_sentence_endings: self._fix_sentence_endings(chunks) return self._wrap_chunks(chunks) (if sf breaks the indentation, check the actual source!) That early-return "if" clause seems to be an incorrect optimisation which skips fix_sentence_endings. Commenting it out seems to fix the problem. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-24 14:53 Message: Logged In: YES user_id=33168 Greg, any comments? You implemented textwrap IIRC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847346&group_id=5470 From noreply at sourceforge.net Mon Nov 24 15:01:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 15:01:46 2003 Subject: [ python-Bugs-848556 ] 4.2.6 (re) Examples: float regexp exponential on failure Message-ID: Bugs item #848556, was opened at 2003-11-24 21: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=848556&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lukasz Pankowski (lupan) Assigned to: Nobody/Anonymous (nobody) Summary: 4.2.6 (re) Examples: float regexp exponential on failure Initial Comment: When using given regexp for floats [-+]?(\d+(\.\d*)?|\d*\.\d+)([eE][-+]?\d+)? '0.5' will match both alternatives on failure, which makes exponential number of matches on failure if matching multiple float numbers '0.5 0.5 0.5' using one regexp which fail at the end (attached test script). If replaced with slightly less verbose (without '\d*' after '|'): [-+]?(\d+(\.\d*)?|\.\d+)([eE][-+]?\d+)? '0.5' fails on the second branch and the exponential effect does not occur. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848556&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:16:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:16:48 2003 Subject: [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-30 02:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:16 Message: Logged In: YES user_id=21627 1) Basically, you lose. If you don't want to build a module as a shared library, you can build it statically, through Modules/Setup. If you absolutely don't want to build a module at all, you edit setup.py, and modify disabled_module_list. If you don't want to edit disabled_module_list, you build the module, and delete it when done. 2) Using /usr/local/lib could be replaced, but I would consider this out of scope of this change. Feel free to submit a separate patch. Make sure that the alternative patch manages to pick up shared libraries in all cases where it finds them today. 3) 'cvs annotate' reveals that this was added in setup.py 1.100. 'cvs log' reveals that this was added in response to python.org/sf/589427, where the Debian maintainer complains that /usr/include is added to the list of -I options, even though the compiler already has /usr/include in its search list. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-11-23 21:44 Message: Logged In: YES user_id=876734 I'm running into issues trying to come up with a clean version of this. I'd like to know what you think of some of these before I try to port what I've got into 2.4 and come up with patches. 1) setup.py seems to have no way to be selective about which modules to build. What if I don't want to try (and then fail make install) to build, for example, ssl? 2) setup.py makes assumptions about pathnames. It always puts /usr/local/lib into the build path. On a 64-bit solaris or HP system, this can lead to a mess, if the 64 bit libraries are somewhere else. 3) There is an existing provision to add additional libs to the build in setup.py, but it's disabled if the prefix is /usr. Why? I have this feeling that someone had a plan here that I'm too obtuse to make out which would offer a shorter path to a solution then I'm getting tangled up in, for managing the build of these modules. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 14:42 Message: Logged In: YES user_id=21627 You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-31 13:22 Message: Logged In: YES user_id=876734 To turn my patches into things that anyone else would want, I need to know what to put in the -L that will be required. At the time we're building the main python distro, that's straightforward. When a user builds an individual module, is there a sensible path relative to PYTHONHOME I can use? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 11:05 Message: Logged In: YES user_id=21627 Please do provide patches. Take into account that modules may be built either with distutils, or through Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:18:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:18:23 2003 Subject: [ python-Bugs-847812 ] 64 bit solaris versus /usr/local/lib Message-ID: Bugs item #847812, was opened at 2003-11-23 21:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847812&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: 64 bit solaris versus /usr/local/lib Initial Comment: setup.py sticks /usr/local/lib in to the link path when building modules. On a 64-bit solaris machine, the libraries in there may well be 32-bit, and not work. There needs to be some provision to control this, I think. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:18 Message: Logged In: YES user_id=21627 What kind of control are you thinking of? You *do* have control over this at the moment: You can edit Modules/Setup, and guide the build process explicitly what modules to pick up from what location. Some installations may have a /usr/local full of 64-bit stuff, so I don't see a problem in this default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847812&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:21:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:21:32 2003 Subject: [ python-Bugs-848614 ] distutils can't build extensions with VC 6 Message-ID: Bugs item #848614, was opened at 2003-11-24 22: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=848614&group_id=5470 Category: Distutils Group: Python 2.2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: distutils can't build extensions with VC 6 Initial Comment: When trying to build Zope 3 on windows with Python 2.3.2, I got: C:\Documents and Settings\jim\Desktop\Zope3>\python23\python setup.py build_ext -i running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. But I have version 6 if Visual Studio installed. I tried this on two different machines and even tried reinstalling Visual Studio. Finally, I tried copying distutils from Python 2.2. Happily, that allowed me to compile Zope 3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:21:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:21:55 2003 Subject: [ python-Bugs-846133 ] os.chmod does not work with a unicode filename Message-ID: Bugs item #846133, was opened at 2003-11-20 22:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: M.-A. Lemburg (lemburg) Summary: os.chmod does not work with a unicode filename Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:21 Message: Logged In: YES user_id=21627 If you look at the source of os.chmod, it is not at all surprising that it does not work for characters outside the file system encoding: it is simply not implemented. Patches are welcome. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 01:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-21 17:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 01:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:28:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:28:35 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 14:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 Category: Python Interpreter Core >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:28 Message: Logged In: YES user_id=21627 This is clearly not a bug. I'm closing it as "works for me": the "and" operator does *not* evaluate its argument twice (as Tim explains, and in contrast to what the subject claims). That the semantics of the if statement (*not* the "and" expression) is surprising if the result of __nonzero__ changes in subsequent invokcations might be a fact (strictly speaking, whether you are surprised depends on what you expect). However, the behaviour of Python is not at all random in itself, and there are very good reasons for things being just the way they are. If changing zero-ness of objects surprises you: Don't do that, then. ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 09:41 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 09:40 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-21 20:29 Message: Logged In: YES user_id=31435 Don't panic . "and" doesn't evaluate anything twice. The subtlety here is that "and" and "or" return one of their arguments. If x evaluates to false in "x and y", then "x and y" returns x: >>> class C: ... def __nonzero__(self): return False ... >>> x, y = C(), C() >>> (x and y) is x True >>> (x or y) is y True >>> The second evaluation occurs because "if expr:" has to evaluate expr. That part's got nothing to do with "and", it's entirely to do with "if". None of this is going to change, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-21 20:07 Message: Logged In: YES user_id=33168 Ouch! This happens in 2.2 and CVS (I assume 2.3 too). I'll look into this. Fixing this should be a good way to improve performance. :-) Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:31:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:31:24 2003 Subject: [ python-Bugs-846521 ] error in python's grammar Message-ID: Bugs item #846521, was opened at 2003-11-21 12:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: error in python's grammar Initial Comment: Python sometimes prints messages like 'expecting a , got a ' This is not English. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:31 Message: Logged In: YES user_id=21627 I'm willing to declare that this is not a bug. The messages are not intended to be correct English - they notoriously lack a full stop, and don't start with a capital letter after the colon. Many messages a verb missing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-21 13:50 Message: Logged In: YES user_id=6656 Speaking just for myself, I find it pretty hard to care. Are you interested in working on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:34:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:34:48 2003 Subject: [ python-Bugs-846564 ] "and" operator tests the first argument twice Message-ID: Bugs item #846564, was opened at 2003-11-21 08:08 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 Category: Python Interpreter Core Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: "and" operator tests the first argument twice Initial Comment: When the first operand of "and" results in False, its truth value is calculated again. Example: class myBool: def __init__(self,value): self.value = value def __nonzero__(self): print 'testing myBool(%s)' % self.value return bool(self.value) if myBool(0) and myBool(1): pass will print: testing myBool(0) testing myBool(0) The same thing occurs with the "or" operator, when the first argument has a True truth value: if myBool(2) and myBool(3): pass will print: testing myBool(2) testing myBool(2) This can be a problem when the "__nonzero__" function is slow or has side-effects. I agree this is not often the case... But imagine an object which truth value means "there are more data to read in a stream". If python evaluates __nonzero__ twice, the expression: "stream and otherTest()" can become True *without* evaluating the otherTest! ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-24 17:34 Message: Logged In: YES user_id=31435 Just noting that someone who creates objects with insanely surprising __nonzero__ behavior can easily avoid the "double evaluation" by coding if bool(x) and bool(y): instead. I agree with Martin that there's no bug here, so agree with his closing the bug report. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 17:28 Message: Logged In: YES user_id=21627 This is clearly not a bug. I'm closing it as "works for me": the "and" operator does *not* evaluate its argument twice (as Tim explains, and in contrast to what the subject claims). That the semantics of the if statement (*not* the "and" expression) is surprising if the result of __nonzero__ changes in subsequent invokcations might be a fact (strictly speaking, whether you are surprised depends on what you expect). However, the behaviour of Python is not at all random in itself, and there are very good reasons for things being just the way they are. If changing zero-ness of objects surprises you: Don't do that, then. ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 03:41 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-11-24 03:40 Message: Logged In: YES user_id=389140 I don't mind the __nonzero__ be called twice, but the test can be totally wrong if the value truth changes: import random class C: def __nonzero__(self): return bool(random.randint(0,1)) if C() and False: print "Should we really allow this?" There are 25% chances for the condition to be true. I find this odd. OK, this kind of script is not likely to happen in real life. So I attached a script where the object is a kind of pipe; it is True if there are data in it. And while we only fill it with "1", we sometimes enter the block where a "2" is found! If this behaviour is expected, it should at least be clearly documented! This remind me the macros in C, where a "variable" can be evaluated several times, so we have to be aware of side- effects. I did not know that "if a and b" was such a macro... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-21 14:29 Message: Logged In: YES user_id=31435 Don't panic . "and" doesn't evaluate anything twice. The subtlety here is that "and" and "or" return one of their arguments. If x evaluates to false in "x and y", then "x and y" returns x: >>> class C: ... def __nonzero__(self): return False ... >>> x, y = C(), C() >>> (x and y) is x True >>> (x or y) is y True >>> The second evaluation occurs because "if expr:" has to evaluate expr. That part's got nothing to do with "and", it's entirely to do with "if". None of this is going to change, of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-11-21 14:07 Message: Logged In: YES user_id=33168 Ouch! This happens in 2.2 and CVS (I assume 2.3 too). I'll look into this. Fixing this should be a good way to improve performance. :-) Thanks for the report! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846564&group_id=5470 From noreply at sourceforge.net Mon Nov 24 17:45:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 17:48:22 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-06 20:52 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Raymond Hettinger (rhettinger) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-24 17:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 01:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 14:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 09:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 19:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 02:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 16:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 15:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 13:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 20:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 15:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Mon Nov 24 18:50:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 18:50:31 2003 Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more strict checking Message-ID: Bugs item #847019, was opened at 2003-11-21 21:19 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Michael Dubner (dubnerm) Assigned to: Guido van Rossum (gvanrossum) Summary: datetime.datetime initialization needs more strict checking Initial Comment: Friend of mine wrote following program: --------------------------------- import datetime t=datetime.datetime('1995-03-25') print t.ctime() --------------------------------- This is obviously wrong code, but instead of reporting this at second line python crashes on third line (with ctime). Info: Using Python 2.3.2 on Windows 2000 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-11-24 18:50 Message: Logged In: YES user_id=31435 Na, it's not that simple. Blazing-fast pickling and unpickling was a design goal for datetime. "Sanity checks" require two- tailed comparisons on 7 distinct fields, and checking of the day field requires month-specific comparison, and may even require determing whether it's a leap year. Doing all that would make sucking datetimes out of pickles enormously slower than it is now (it's merely a 10-byte string copy now). If we were willing to do all the checks we do on things coming through the front door, we wouldn't call it a back door . OTOH, we shouldn't allow a hostile user the ability to crash the system via constructing a damaged datetime pickle either, so maybe the whole "fast back door" idea is impossible to rehabilitate. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-11-23 20:36 Message: Logged In: YES user_id=39274 Of cause i've seen that backdoor, but from my point of view constructor is not so time-critical that insertion of sanity chechs will slow down in most (sane) scenarios. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-21 22:16 Message: Logged In: YES user_id=31435 LOL! Assigned to Guido for his amusement. One string argument of exactly size 10 triggers the "secret" backdoor to construct a datetime.datetime from a pickle. The datetime constructed here is insane, and provokes Microsoft's library into crashing. In a debug build, it triggers an assertion error in the datetime module: >>> import datetime [16122 refs] >>> datetime.datetime('1995-03-25') datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973) [16124 refs] >>> _.ctime() Assertion failed: month <= 12, file C:\Code\python\Modules\datetimemodule.c, line 189 Boosted priority since it's a way to crash the interpreter on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 From noreply at sourceforge.net Mon Nov 24 20:17:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Nov 24 20:17:42 2003 Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more strict checking Message-ID: Bugs item #847019, was opened at 2003-11-22 05:19 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Michael Dubner (dubnerm) Assigned to: Guido van Rossum (gvanrossum) Summary: datetime.datetime initialization needs more strict checking Initial Comment: Friend of mine wrote following program: --------------------------------- import datetime t=datetime.datetime('1995-03-25') print t.ctime() --------------------------------- This is obviously wrong code, but instead of reporting this at second line python crashes on third line (with ctime). Info: Using Python 2.3.2 on Windows 2000 ---------------------------------------------------------------------- >Comment By: Michael Dubner (dubnerm) Date: 2003-11-25 04:17 Message: Logged In: YES user_id=39274 Can we add dummy fields to change size of backdoor string so it will not be same as commonly used formats? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-25 02:50 Message: Logged In: YES user_id=31435 Na, it's not that simple. Blazing-fast pickling and unpickling was a design goal for datetime. "Sanity checks" require two- tailed comparisons on 7 distinct fields, and checking of the day field requires month-specific comparison, and may even require determing whether it's a leap year. Doing all that would make sucking datetimes out of pickles enormously slower than it is now (it's merely a 10-byte string copy now). If we were willing to do all the checks we do on things coming through the front door, we wouldn't call it a back door . OTOH, we shouldn't allow a hostile user the ability to crash the system via constructing a damaged datetime pickle either, so maybe the whole "fast back door" idea is impossible to rehabilitate. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-11-24 04:36 Message: Logged In: YES user_id=39274 Of cause i've seen that backdoor, but from my point of view constructor is not so time-critical that insertion of sanity chechs will slow down in most (sane) scenarios. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-11-22 06:16 Message: Logged In: YES user_id=31435 LOL! Assigned to Guido for his amusement. One string argument of exactly size 10 triggers the "secret" backdoor to construct a datetime.datetime from a pickle. The datetime constructed here is insane, and provokes Microsoft's library into crashing. In a debug build, it triggers an assertion error in the datetime module: >>> import datetime [16122 refs] >>> datetime.datetime('1995-03-25') datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973) [16124 refs] >>> _.ctime() Assertion failed: month <= 12, file C:\Code\python\Modules\datetimemodule.c, line 189 Boosted priority since it's a way to crash the interpreter on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470 From noreply at sourceforge.net Tue Nov 25 02:51:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 02:51:49 2003 Subject: [ python-Bugs-848614 ] distutils can't build extensions with VC 6 Message-ID: Bugs item #848614, was opened at 2003-11-24 23:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 Category: Distutils Group: Python 2.2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: distutils can't build extensions with VC 6 Initial Comment: When trying to build Zope 3 on windows with Python 2.3.2, I got: C:\Documents and Settings\jim\Desktop\Zope3>\python23\python setup.py build_ext -i running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. But I have version 6 if Visual Studio installed. I tried this on two different machines and even tried reinstalling Visual Studio. Finally, I tried copying distutils from Python 2.2. Happily, that allowed me to compile Zope 3. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-25 08:51 Message: Logged In: YES user_id=11105 Seems this is a common mistake: you have to start the MSVC6 gui *at least once*, otherwise the needed registry entries are not created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 From noreply at sourceforge.net Mon Nov 24 21:22:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 03:02:16 2003 Subject: [ python-Bugs-847812 ] 64 bit solaris versus /usr/local/lib Message-ID: Bugs item #847812, was opened at 2003-11-23 15:25 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847812&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: 64 bit solaris versus /usr/local/lib Initial Comment: setup.py sticks /usr/local/lib in to the link path when building modules. On a 64-bit solaris machine, the libraries in there may well be 32-bit, and not work. There needs to be some provision to control this, I think. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-11-24 21:22 Message: Logged In: YES user_id=876734 I knew there was something fundamental I was missing. However, my copy of setup.py, which is not automatically generated, has /usr/local in it too, in 'detect_modules'. Or do those paths end up somewhere else. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 17:18 Message: Logged In: YES user_id=21627 What kind of control are you thinking of? You *do* have control over this at the moment: You can edit Modules/Setup, and guide the build process explicitly what modules to pick up from what location. Some installations may have a /usr/local full of 64-bit stuff, so I don't see a problem in this default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847812&group_id=5470 From noreply at sourceforge.net Tue Nov 25 03:13:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 03:13:52 2003 Subject: [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific addressing Message-ID: Bugs item #764437, was opened at 2003-07-02 17:13 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Paul Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: AF_UNIX sockets do not handle Linux-specific addressing Initial Comment: As described in unix(7) manpage, Linux allows for special "kernel namespace" AF_UNIX sockets defined. With such sockets, the first byte of the path is \x00, and the rest is the address. These sockets do not show up in the filesystem. socketmodule.c:makesockaddr (as called by recvfrom) uses code like PyString_FromString(a->sun_path) to retrieve the address. This is incorrect -- on Linux, if the first byte of a->sun_path is null, the function should use PyString_FromStringAndSize to retrieve the full 108- byte buffer. I am not entirely sure that this is the only thing that needs to be fixed, but bind() and sendto() work with these sort of socket paths just fine. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-11-25 19:13 Message: Logged In: YES user_id=29957 Eek. What a totally mental design decision on the part of the Linux kernel developers. Is there a magic C preprocessor symbol we can use to detect that this insanity is available? (FWIW, Perl also has problems with this: http://www.alexhudson.com/code/abstract-sockets-and-perl ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 From noreply at sourceforge.net Mon Nov 24 21:25:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:02:44 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-06 19:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Raymond Hettinger (rhettinger) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-24 21:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-24 17:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 00:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 13:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 08:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 18:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 01:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 15:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 14:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 14:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 12:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-07 19:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 14:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:12:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:12:38 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 11: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=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Raymond Hettinger (rhettinger) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:38:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:38:21 2003 Subject: [ python-Bugs-848871 ] Windows installer halts Message-ID: Bugs item #848871, was opened at 2003-11-25 12: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=848871&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jens Olsson (morr) Assigned to: Thomas Heller (theller) Summary: Windows installer halts Initial Comment: The Windows installer halts when starting to install files, more exactly when installing the file "UNWISE.EXE" and the progress bar reads "1%". Python versions tested: 2.2.3 2.3.1 2.3.2 2.3.2-1 All tested versions behave the same. Since I don't believe it's a common bug I attach selected computer specs for the system in question. I find it hard to believe it is the python windows installer by itself that contains the bug but since I haven't experienced this with any other installer I submit the bug anyway. It can't be my system by itself either. - Varying the installation options does not seem to help (non exhaustive testing done). - Running install on on specific processor (Hyper Threading is enabled) does not change things Test system summary (see attachment for full specs): Gigabyte 8KNXP motherboard, intel Northwood 3.0GHz HT, 2x512MB Corsair 3500, Radeon 9700 AIW, Seagate Barracuda 160GB, Windows XP Pro SP1a. Reproduction steps: 1. Launch installer 2. Click 'next' when asked for directory 3. Click 'next' when asked about backups 4. Click 'next' when asked for component selection 5. Click 'next' when asked for start menu group selection 6. Click 'next' when prompted with the "ready to install" screen 7. Observere bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848871&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:38:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 06:38:31 2003 Subject: [ python-Bugs-848614 ] distutils can't build extensions with VC 6 Message-ID: Bugs item #848614, was opened at 2003-11-24 23:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 Category: Distutils Group: Python 2.2.3 Status: Open Resolution: None Priority: 6 Submitted By: Jim Fulton (dcjim) Assigned to: Nobody/Anonymous (nobody) Summary: distutils can't build extensions with VC 6 Initial Comment: When trying to build Zope 3 on windows with Python 2.3.2, I got: C:\Documents and Settings\jim\Desktop\Zope3>\python23\python setup.py build_ext -i running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. But I have version 6 if Visual Studio installed. I tried this on two different machines and even tried reinstalling Visual Studio. Finally, I tried copying distutils from Python 2.2. Happily, that allowed me to compile Zope 3. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-25 12:38 Message: Logged In: YES user_id=11105 I've attached a patch which tries to find out whether MSVC6 is installed if the registry entries are not found. If so, a warnning is printed in addition to the error mentioned above: It seems you have Visual Studio 6 installed, but the expected registry settings are not present. You must at least run the Visual Studio GUI once so that these entries are created. I do not know if DevStudio 7 has the same problem or not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-25 08:51 Message: Logged In: YES user_id=11105 Seems this is a common mistake: you have to start the MSVC6 gui *at least once*, otherwise the needed registry entries are not created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 From noreply at sourceforge.net Tue Nov 25 04:50:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 07:02:48 2003 Subject: [ python-Bugs-848812 ] Inconsistent list.__add__/__addi__. Message-ID: Bugs item #848812, was opened at 2003-11-25 04: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=848812&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent list.__add__/__addi__. Initial Comment: >>> L = [1,2,3] >>> L + (1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: can only concatenate list (not "tuple") to list >>> L += (1,2,3) >>> L [1, 2, 3, 1, 2, 3] I've always been somewhat annoyed that list.__add__ didn't accept any iterable (just lists), but to have += accept any iterable but not + is just plain inconsistent. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 From noreply at sourceforge.net Tue Nov 25 06:13:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 07:03:03 2003 Subject: [ python-Bugs-846521 ] error in python's grammar Message-ID: Bugs item #846521, was opened at 2003-11-21 11:36 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 4 Submitted By: Keith Briggs (kbriggs) >Assigned to: Michael Hudson (mwh) Summary: error in python's grammar Initial Comment: Python sometimes prints messages like 'expecting a , got a ' This is not English. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-25 11:13 Message: Logged In: YES user_id=6656 Lets close it then. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 22:31 Message: Logged In: YES user_id=21627 I'm willing to declare that this is not a bug. The messages are not intended to be correct English - they notoriously lack a full stop, and don't start with a capital letter after the colon. Many messages a verb missing. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-21 12:50 Message: Logged In: YES user_id=6656 Speaking just for myself, I find it pretty hard to care. Are you interested in working on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846521&group_id=5470 From noreply at sourceforge.net Tue Nov 25 07:50:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 07:50:25 2003 Subject: [ python-Bugs-848907 ] pydoc crash on MacOS X Message-ID: Bugs item #848907, was opened at 2003-11-25 13: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=848907&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc crash on MacOS X Initial Comment: pydoc will crash the python interpreter on MacOS X if an extension module defines an Objective-C class or category. The attached tarball contains an example of this, if you build the extension module and then run dotest.py the interpreter will crash. The cause for this is the call to 'imp.load_module' in pydoc.py. This will load the extension module with __temp__ as it's name. load_module will load the executable image, search for the init__temp__ function and will then try to unload the image because that function is not found. Unloading the image (using NSUnloadModule, see dynload_next.c) will cause the crash because it is impossible to unload executable images that contain an Objective-C class or category. A real world example: install PyObjC and run 'pydoc -k hello'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470 From noreply at sourceforge.net Tue Nov 25 07:51:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 07:51:57 2003 Subject: [ python-Bugs-848907 ] pydoc crash on MacOS X Message-ID: Bugs item #848907, was opened at 2003-11-25 13:50 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470 >Category: Macintosh >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Jack Jansen (jackjansen) Summary: pydoc crash on MacOS X Initial Comment: pydoc will crash the python interpreter on MacOS X if an extension module defines an Objective-C class or category. The attached tarball contains an example of this, if you build the extension module and then run dotest.py the interpreter will crash. The cause for this is the call to 'imp.load_module' in pydoc.py. This will load the extension module with __temp__ as it's name. load_module will load the executable image, search for the init__temp__ function and will then try to unload the image because that function is not found. Unloading the image (using NSUnloadModule, see dynload_next.c) will cause the crash because it is impossible to unload executable images that contain an Objective-C class or category. A real world example: install PyObjC and run 'pydoc -k hello'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470 From noreply at sourceforge.net Tue Nov 25 07:55:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 07:55:28 2003 Subject: [ python-Feature Requests-848910 ] Enable crosscompilation Message-ID: Feature Requests item #848910, was opened at 2003-11-25 13:55 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=848910&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: J?rg Hoh (hohjg) Assigned to: Nobody/Anonymous (nobody) Summary: Enable crosscompilation Initial Comment: Python is awful to crosscompile. I've done it with the help of that site ( http://www.ailis.de/~k/knowledge/crosscompiling/python.php), but I still had to patch the setup.py myself. The wish: Could you avoid to add the standard include path (usually /usr/include) to the include paths (in setup.py)? It confuses my crosscompiler (for which /usr/include isn't applicable, because it produces code for a different plattform and endianess), because the includes given by commandline to the gcc are searched before the standard include paths. And if there are files with the wished names, it will produce lots of errors and warnings. The second one (a more longterm wish) Could you split the build process into 2 parts? A part which is plattform independet (the (cross-) compilation of the python-binary and all required binary libraries), and a plattform specific one, which is then running on the target plattform. This would help me and other people crosscompiling python for more plattforms and embedded systems, which haven't an available native compiler (or the plattform isn't suppossed to run a compiler because of its limited ressouces). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=848910&group_id=5470 From noreply at sourceforge.net Tue Nov 25 09:06:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 09:06:31 2003 Subject: [ python-Bugs-848907 ] pydoc crash on MacOS X Message-ID: Bugs item #848907, was opened at 2003-11-25 13:50 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Jack Jansen (jackjansen) Summary: pydoc crash on MacOS X Initial Comment: pydoc will crash the python interpreter on MacOS X if an extension module defines an Objective-C class or category. The attached tarball contains an example of this, if you build the extension module and then run dotest.py the interpreter will crash. The cause for this is the call to 'imp.load_module' in pydoc.py. This will load the extension module with __temp__ as it's name. load_module will load the executable image, search for the init__temp__ function and will then try to unload the image because that function is not found. Unloading the image (using NSUnloadModule, see dynload_next.c) will cause the crash because it is impossible to unload executable images that contain an Objective-C class or category. A real world example: install PyObjC and run 'pydoc -k hello'. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-25 15:06 Message: Logged In: YES user_id=45365 This is a duplicate of , but I'm leaving it in for the moment as it has a real-life example of when modules are unloaded. Ronald: could you you see whether you agree with my suggestions over there that PyObjC modules should solve this themselves (as opposed to disabling unloading in general)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848907&group_id=5470 From noreply at sourceforge.net Tue Nov 25 09:18:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 09:19:29 2003 Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 21:44 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 15:18 Message: Logged In: YES user_id=580910 Note that the problem doesn't really have anything to do with unloading modules, the problem occurs when trying to unload a dylib that doesn't contain the proper init function. See bug #848907 (sorry about that one, I didn't look for earlier bug reports). What happens: - pydoc calls imp.load_module('__temp__', open('_objc.so'), ...) - load_module loads _objc.so - load_module tries to find init__temp__ in _objc.so - nothing is found and therefore load_module calls NSUnlinkModule - NSUnlinkModule aborts the process because _objc.so contains Objective-C definitions No code in the extension module has any change to fix things because the init function is never called. BTW. The problem also exists in a vanilla Python 2.3 installation on Panther, I cleared /Library/Python2.3 and ran 'pydoc -k hello' and this also crashed. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-14 11:40 Message: Logged In: YES user_id=45365 I think that either the module itself, or the package responsible for the module, should forestall unloading (by tucking away an extra reference somewhere). The root of the problem is that the Python refcount doesn't reflect the all references to the module: ObjC keeps references too. OTOH: if all modules containing ObjC code have this problem, and it is easy to detect whether a module contains ObjC code then adding a safety net to the import code might be a prudent course of action. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 16:16 Message: Logged In: YES user_id=45365 I'm surprised that it does the unload:-) I think the correct solution would be for the module itself (or someone close to it) to stash away a reference. As this is only a problem for some modules (those containing ObjC code) I don't think a general change is in order. The real problem is that the "last reference" as Python sees it isn't really the last reference: the ObjC runtime also has references to stuff in there. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-11 15:20 Message: Logged In: YES user_id=139309 it does if you del sys.modules['somemodule'] and somemodule's reference count goes to zero. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 11:51 Message: Logged In: YES user_id=45365 Bob, I'm confused. As far as I know Python never unloads extension modules... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Tue Nov 25 09:36:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 09:37:22 2003 Subject: [ python-Bugs-838140 ] Unloading extension modules not always safe Message-ID: Bugs item #838140, was opened at 2003-11-07 21:44 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Unloading extension modules not always safe Initial Comment: I will look into the solution for this, but the "for now" solution would be to never try and unlink bundles because they may contain ObjC code. For several reasons, ObjC classes can never be unloaded, so bundles containing ObjC code can also never be unloaded. This is more than a problem for just PyObjC, because any arbitrary module may contain some ObjC code. We need to detect this before running NSUnlinkModule. I'll try and put together a patch sometime soon if nobody else does, but for now see: http:// sourceforge.net/tracker/? func=detail&aid=832025&group_id=14534&atid=114534 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 15:36 Message: Logged In: YES user_id=580910 A quick workaround would be to let pydoc check the type of module it tries to load, it currently checks if the file is a binary module by checking "if info and 'b' in info[2]" (pydoc.py:171). If it would check if the filetype is not C_EXTENSION (3) the problem would not arise with pydoc (which probably accounts for >99% of the problematic load_module calls). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-11-25 15:18 Message: Logged In: YES user_id=580910 Note that the problem doesn't really have anything to do with unloading modules, the problem occurs when trying to unload a dylib that doesn't contain the proper init function. See bug #848907 (sorry about that one, I didn't look for earlier bug reports). What happens: - pydoc calls imp.load_module('__temp__', open('_objc.so'), ...) - load_module loads _objc.so - load_module tries to find init__temp__ in _objc.so - nothing is found and therefore load_module calls NSUnlinkModule - NSUnlinkModule aborts the process because _objc.so contains Objective-C definitions No code in the extension module has any change to fix things because the init function is never called. BTW. The problem also exists in a vanilla Python 2.3 installation on Panther, I cleared /Library/Python2.3 and ran 'pydoc -k hello' and this also crashed. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-14 11:40 Message: Logged In: YES user_id=45365 I think that either the module itself, or the package responsible for the module, should forestall unloading (by tucking away an extra reference somewhere). The root of the problem is that the Python refcount doesn't reflect the all references to the module: ObjC keeps references too. OTOH: if all modules containing ObjC code have this problem, and it is easy to detect whether a module contains ObjC code then adding a safety net to the import code might be a prudent course of action. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 16:16 Message: Logged In: YES user_id=45365 I'm surprised that it does the unload:-) I think the correct solution would be for the module itself (or someone close to it) to stash away a reference. As this is only a problem for some modules (those containing ObjC code) I don't think a general change is in order. The real problem is that the "last reference" as Python sees it isn't really the last reference: the ObjC runtime also has references to stuff in there. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-11 15:20 Message: Logged In: YES user_id=139309 it does if you del sys.modules['somemodule'] and somemodule's reference count goes to zero. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-11-11 11:51 Message: Logged In: YES user_id=45365 Bob, I'm confused. As far as I know Python never unloads extension modules... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838140&group_id=5470 From noreply at sourceforge.net Tue Nov 25 10:45:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 10:45:22 2003 Subject: [ python-Bugs-849046 ] gzip.GzipFile is slow Message-ID: Bugs item #849046, was opened at 2003-11-25 16: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=849046&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile is slow Initial Comment: gzip.GzipFile is significantly (an order of a magnitude) slower than using the gzip binary. I've been bitten by this several times, and have replaced "fd = gzip.open('somefile', 'r')" by "fd = os.popen('gzcat somefile', 'r')" on several occassions. Would a patch that implemented GzipFile in C have any change of being accepted? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849046&group_id=5470 From noreply at sourceforge.net Tue Nov 25 11:34:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 11:34:35 2003 Subject: [ python-Feature Requests-801847 ] Adding rsplit() to string and unicode objects. Message-ID: Feature Requests item #801847, was opened at 2003-09-07 00:52 Message generated for change (Comment added) made by jafo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 4 Submitted By: Sean Reifschneider (jafo) Assigned to: Raymond Hettinger (rhettinger) Summary: Adding rsplit() to string and unicode objects. Initial Comment: I'm attaching patches to the library and documentation for implementing rsplit() on string and unicode objects. This works like split(), but working from the right. ./python -c 'print u"foo, bar, baz".rsplit(None, 1)' [u'foo, bar,', u'baz'] This was supposed to be against the CVS code, but I've had a heck of a time getting it checked out -- my checkout has been hung for half an hour now. The code patch is against the 2.3 release, the docs patch is against the CVS. My checkout got to docs, but I didn't have the code to a point where I could build and test it. Sean ---------------------------------------------------------------------- >Comment By: Sean Reifschneider (jafo) Date: 2003-11-25 16:34 Message: Logged In: YES user_id=81797 Raymond, you've asked Guido about it on September 11, and he (apparently) explicitly stayed out of the discussion. I assumed that you had let him know you wanted his judgement on this and that his response was that he didn't want to be involved, leaving it up to the library "elite guard" instead. Did you actually copy Guido on your earlier request? Personally, I don't see the logic in "if we get only one string method". Python isn't for the Python core developers, it's for the users. If the users have several things that they want added, why the artificial limit on how many to accept? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-25 02:25 Message: Logged In: YES user_id=80475 Get Guido to approve the API change and I will be happy to complete the implementation, documentation, testing, etc. Advice: He will want *compelling* non-toy use cases and reasons why that a person wouldn't just implement it in pure python (saying that they aren't smart enough is not a reason). He is rarely ever persuaded by symmetry/completeness arguments along the lines of "we have an l-this so we have to have an r-that". If that were the case, tuples would have gotten index() and count() long ago. Language growth rate is one issue, the total number of string methods is another, and more importantly he seeks to minimize the number of small API compatabilities between versions which make it difficult to write code for Py2.4 that runs on Py2.2. Also, there are a number of strong competitors vying to be added as string methods. If we only get one new method, why is this one to be preferred over str.cook() for supporting Barry's simplified string substitutions Given only one new str API change, I would personally prefer to add an optional fillchar argument to str.center(). ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-11-24 22:45 Message: Logged In: YES user_id=139309 I'd have to say me too on this one, wake up please :) ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-29 05:38 Message: Logged In: YES user_id=81797 This seems to have generated nothing but positive comment from the folks on python-dev. Thoughts? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-22 18:17 Message: Logged In: YES user_id=80475 I'll review your patch when I get a chance. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-22 13:10 Message: Logged In: YES user_id=99508 As a comment on the ease with which a programmer can get rsplit wrong, note that rhettinger's rsplit implementation is not correct: compare rsplit('foobarbaz', 'bar') with 'foobarbaz'.split('bar'). He forgot to reverse the separator if it's not None. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-11 23:55 Message: Logged In: YES user_id=80475 Guido, do you care to pronounce on this one? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-11 06:07 Message: Logged In: YES user_id=21627 There is PEP 2, which suggests to write a library PEP for proposal to extend the library. Now, this probably would be overkill for a single string method. However, I feel that there are already too many string methods, so I won't accept that patch. I'm not rejecting it, either, because I see that other maintainers might have a different opinion. In short, you should propose your change to python-dev, finding out what "a majority" of the maintainers thinks; you might also propose it on python-list, trying to collect reactions from users. It would then be good to summarize these discussions here (instead of carrying them out here). ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 20:40 Message: Logged In: YES user_id=81797 I realize that rsplit() can be implemented, because, well, I implemented it. The standard library is there to provide ready-to-use functionality so that users of python can concentrate on their program instead of concentrate on re-inventing the wheel. find() can be implemented with a short loop, split() can be implemented with find(), join() can be implemented with a short loop. Many things can be implemented with a little additional effort on the part of the user to develop or locate the code they're wanting. These little things can add up quickly and can have quite a dramatic impact on the programming experience in Python. Having to find or implement these functions will cause distraction from the code at hand, time lost while finding, implementing, testing, and maintaining the code in question. One of Python's strengths is a rich standard library. So, what are the guidelines for determining when it's rich enough? Why is it ok to suggest that users should get distracted from their code to go implement something else? Is there a policy that I'm not aware of that new functionality should be put in the cookbook instead of the standard library? Why is it being ignored that some programmers would find implementing rsplit() challenging? I'm not trying to be difficult here, I honestly can't understand the apparent change from having a rich library to a "batteries not included" stance. The response I got from #python when I mentioned having submitted the patch indicates to me that other experienced Python developers expect there to be an rsplit(). So, why is there so much resistance to adding something to the library? What are the guidelines for determining if something should be in the library? Sean ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-10 19:35 Message: Logged In: YES user_id=80475 I would classify this more as a technique than a fundamental string operation implemented by all stringlike objects (including UserString). Accordingly, I recommend that the patch be closed and a recipe posted in the ASPN cookbook - something along the lines of: >>> def rsplit(s, sep=None, maxsplit=-1): ... return [chunk[::-1] for chunk in s[::-1].split(sep, maxsplit)[::-1]] >>> rsplit(u"foo, bar, baz", None, 1) [u'foo, bar,', u'baz'] ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-10 19:15 Message: Logged In: YES user_id=81797 os.path.basename/os.path.dirname is an example of where you could use rsplit. One of the other #python folks said he had recently wanted rsplit for an application where he was getting the domain name and user part from a list of e-mail addresses, but found that some entries contained an "@" in the user part. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-10 17:08 Message: Logged In: YES user_id=21627 I questioned the usefulness because I could not think of a meaningful application. Now I see what a potential application could be, but I doubt its generality, because that approach would break if there could be two fields that have commas in them. I also disagree that symmetry can motivate usefulness: I also doubt that all of the r* functions are useful, but they cannot be removed for backwards compatibility. The fact that rsplit would fit together with the other r* functions indicates that adding rsplit would provide symmetry, not that it would provide usefulness. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2003-09-08 00:56 Message: Logged In: YES user_id=81797 Can you provide more details about why the usefulness of this function is in question? First I would like to tell you the story of it coming to be, then I will answer your incomplete question with a (probably) incomplete answer. I had a device which sent me comma-separated fields, but one of the fields in the middle could contain a comma. The answer that seemed obvious to me was to use split with a maxsplit to get the fields up to that field, and then a rsplit with a maxsplit on the remainder. When I mentioned on #python that I was implementing rsplit, 4 other fellow python users replied right away that they had been wanting it. To answer your question, it's useful because people using strings are used to having r*() functions like rfind and rstrip. The lack of rsplit is kind of glaring in this context. Really, though, it's useful because otherwise people have to implement -- often badly. Sean ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-07 19:49 Message: Logged In: YES user_id=21627 Why is this function useful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=801847&group_id=5470 From noreply at sourceforge.net Tue Nov 25 11:47:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Nov 25 11:47:40 2003 Subject: [ python-Bugs-849097 ] Request: getpos() for sgmllib Message-ID: Bugs item #849097, was opened at 2003-11-25 17:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849097&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Wiklund (d98dzone) Assigned to: Nobody/Anonymous (nobody) Summary: Request: getpos() for sgmllib Initial Comment: During the process of making my masters thesis I discovered the need for a working getpos() in sgmllib.py. As it is now you can successfully call it since it is inherited from markupbase.py but you will always get the answer (1,0) since it is never updated. To fix this one needs to change the goahead function. This is my own implementation of this change, in part influenced by the "sister" goahead-function in HTLMParser.py: ************************************ def goahead(self, end): rawdata = self.rawdata i = 0 k = 0 n = len(rawdata) tmp=0 while i < n: if self.nomoretags: self.handle_data(rawdata[i:n]) i = n break match = interesting.search(rawdata, i) if match: j = match.start() else: j = n if i < j: self.handle_data(rawdata[i:j]) tmp = self.updatepos(i, j) i = j if i == n: break startswith = rawdata.startswith if rawdata[i] == '<': if starttagopen.match(rawdata, i): if self.literal: self.handle_data(rawdata[i]) tmp = self.updatepos(i, i+1) i = i+1 continue k = self.parse_starttag(i) if k < 0: break tmp = self.updatepos(i, k) i = k continue if rawdata.startswith(" (i + 1): self.handle_data("<") i = i+1 tmp = self.updatepos(i, k) else: # incomplete break continue if rawdata.startswith("<------------------------><------------ (gotti@gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve Bugs item #849662, was opened at 2003-11-26 14:06 Message generated for change (Comment added) made by ganssauge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849662&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Raymond Hettinger (rhettinger) Summary: reading shelves is really slow Initial Comment: My application uses a shelve-file which is created by another process using the same python version. Before python2.3 using this shelve with the exact same application was almost twice as fast as a binary pickle containing the same data. Now with python2.3 the same application is suddenly about 150 times slower than using the binary pickle. The usage is as follows: idx_dict = shelve.open (idx_dict_name, "r") ... while not infile.eof: index = get_index_from_somewhere_else() if not idx_dict.has_key (index): do_something(index) else: do_something_else(index) idx.dict.close() Profiling revealed that most of the time is spent within userdict. ---------------------------------------------------------------------- >Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 10:42 Message: Logged In: YES user_id=792746 What the heck ... here is the shelve in question ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 10:32 Message: Logged In: YES user_id=792746 I uploaded my profiling data, maybe it will help you ... Here is the information you requested: ----------------><------------------------><------------ (gotti@gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve Bugs item #850110, was opened at 2003-11-27 08:54 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) >Assigned to: Michael Hudson (mwh) Summary: Out of order commands excecution? Initial Comment: Consider the following: >>> import string >>> def test1(): join = string.join >>> def test2(): join = string.join string = string.split >>> test1() >>> test2() Traceback (most recent call last): File "", line 1, in -toplevel- test2() File "", line 2, in test2 join = string.join UnboundLocalError: local variable 'string' referenced before assignment >>> How the second statement in test2 generates an error in first one? Nadav. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-11-27 12:09 Message: Logged In: YES user_id=6656 Well, that's just how it works. This must be documented somewhere... see if http://www.python.org/doc/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python helps (and maybe the question before). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 From noreply at sourceforge.net Thu Nov 27 08:11:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 08:11:31 2003 Subject: [ python-Bugs-850238 ] unclear documentation/missing command? Message-ID: Bugs item #850238, was opened at 2003-11-27 14:11 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=850238&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Kostyrka (yacc143) Assigned to: Nobody/Anonymous (nobody) Summary: unclear documentation/missing command? Initial Comment: Hi! The documentation of \declaremodule (http://www.python.org/doc/2.3.2/doc/module-markup.html) misses one important thing: It only works as such if you use one \section per module. (I had some fun LaTeX debugging to find it) It should also be noted, that perhaps an extra command to call \py@reset, something like \endmodule, this way the author could specify which part of the file pertains to certain module. Alternativly, perhaps \declaremodule should flush out any module info that is already entered? Andreas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850238&group_id=5470 From noreply at sourceforge.net Thu Nov 27 12:55:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 12:55:17 2003 Subject: [ python-Bugs-849662 ] reading shelves is really slow Message-ID: Bugs item #849662, was opened at 2003-11-26 09:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849662&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Raymond Hettinger (rhettinger) Summary: reading shelves is really slow Initial Comment: My application uses a shelve-file which is created by another process using the same python version. Before python2.3 using this shelve with the exact same application was almost twice as fast as a binary pickle containing the same data. Now with python2.3 the same application is suddenly about 150 times slower than using the binary pickle. The usage is as follows: idx_dict = shelve.open (idx_dict_name, "r") ... while not infile.eof: index = get_index_from_somewhere_else() if not idx_dict.has_key (index): do_something(index) else: do_something_else(index) idx.dict.close() Profiling revealed that most of the time is spent within userdict. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-27 12:55 Message: Logged In: YES user_id=80475 The fragment in the original posting showed the only inner-loop shelve access was through has_key(). The tracebacks show that UserDict is nowhere in the traceback chain. I conclude that the fragment does not represent what is really going on in the problematic script. So, please attach the profiled script, Konvertierung/entsch_pass2.py The attached profile indicates that somewhere, there is a line like: for k,v in idx_dict.iteritems(). This is surprising because shelves did not support iteritems() in Py2.2. That would be mean that you've timed and compared two different pieces of code. Please show the shortest script with data that runs at radically different speeds on Py2.2 vs Py2.3. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 05:42 Message: Logged In: YES user_id=792746 What the heck ... here is the shelve in question ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 05:32 Message: Logged In: YES user_id=792746 I uploaded my profiling data, maybe it will help you ... Here is the information you requested: ----------------><------------------------><------------ (gotti@gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve Feature Requests item #850408, was opened at 2003-11-27 16:31 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=850408&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sebastian Bassi (sbassi) Assigned to: Nobody/Anonymous (nobody) Summary: Count in String with overlap support (code included) Initial Comment: Hello, The string.count function doesn't support overlapping string. Here is a new function I'd like to see included in Python, a string.overcount function that has overlapping support. This is useful for dna related work and I think it has another uses. The "standar" string.count work like this: >s=newstring('aaabbaa') >s.count("aa") 2 But the "REAL" result, should be 3, becuase there are 3 instances of "aa". So, to get the 2 as a result, you will use count, the get 3, you will have overcount (or whatever you want to call it). So here is my code: class newstring(str): def overcount(self,pattern): """Returns how many p on s, works for overlapping""" ocu=0 x=0 while 1: try: i=self.index(pattern,x) except ValueError: break ocu+=1 x=i+1 return ocu s=newstring('aaabbaa') print s.overcount('aa') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=850408&group_id=5470 From noreply at sourceforge.net Thu Nov 27 17:03:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 17:03:47 2003 Subject: [ python-Bugs-842116 ] PackMan database for panther misses devtools dep Message-ID: Bugs item #842116, was opened at 2003-11-14 14:58 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842116&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan database for panther misses devtools dep Initial Comment: On Panther the Python headers are part of the BSD SDK. The PackMan database currently only checks for the devtools core being installed, it should also check the BSD SDK, which include Python.h and the other include files. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-27 23:03 Message: Logged In: YES user_id=45365 Fixed in the database. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=842116&group_id=5470 From noreply at sourceforge.net Thu Nov 27 18:13:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 18:13:29 2003 Subject: [ python-Bugs-630818 ] Dialogs too tight on OSX Message-ID: Bugs item #630818, was opened at 2002-10-30 01:55 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630818&group_id=5470 Category: Macintosh Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alexandre Parenteau (aubonbeurre) Assigned to: Jack Jansen (jackjansen) Summary: Dialogs too tight on OSX Initial Comment: > Jack, > > A detail really : > > The 2.2.2. EditPythonPrefs dialog is a little bit too compact > on OSX. It > obliterates partly some of the radio buttons. Ah, yes, I continually forget to fix that! There's a lot of dialogs that have this problem. Could you post a bug report, please? -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-28 00:13 Message: Logged In: YES user_id=45365 And now I've forgotten this bug for so long that it isn't worth fixing anymore:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630818&group_id=5470 From noreply at sourceforge.net Thu Nov 27 18:21:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 18:22:10 2003 Subject: [ python-Bugs-844676 ] PackageManager: deselect show hidden: indexerror Message-ID: Bugs item #844676, was opened at 2003-11-18 21:36 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844676&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martina Oefelein (oefe) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager: deselect show hidden: indexerror Initial Comment: Select "Show hidden". Select the last package in the list Deselect "Show hidden": IndexError: list index out of range Traceback: File "Wapplication.py", line 45, in mainloop self.do1event(mask, wait) File "FrameWork.py", line 194, in do1event self.dispatch(event) File "FrameWork.py", line 227, in dispatch handler(event) File "FrameWork.py", line 289, in do_mouseDown handler(partcode, wid, event) File "FrameWork.py", line 836, in do_inContent self.do_contentclick(local, modifiers, event) File "Wwindows.py", line 336, in do_contentclick widget.click(point, modifiers) File "Wcontrols.py", line 241, in click Wbase.CallbackCall(self._callback, 0, self.get()) File "Wbase.py", line 684, in CallbackCall return callback() File "PackageManager.py", line 386, in updatestatus installed, message = self.getstatus(sel) File "PackageManager.py", line 316, in getstatus pkg = self.packages[number] Mac OS X 10.3.1, MacPython 2.3 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-28 00:21 Message: Logged In: YES user_id=45365 Fixed in PackageManager.py rev 1.14.4.3 (for 2.3.X) and rev 1.17 (for 2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=844676&group_id=5470 From noreply at sourceforge.net Thu Nov 27 18:29:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 18:29:50 2003 Subject: [ python-Bugs-838616 ] MacPython for Panther additions includes IDLE Message-ID: Bugs item #838616, was opened at 2003-11-09 00:45 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838616&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython for Panther additions includes IDLE Initial Comment: The second build of the MacPython for Panther additions includes the IDLE applet. But it doesn't work (because _tkinter and AquaTclTk aren't installed). This should be fixed in the next installer. Moreover, it would be nice if there was something in place to do a quick sanity check of installers (MANIFEST files with comparison to the previous installer?). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-11-28 00:29 Message: Logged In: YES user_id=45365 I've added a note on this problem to the Mac/OSX/Dist/README.txt file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=838616&group_id=5470 From noreply at sourceforge.net Thu Nov 27 18:47:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Nov 27 18:47:26 2003 Subject: [ python-Bugs-850496 ] os.utime does not accept unicode filenames Message-ID: Bugs item #850496, was opened at 2003-11-28 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850496&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.utime does not accept unicode filenames Initial Comment: Most file related functions on windows accept unicode filenames. os.utime does not. This prevent the shutil module from working with unicode filenames in some situations. A partial traceback from the SpamBayes project is below: File "out1.pyz/shutil", line 170, in move File "out1.pyz/shutil", line 83, in copy2 File "out1.pyz/shutil", line 58, in copystat UnicodeEncodeError: 'ascii' codec can't encode characters in position 26-35: ordinal not in range(128) The SpamBayes bug is at https://sourceforge.net/tracker/index.php?func=detail&aid=835435&group_id=61702&atid=498103 Attaching a patch, including a patch to the test case. Also nominating as 2.3 bugfix candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850496&group_id=5470 From noreply at sourceforge.net Fri Nov 28 01:44:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 01:45:06 2003 Subject: [ python-Bugs-850496 ] os.utime does not accept unicode filenames Message-ID: Bugs item #850496, was opened at 2003-11-28 10:47 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850496&group_id=5470 Category: Windows Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: os.utime does not accept unicode filenames Initial Comment: Most file related functions on windows accept unicode filenames. os.utime does not. This prevent the shutil module from working with unicode filenames in some situations. A partial traceback from the SpamBayes project is below: File "out1.pyz/shutil", line 170, in move File "out1.pyz/shutil", line 83, in copy2 File "out1.pyz/shutil", line 58, in copystat UnicodeEncodeError: 'ascii' codec can't encode characters in position 26-35: ordinal not in range(128) The SpamBayes bug is at https://sourceforge.net/tracker/index.php?func=detail&aid=835435&group_id=61702&atid=498103 Attaching a patch, including a patch to the test case. Also nominating as 2.3 bugfix candidate. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-11-28 17:44 Message: Logged In: YES user_id=14198 I'll roll this in with http://www.python.org/sf/846133 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850496&group_id=5470 From noreply at sourceforge.net Fri Nov 28 04:58:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 04:58:22 2003 Subject: [ python-Bugs-846133 ] os.chmod/os.utime/shutil do not work with unicode filenames Message-ID: Bugs item #846133, was opened at 2003-11-21 08:27 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) >Assigned to: Mark Hammond (mhammond) >Summary: os.chmod/os.utime/shutil do not work with unicode filenames Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-11-28 20:58 Message: Logged In: YES user_id=14198 I opened http://www.python.org/sf/846133 regarding os.utime, which I found via the "shutil" module, via SpamBayes, also on a Japanese system (see that bug for details), but then I saw this and decided to tackle them both. I rolled my fix for that in with a fix for chmod. I also hacked the test suite radically: * Creation of a test_support.TESTFN_UNICODE_UNENCODEABLE variable, which is a Unicode string that can *not* be encoded using the file system encoding. This will cause functions with 'encoding' support but without Unicode support (such as utime/chmod) to fail. * Made functions of all the test cases, so more combinations of unicode/encoded can be tested. Many are redundant, but that is OK. * Added shutil tests of the filenames * While I was there, converted to a unittest test. The new test case blows up with a couple of errors before the posixmodule patch is applied, and passes after. Note that shutil.move/copy etc can not handle being passed one string and one unicode arg, and therefore this combination is skipped. I'd like any opinions on whether this is a bug in shutil or not. Also note that the new comment in test_support.py regarding a potential bug in the 'mbcs' encoding - it appears as if it always works as though errors=ignore. Comments/reviews? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-25 09:21 Message: Logged In: YES user_id=21627 If you look at the source of os.chmod, it is not at all surprising that it does not work for characters outside the file system encoding: it is simply not implemented. Patches are welcome. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 11:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-22 03:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 11:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Fri Nov 28 11:01:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 11:01:33 2003 Subject: [ python-Bugs-849662 ] reading shelves is really slow Message-ID: Bugs item #849662, was opened at 2003-11-26 14:06 Message generated for change (Comment added) made by ganssauge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849662&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Raymond Hettinger (rhettinger) Summary: reading shelves is really slow Initial Comment: My application uses a shelve-file which is created by another process using the same python version. Before python2.3 using this shelve with the exact same application was almost twice as fast as a binary pickle containing the same data. Now with python2.3 the same application is suddenly about 150 times slower than using the binary pickle. The usage is as follows: idx_dict = shelve.open (idx_dict_name, "r") ... while not infile.eof: index = get_index_from_somewhere_else() if not idx_dict.has_key (index): do_something(index) else: do_something_else(index) idx.dict.close() Profiling revealed that most of the time is spent within userdict. ---------------------------------------------------------------------- >Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-28 16:01 Message: Logged In: YES user_id=792746 I think I found the answer: apart from has_key() I'm using "dict != None". If I leave that out in my test program both python variants run with the same speed. The dict != None condition seems to trigger len(dict.keys()) and that seems to be way slower than before. I definitely didn't time different scripts: the script is part of our CDROM production system and the only variables I had during my tests were python itself and the python path. Find my test script attached... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-27 17:55 Message: Logged In: YES user_id=80475 The fragment in the original posting showed the only inner-loop shelve access was through has_key(). The tracebacks show that UserDict is nowhere in the traceback chain. I conclude that the fragment does not represent what is really going on in the problematic script. So, please attach the profiled script, Konvertierung/entsch_pass2.py The attached profile indicates that somewhere, there is a line like: for k,v in idx_dict.iteritems(). This is surprising because shelves did not support iteritems() in Py2.2. That would be mean that you've timed and compared two different pieces of code. Please show the shortest script with data that runs at radically different speeds on Py2.2 vs Py2.3. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 10:42 Message: Logged In: YES user_id=792746 What the heck ... here is the shelve in question ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 10:32 Message: Logged In: YES user_id=792746 I uploaded my profiling data, maybe it will help you ... Here is the information you requested: ----------------><------------------------><------------ (gotti@gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve Bugs item #850818, was opened at 2003-11-28 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=105470&aid=850818&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Popen3 description Initial Comment: In section 6.8.1 Popen3 and Popen4 Objects, of the current and development docs, under attribute 'childerr': """ Where the standard error from the child process goes is capturestderr was true for the constructor, or None. """ The 'is' should be 'if'. I think it might also be an improvement to replace 'or' with 'otherwise'. If a rewriting is acceptable, I think """ A file object that provides error output from the child process, if capturestderr was true for the constructor, otherwise None. """ improves uniformity with the descriptions of 'fromchild' and 'tochild'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850818&group_id=5470 From noreply at sourceforge.net Fri Nov 28 12:16:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 12:16:40 2003 Subject: [ python-Bugs-850823 ] Doc/README has broken link Message-ID: Bugs item #850823, was opened at 2003-11-28 12: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=850823&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: Doc/README has broken link Initial Comment: The README file in the docs directory has a URL for the development docs which is out of date. This is true in current (anonymous) CVS. http://python.sourceforge.net/devel-docs/ should be http://www.python.org/dev/doc/devel/ Also, perhaps a referral from the old page could be arranged instead of a 404. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850823&group_id=5470 From noreply at sourceforge.net Fri Nov 28 12:49:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 12:49:51 2003 Subject: [ python-Feature Requests-850408 ] Count in String with overlap support (code included) Message-ID: Feature Requests item #850408, was opened at 2003-11-27 14:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=850408&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Sebastian Bassi (sbassi) Assigned to: Nobody/Anonymous (nobody) Summary: Count in String with overlap support (code included) Initial Comment: Hello, The string.count function doesn't support overlapping string. Here is a new function I'd like to see included in Python, a string.overcount function that has overlapping support. This is useful for dna related work and I think it has another uses. The "standar" string.count work like this: >s=newstring('aaabbaa') >s.count("aa") 2 But the "REAL" result, should be 3, becuase there are 3 instances of "aa". So, to get the 2 as a result, you will use count, the get 3, you will have overcount (or whatever you want to call it). So here is my code: class newstring(str): def overcount(self,pattern): """Returns how many p on s, works for overlapping""" ocu=0 x=0 while 1: try: i=self.index(pattern,x) except ValueError: break ocu+=1 x=i+1 return ocu s=newstring('aaabbaa') print s.overcount('aa') ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 12:49 Message: Logged In: YES user_id=80475 Your pure python snippet is well done and may make a good ASPN recipe; however, I do not think it sufficiently unversal to warrant including it in C. I can think of no non-toy real world use cases for regular text. It seems most applicable to abstract character strings and even there counting overlapping sequences is not a common requirement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=850408&group_id=5470 From noreply at sourceforge.net Fri Nov 28 12:54:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 12:54:23 2003 Subject: [ python-Feature Requests-835521 ] More obvious indication of __reduce__ documentation. Message-ID: Feature Requests item #835521, was opened at 2003-11-04 01:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=835521&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: More obvious indication of __reduce__ documentation. Initial Comment: I just spent quite some time searching for documentation on the interface for __reduce__. Turns out, it's in the library documentation, 3.14.5.2, under the heading "Pickling and unpickling extension types." Perhaps that heading can be changed to more clearly indicate that "__reduce__ is documented here!" At least, when I'm writing new-style classes (which the pickle/copy machinery doesn't accept anything but a copy_reg registration or __reduce__ or __reduce_ex__) I don't generally consider my work to be an "extension class" and thus hadn't ever looked under that heading. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 12:54 Message: Logged In: YES user_id=80475 Would adding an index entry suffice? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=835521&group_id=5470 From noreply at sourceforge.net Fri Nov 28 12:56:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 12:56:13 2003 Subject: [ python-Feature Requests-829370 ] math.signum(int) Message-ID: Feature Requests item #829370, was opened at 2003-10-23 21:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=829370&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Voelkel (gekonntde) Assigned to: Nobody/Anonymous (nobody) Summary: math.signum(int) Initial Comment: python needs a signum function, def signum(self, int): if(int < 0): return -1; elif(int > 0): return 1; else: return int; ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 12:56 Message: Logged In: YES user_id=80475 With the use cases being infrequent and the pure python version being so easy, I think we ought to pass on this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=829370&group_id=5470 From noreply at sourceforge.net Fri Nov 28 14:48:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 14:48:52 2003 Subject: [ python-Bugs-848614 ] distutils can't build extensions with VC 6 Message-ID: Bugs item #848614, was opened at 2003-11-24 23:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 Category: Distutils Group: Python 2.2.3 Status: Open >Resolution: Fixed Priority: 6 Submitted By: Jim Fulton (dcjim) >Assigned to: Thomas Heller (theller) Summary: distutils can't build extensions with VC 6 Initial Comment: When trying to build Zope 3 on windows with Python 2.3.2, I got: C:\Documents and Settings\jim\Desktop\Zope3>\python23\python setup.py build_ext -i running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. But I have version 6 if Visual Studio installed. I tried this on two different machines and even tried reinstalling Visual Studio. Finally, I tried copying distutils from Python 2.2. Happily, that allowed me to compile Zope 3. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-28 20:48 Message: Logged In: YES user_id=11105 Committed to trunk and release23-maint branch. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-25 12:38 Message: Logged In: YES user_id=11105 I've attached a patch which tries to find out whether MSVC6 is installed if the registry entries are not found. If so, a warnning is printed in addition to the error mentioned above: It seems you have Visual Studio 6 installed, but the expected registry settings are not present. You must at least run the Visual Studio GUI once so that these entries are created. I do not know if DevStudio 7 has the same problem or not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-25 08:51 Message: Logged In: YES user_id=11105 Seems this is a common mistake: you have to start the MSVC6 gui *at least once*, otherwise the needed registry entries are not created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 From noreply at sourceforge.net Fri Nov 28 15:11:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 15:11:52 2003 Subject: [ python-Bugs-848614 ] distutils can't build extensions with VC 6 Message-ID: Bugs item #848614, was opened at 2003-11-24 23:21 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 Category: Distutils Group: Python 2.2.3 >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Jim Fulton (dcjim) Assigned to: Thomas Heller (theller) Summary: distutils can't build extensions with VC 6 Initial Comment: When trying to build Zope 3 on windows with Python 2.3.2, I got: C:\Documents and Settings\jim\Desktop\Zope3>\python23\python setup.py build_ext -i running build_ext error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. But I have version 6 if Visual Studio installed. I tried this on two different machines and even tried reinstalling Visual Studio. Finally, I tried copying distutils from Python 2.2. Happily, that allowed me to compile Zope 3. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-28 20:48 Message: Logged In: YES user_id=11105 Committed to trunk and release23-maint branch. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-25 12:38 Message: Logged In: YES user_id=11105 I've attached a patch which tries to find out whether MSVC6 is installed if the registry entries are not found. If so, a warnning is printed in addition to the error mentioned above: It seems you have Visual Studio 6 installed, but the expected registry settings are not present. You must at least run the Visual Studio GUI once so that these entries are created. I do not know if DevStudio 7 has the same problem or not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-11-25 08:51 Message: Logged In: YES user_id=11105 Seems this is a common mistake: you have to start the MSVC6 gui *at least once*, otherwise the needed registry entries are not created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848614&group_id=5470 From noreply at sourceforge.net Fri Nov 28 16:23:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 16:23:33 2003 Subject: [ python-Bugs-846133 ] os.chmod/os.utime/shutil do not work with unicode filenames Message-ID: Bugs item #846133, was opened at 2003-11-20 22:27 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) >Assigned to: Martin v. L?wis (loewis) Summary: os.chmod/os.utime/shutil do not work with unicode filenames Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-28 10:58 Message: Logged In: YES user_id=14198 I opened http://www.python.org/sf/846133 regarding os.utime, which I found via the "shutil" module, via SpamBayes, also on a Japanese system (see that bug for details), but then I saw this and decided to tackle them both. I rolled my fix for that in with a fix for chmod. I also hacked the test suite radically: * Creation of a test_support.TESTFN_UNICODE_UNENCODEABLE variable, which is a Unicode string that can *not* be encoded using the file system encoding. This will cause functions with 'encoding' support but without Unicode support (such as utime/chmod) to fail. * Made functions of all the test cases, so more combinations of unicode/encoded can be tested. Many are redundant, but that is OK. * Added shutil tests of the filenames * While I was there, converted to a unittest test. The new test case blows up with a couple of errors before the posixmodule patch is applied, and passes after. Note that shutil.move/copy etc can not handle being passed one string and one unicode arg, and therefore this combination is skipped. I'd like any opinions on whether this is a bug in shutil or not. Also note that the new comment in test_support.py regarding a potential bug in the 'mbcs' encoding - it appears as if it always works as though errors=ignore. Comments/reviews? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-24 23:21 Message: Logged In: YES user_id=21627 If you look at the source of os.chmod, it is not at all surprising that it does not work for characters outside the file system encoding: it is simply not implemented. Patches are welcome. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 01:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-21 17:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 01:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Fri Nov 28 16:57:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 16:57:08 2003 Subject: [ python-Bugs-849662 ] reading shelves is really slow Message-ID: Bugs item #849662, was opened at 2003-11-26 09:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=849662&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gottfried Gan?auge (ganssauge) Assigned to: Raymond Hettinger (rhettinger) Summary: reading shelves is really slow Initial Comment: My application uses a shelve-file which is created by another process using the same python version. Before python2.3 using this shelve with the exact same application was almost twice as fast as a binary pickle containing the same data. Now with python2.3 the same application is suddenly about 150 times slower than using the binary pickle. The usage is as follows: idx_dict = shelve.open (idx_dict_name, "r") ... while not infile.eof: index = get_index_from_somewhere_else() if not idx_dict.has_key (index): do_something(index) else: do_something_else(index) idx.dict.close() Profiling revealed that most of the time is spent within userdict. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 16:57 Message: Logged In: YES user_id=80475 Yes, that was the culprit. I'll look for a way to make __cmp__ a bit smarter. In the meantime, the proper way to check for None is always: if dict is None. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-28 11:01 Message: Logged In: YES user_id=792746 I think I found the answer: apart from has_key() I'm using "dict != None". If I leave that out in my test program both python variants run with the same speed. The dict != None condition seems to trigger len(dict.keys()) and that seems to be way slower than before. I definitely didn't time different scripts: the script is part of our CDROM production system and the only variables I had during my tests were python itself and the python path. Find my test script attached... ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-27 12:55 Message: Logged In: YES user_id=80475 The fragment in the original posting showed the only inner-loop shelve access was through has_key(). The tracebacks show that UserDict is nowhere in the traceback chain. I conclude that the fragment does not represent what is really going on in the problematic script. So, please attach the profiled script, Konvertierung/entsch_pass2.py The attached profile indicates that somewhere, there is a line like: for k,v in idx_dict.iteritems(). This is surprising because shelves did not support iteritems() in Py2.2. That would be mean that you've timed and compared two different pieces of code. Please show the shortest script with data that runs at radically different speeds on Py2.2 vs Py2.3. ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 05:42 Message: Logged In: YES user_id=792746 What the heck ... here is the shelve in question ---------------------------------------------------------------------- Comment By: Gottfried Gan?auge (ganssauge) Date: 2003-11-27 05:32 Message: Logged In: YES user_id=792746 I uploaded my profiling data, maybe it will help you ... Here is the information you requested: ----------------><------------------------><------------ (gotti@gglinux 534) PYTHONPATH=../../../COMMON.DEVEL/Tools/python/lib.linux- i686-2.3 python Konvertierung/entsch_pass2.py HI69228 x HR all_idx2.shelve Bugs item #850964, was opened at 2003-11-28 16:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Mueller (yuurei) Assigned to: Nobody/Anonymous (nobody) Summary: optparse: OptionParser.__init__'s "prog" argument ignored Initial Comment: optparse uses sys.argv[0] for the program name even if you supply the prog argument to OptionParser.__init__ ie, if you have p = OptionParser(prog='NEW_NAME'), p.print_usage, p.print_help, p.error, etc. don't use NEW_NAME as %prog. This is with Python 2.3.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 From noreply at sourceforge.net Fri Nov 28 19:28:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 19:28:36 2003 Subject: [ python-Bugs-850981 ] test_poll fails in 2.3.2 on MacOSX(Panther) Message-ID: Bugs item #850981, was opened at 2003-11-28 16:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails in 2.3.2 on MacOSX(Panther) Initial Comment: OSX 10.3 (Panther) Python 2.3.2 source ./configure make make test ... test test_poll crashed -- select.error: (9, 'Bad file descriptor') ... 228 tests OK. 1 test failed: test_poll 26 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_mpz test_nis test_normalization test_ossaudiodev test_pep277 test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_urllibnet test_winreg test_winsound Those skips are all expected on darwin. Need more info - just ask. --r ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470 From noreply at sourceforge.net Fri Nov 28 20:24:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 20:24:32 2003 Subject: [ python-Bugs-850997 ] mbcs encoding ignores errors Message-ID: Bugs item #850997, was opened at 2003-11-29 12: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=850997&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: mbcs encoding ignores errors Initial Comment: The following snippet: >>> u'@test-\u5171'.encode("mbcs", "strict") '@test-?' Should raise a UnicodeError. The errors param is completely ignored, and the function always works as though errors='replace'. Attaching a test case, and the start of a patch. The patch has a number of issues: * I'm not sure what errors are considered 'mandatory'. I have handled 'strict', 'ignore' and 'replace' - however, 'ignore' and 'replace' currently are exactly the same (ie, replace) * The Windows functions don't tell us exactly what character failed in the conversion. Thus, the exception I raise implies the first character is the one that failed. For the same reason, I have made no attempt to support error callbacks. Comments/guidance appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 From noreply at sourceforge.net Fri Nov 28 20:31:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 20:31:25 2003 Subject: [ python-Bugs-850997 ] mbcs encoding ignores errors Message-ID: Bugs item #850997, was opened at 2003-11-29 12:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Thomas Heller (theller) Summary: mbcs encoding ignores errors Initial Comment: The following snippet: >>> u'@test-\u5171'.encode("mbcs", "strict") '@test-?' Should raise a UnicodeError. The errors param is completely ignored, and the function always works as though errors='replace'. Attaching a test case, and the start of a patch. The patch has a number of issues: * I'm not sure what errors are considered 'mandatory'. I have handled 'strict', 'ignore' and 'replace' - however, 'ignore' and 'replace' currently are exactly the same (ie, replace) * The Windows functions don't tell us exactly what character failed in the conversion. Thus, the exception I raise implies the first character is the one that failed. For the same reason, I have made no attempt to support error callbacks. Comments/guidance appreciated. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-11-29 12:31 Message: Logged In: YES user_id=14198 Attaching a patch. This patch also attempts to handle Encode, but I haven't worked out how to exercise this code-path - ie, what mbcs encoded string can I pass that can not be converted to unicode? As I mentioned, patch has a few issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 From noreply at sourceforge.net Fri Nov 28 20:32:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 20:32:23 2003 Subject: [ python-Bugs-846133 ] os.chmod/os.utime/shutil do not work with unicode filenames Message-ID: Bugs item #846133, was opened at 2003-11-21 08:27 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eric Meyer (meyeet) Assigned to: Martin v. L?wis (loewis) Summary: os.chmod/os.utime/shutil do not work with unicode filenames Initial Comment: I have a filename that contains Kanji characters and I'm trying change the permissions on the file. I am running Python 2.3.1 on Windows 2000. Also I have the japanese language pack installed so that I can view the kanji characters in Windows explorer. >>> part u'\u5171\u6709\u3055\u308c\u308b.txt' >>> os.chmod(part, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?????.txt' >>> I attached the above named file for you to test against. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-11-29 12:32 Message: Logged In: YES user_id=14198 I created www.python.org/sf/850997 about the MBCS encoding issue. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-28 20:58 Message: Logged In: YES user_id=14198 I opened http://www.python.org/sf/846133 regarding os.utime, which I found via the "shutil" module, via SpamBayes, also on a Japanese system (see that bug for details), but then I saw this and decided to tackle them both. I rolled my fix for that in with a fix for chmod. I also hacked the test suite radically: * Creation of a test_support.TESTFN_UNICODE_UNENCODEABLE variable, which is a Unicode string that can *not* be encoded using the file system encoding. This will cause functions with 'encoding' support but without Unicode support (such as utime/chmod) to fail. * Made functions of all the test cases, so more combinations of unicode/encoded can be tested. Many are redundant, but that is OK. * Added shutil tests of the filenames * While I was there, converted to a unittest test. The new test case blows up with a couple of errors before the posixmodule patch is applied, and passes after. Note that shutil.move/copy etc can not handle being passed one string and one unicode arg, and therefore this combination is skipped. I'd like any opinions on whether this is a bug in shutil or not. Also note that the new comment in test_support.py regarding a potential bug in the 'mbcs' encoding - it appears as if it always works as though errors=ignore. Comments/reviews? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-11-25 09:21 Message: Logged In: YES user_id=21627 If you look at the source of os.chmod, it is not at all surprising that it does not work for characters outside the file system encoding: it is simply not implemented. Patches are welcome. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-22 11:51 Message: Logged In: YES user_id=671362 Hi, Eric. My previous post was maybe wrong. This is the problem of os.chmod. I've confirmed two kinds of exceptions are raised when using os.chmod for unicode filenames. The first one is [Errno 22] Invalid argument. You can read/write a file but cannot use os.chmod. The second one is [Errno 2] No such file or directory. Although there exists a file, Python complains "No such file or directory" test.test_codecs has a bunch of international unicode characters, so I borrowed them for testing. >>> import os >>> from test.test_codecs import punycode_testcases >>> def unicode_test(name): try: f = file(name, 'w') f.close() except IOError, e: print e return try: os.chmod(name, 0777) except OSError, e: print e >>> for i, (uni, puny) in enumerate (punycode_testcases): print i unicode_test(uni) I ran this script on Windows 2000(Japanese edition) using Python 2.3 and got "[Errno 22]" for 0,1,2,3,4,5,7,10 and "[Errno 2]" for 9. ---------------------------------------------------------------------- Comment By: Eric Meyer (meyeet) Date: 2003-11-22 03:18 Message: Logged In: YES user_id=913976 George, I tried the following but I had to specify one of the japanese codecs during the unicode() call. What is your default encoding set to? Below are my results. >>> import os >>> os.listdir('.') [] >>> u1 = unicode('\x82\xa0', 'cp932') >>> u2 = u'\x82\xa0' >>> u1, u2 (u'\u3042', u'\x82\xa0') >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['?'] >>> os.chmod(u1, 0777) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument: '?' ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-11-21 11:07 Message: Logged In: YES user_id=671362 I'm running Python in almost the same environment. I guess this results from the different bihavior of u'' and unicode(''). If you convert a multi-byte character to a unicode character, u'' and unicode('') don't return the same string. unicode'' works as intended but u'' doesn't. This is probably caused by the bug of Japanese codecs package. Eric, please try the session below and tell me what happens. NOTE: Japanese codecs needs to be installed to test the code below. Otherwise, UnicodeDecodeError will be raised. --- >>> import os >>> os.listdir('.') [] >>> lst = ['\x82', '\xa0'] # japanese character >>> u1 = unicode('\x82\xa0') >>> u2 = u'\x82\xa0' >>> u1 == u2 False >>> u1, u2 (u'\u3042', u'\x82\xa0') # u2 is odd >>> print >> file(u1, 'w'), "hello world" >>> os.listdir('.') ['あ'] >>> os.chmod(u1, 0777) >>> os.chmod(u2, 0777) Traceback (most recent call last): File "", line 1, in -toplevel- os.chmod(u2, 0777) OSError: [Errno 22] Invalid argument: '??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846133&group_id=5470 From noreply at sourceforge.net Fri Nov 28 20:43:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 20:43:32 2003 Subject: [ python-Bugs-851001 ] comparing reference looped lists causes RuntimeError Message-ID: Bugs item #851001, was opened at 2003-11-29 10: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=851001&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: comparing reference looped lists causes RuntimeError Initial Comment: On CVS HEAD Python(2.4), comparing reference looped lists causes RuntimeError. >>> import sys >>> print sys.version 2.4a0 (#1, Nov 28 2003, 11:18:42) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] >>> l = [] >>> l.append(l) >>> m = l[:] >>> l, m ([[...]], [[[...]]]) >>> l == m Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion depth exceeded in cmp >>> m == l Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion depth exceeded in cmp On Python 2.3 & 2.2, this doesn't happen. >>> import sys >>> print sys.version 2.3.2 (#1, Oct 6 2003, 10:07:16) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] >>> l = [] >>> l.append(l) >>> m = l[:] >>> l, m ([[...]], [[[...]]]) >>> l == m True The results of Python 2.2 is same as Python 2.3 except that True/False is denoted as 1/0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851001&group_id=5470 From noreply at sourceforge.net Fri Nov 28 20:56:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 20:56:10 2003 Subject: [ python-Bugs-848856 ] couple of new list.sort bugs Message-ID: Bugs item #848856, was opened at 2003-11-25 06:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Raymond Hettinger (rhettinger) Summary: couple of new list.sort bugs Initial Comment: I really feel I should apologise for this one: [mwh@pc150 build-debug]$ cat t.py class SortKiller(object): def __init__(self, i): pass def __del__(self): del l[:] l = range(10) l.sort(key=SortKiller) [mwh@pc150 build-debug]$ ./python t.py Segmentation fault This can be fixed by moving the "restoring the objects of the list from the wrappers" code *before* the "put saved_ob_item back in the list" code. The second is less serious but probably more annoying to fix: [mwh@pc150 build-debug]$ cat u.py def k(x): return 1/x l = range(-2,2) try: l.sort(key=k) except ZeroDivisionError: pass print l [mwh@pc150 build-debug]$ ./python u.py [, , 0, 1] [6571 refs] ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-28 20:56 Message: Logged In: YES user_id=80475 The second was easy to fix. The first is defying my attempts to fix it. You're welcome to take a crack at it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848856&group_id=5470 From noreply at sourceforge.net Fri Nov 28 22:17:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Nov 28 22:17:04 2003 Subject: [ python-Bugs-851020 ] building on Fedora Core 1 Message-ID: Bugs item #851020, was opened at 2003-11-28 22: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=851020&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael P. Soulier (msoulier) Assigned to: Nobody/Anonymous (nobody) Summary: building on Fedora Core 1 Initial Comment: I'm trying to build Python 2.3.2 on Fedora Core 1. The configure runs without errors, but I then get an odd error about pyconfig.h during the build. gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/dictobject.o Objects/dictobject.c In file included from Objects/dictobject.c:10: Include/Python.h:8:22: pyconfig.h: No such file or directory Include/Python.h:21:2: #error "limits.h is required by std C -- why isn't HAVE_LIMITS_H defined?" In file included from Include/Python.h:48, from Objects/dictobject.c:10: Include/pyport.h:4:48: pyconfig.h: No such file or directory Include/pyport.h:536:2: #error "could not set LONG_MAX in pyport.h" Objects/dictobject.c: In function `dictresize': Objects/dictobject.c:477: warning: implicit declaration of function `free' make: *** [Objects/dictobject.o] Error 1 [msoulier@tigger Python-2.3.2]$ find . -name pyconfig.h ./Mac/Include/pyconfig.h ./PC/pyconfig.h ./PC/os2emx/pyconfig.h ./PC/os2vacpp/pyconfig.h ./RISCOS/pyconfig.h ./pyconfig.h I'm not sure what the issue is here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851020&group_id=5470 From noreply at sourceforge.net Sat Nov 29 01:57:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 01:57:38 2003 Subject: [ python-Bugs-851056 ] winreg can segfault Message-ID: Bugs item #851056, was opened at 2003-11-29 01: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=851056&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: winreg can segfault Initial Comment: (I need this fixed before 2.3.3 since it is critical to something at work. I therefore promise to do it myself.) I tracked down a segfault on Windows (XP) in some windows registry traversal code I wrote. It uses _winreg.c, the crash is in PyEnumValue. I I think the cause is that the requested value was very large (several 100 KB) and the code does an alloca() for that much. I'm guessing this overflows the stack. The code needs to be rewritten to avoid alloca() I fear... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851056&group_id=5470 From noreply at sourceforge.net Sat Nov 29 03:39:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 03:40:07 2003 Subject: [ python-Bugs-851001 ] comparing reference looped lists causes RuntimeError Message-ID: Bugs item #851001, was opened at 2003-11-28 20:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851001&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: comparing reference looped lists causes RuntimeError Initial Comment: On CVS HEAD Python(2.4), comparing reference looped lists causes RuntimeError. >>> import sys >>> print sys.version 2.4a0 (#1, Nov 28 2003, 11:18:42) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] >>> l = [] >>> l.append(l) >>> m = l[:] >>> l, m ([[...]], [[[...]]]) >>> l == m Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion depth exceeded in cmp >>> m == l Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion depth exceeded in cmp On Python 2.3 & 2.2, this doesn't happen. >>> import sys >>> print sys.version 2.3.2 (#1, Oct 6 2003, 10:07:16) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] >>> l = [] >>> l.append(l) >>> m = l[:] >>> l, m ([[...]], [[[...]]]) >>> l == m True The results of Python 2.2 is same as Python 2.3 except that True/False is denoted as 1/0. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 03:39 Message: Logged In: YES user_id=80475 This is a feature. Quoth Misc/NEWS: Python no longer tries to be smart about recursive comparisons. When comparing containers with cyclic references to themselves it will now just hit the recursion limit. See SF patch 825639. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851001&group_id=5470 From noreply at sourceforge.net Sat Nov 29 03:44:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 03:44:13 2003 Subject: [ python-Bugs-848812 ] Inconsistent list.__add__/__addi__. Message-ID: Bugs item #848812, was opened at 2003-11-25 04:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistent list.__add__/__addi__. Initial Comment: >>> L = [1,2,3] >>> L + (1,2,3) Traceback (most recent call last): File "", line 1, in ? TypeError: can only concatenate list (not "tuple") to list >>> L += (1,2,3) >>> L [1, 2, 3, 1, 2, 3] I've always been somewhat annoyed that list.__add__ didn't accept any iterable (just lists), but to have += accept any iterable but not + is just plain inconsistent. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-11-29 03:44 Message: Logged In: YES user_id=80475 It's a feature, not a bug. The goal is to eliminate unattractive, error prone constructions. Probe the archives for past discussion and pronouncement on this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=848812&group_id=5470 From noreply at sourceforge.net Sat Nov 29 07:36:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 07:36:41 2003 Subject: [ python-Bugs-851123 ] shutil.copy destroys hard links Message-ID: Bugs item #851123, was opened at 2003-11-29 13:36 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=851123&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald Schlueter (gls62) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copy destroys hard links Initial Comment: Hi, I am using python2.3 on a debian linux (unstable) kernel Version 2.4.20. shell: cd /tmp cp /etc/passwd a ln a b cp a b *** a and b are the same file *** python import shutil shutil.copy("a", "b") The file is destroyed and cut down to 0 Bytes! Thank you, Gerry (gls62) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851123&group_id=5470 From noreply at sourceforge.net Sat Nov 29 09:05:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 09:05:41 2003 Subject: [ python-Bugs-851152 ] Item out of order on builtin function page Message-ID: Bugs item #851152, was opened at 2003-11-29 09:05 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=851152&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: Item out of order on builtin function page Initial Comment: On http://www.python.org/doc/current/lib/built-in-funcs.html, the str function is out of alphabetic order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851152&group_id=5470 From noreply at sourceforge.net Sat Nov 29 09:34:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 09:34:23 2003 Subject: [ python-Bugs-851156 ] Bug tracker page asks for login even when logged in Message-ID: Bugs item #851156, was opened at 2003-11-29 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=851156&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: Bug tracker page asks for login even when logged in Initial Comment: The bug tracker page (http://sourceforge.net/tracker/?atid=105470&group_id=5470&func=browse) asks the user to login even when I'm already logged in, i.e. it has the text: Please log into SourceForge to submit a new report. where "log into SourceForge" is a red link to the login page. I've tried other projects on SourceForge, and they don't have this text, which makes me think it's project specific. That's why I'm reporting it here (though I can't find an appropriate category). Also, it's the fact that other projects don't have this that makes me consider this to be a bug - I went around in circles trying to log in successfully until I realized, by checking with other projects, that this message didn't mean I wasn't logged in. I suggest getting rid of it entirely, which is what I see other projects doing (though I can't claim that two or three projects is a representative sample). Alternatively, change the wording to read "If you don't see 'Submit New' above, then you're not logged into to SourceForge. You can login ." Thanks, Gary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851156&group_id=5470 From noreply at sourceforge.net Sat Nov 29 10:18:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 10:18:50 2003 Subject: [ python-Bugs-850997 ] mbcs encoding ignores errors Message-ID: Bugs item #850997, was opened at 2003-11-29 02:24 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) >Assigned to: Nobody/Anonymous (nobody) Summary: mbcs encoding ignores errors Initial Comment: The following snippet: >>> u'@test-\u5171'.encode("mbcs", "strict") '@test-?' Should raise a UnicodeError. The errors param is completely ignored, and the function always works as though errors='replace'. Attaching a test case, and the start of a patch. The patch has a number of issues: * I'm not sure what errors are considered 'mandatory'. I have handled 'strict', 'ignore' and 'replace' - however, 'ignore' and 'replace' currently are exactly the same (ie, replace) * The Windows functions don't tell us exactly what character failed in the conversion. Thus, the exception I raise implies the first character is the one that failed. For the same reason, I have made no attempt to support error callbacks. Comments/guidance appreciated. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-11-29 16:18 Message: Logged In: YES user_id=11105 No idea why this was assigned to me - unicode is certainly not one of my strengths. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-11-29 02:31 Message: Logged In: YES user_id=14198 Attaching a patch. This patch also attempts to handle Encode, but I haven't worked out how to exercise this code-path - ie, what mbcs encoded string can I pass that can not be converted to unicode? As I mentioned, patch has a few issues ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850997&group_id=5470 From noreply at sourceforge.net Sat Nov 29 19:45:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 19:45:59 2003 Subject: [ python-Bugs-851152 ] Item out of order on builtin function page Message-ID: Bugs item #851152, was opened at 2003-11-29 09:05 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851152&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Feldman (garyfx) >Assigned to: Raymond Hettinger (rhettinger) Summary: Item out of order on builtin function page Initial Comment: On http://www.python.org/doc/current/lib/built-in-funcs.html, the str function is out of alphabetic order. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851152&group_id=5470 From noreply at sourceforge.net Sat Nov 29 19:46:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Nov 29 19:47:03 2003 Subject: [ python-Bugs-850964 ] optparse: OptionParser.__init__'s "prog" argument ignored Message-ID: Bugs item #850964, was opened at 2003-11-28 18:48 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Mueller (yuurei) >Assigned to: Greg Ward (gward) Summary: optparse: OptionParser.__init__'s "prog" argument ignored Initial Comment: optparse uses sys.argv[0] for the program name even if you supply the prog argument to OptionParser.__init__ ie, if you have p = OptionParser(prog='NEW_NAME'), p.print_usage, p.print_help, p.error, etc. don't use NEW_NAME as %prog. This is with Python 2.3.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 From noreply at sourceforge.net Sun Nov 30 00:40:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 00:40:38 2003 Subject: [ python-Bugs-851449 ] New-style classes with __eq__ but not __hash__ are hashable Message-ID: Bugs item #851449, was opened at 2003-11-30 00:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Edward Loper (edloper) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes with __eq__ but not __hash__ are hashable Initial Comment: According to the current reference docs, "If [a class] defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. [1] But this doesn't work quite like you'd think for new-style classes: Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... def __cmp__(self, other): return -1 >>> print {A():1} {<__main__.A object at 0x71cf0>: 1} The problem is that object defines a default __hash__ method: >>> print A.__hash__ So the dictionary class thinks that the object is hashable. But given that we've overridden cmp, there's no reason to believe that __hash__ is still valid. The only workaround I've found is to manually add a __hash__ method that raises the appropriate exception: >>> class A(object): ... def __cmp__(self, other): return -1 ... def __hash__(self): ... raise TypeError, ('%s objects are unhashable' % ... self.__class__) But it seems like this should be fixed in Python itself. I can think of 2 reasonable ways to fix it: - change object.__hash__() to raise a TypeError if __cmp__ or __eq__ is overridden. - change hash() to raise a TypeError if given an object that overrides __cmp__ or __eq__ but not __hash__. So.. Is this a real bug, or am I missing something? And if so, what's the prefered place to fix it? (I'd be happy to try to put together a patch for it, if it is indeed broken.) -Edward [1] http://www.python.org/doc/current/ref/ customization.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851449&group_id=5470 From noreply at sourceforge.net Sun Nov 30 14:26:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 14:26:15 2003 Subject: [ python-Bugs-850110 ] Out of order commands excecution? Message-ID: Bugs item #850110, was opened at 2003-11-27 08:54 Message generated for change (Comment added) made by nadavhoresh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Michael Hudson (mwh) Summary: Out of order commands excecution? Initial Comment: Consider the following: >>> import string >>> def test1(): join = string.join >>> def test2(): join = string.join string = string.split >>> test1() >>> test2() Traceback (most recent call last): File "", line 1, in -toplevel- test2() File "", line 2, in test2 join = string.join UnboundLocalError: local variable 'string' referenced before assignment >>> How the second statement in test2 generates an error in first one? Nadav. ---------------------------------------------------------------------- >Comment By: Nadav Horesh (nadavhoresh) Date: 2003-11-30 19:26 Message: Logged In: YES user_id=75473 I've looked at the FAQ and it is not seems to sesolve the issue: In test2 "string" becomes a local variable in the second line, while in the first line (join = string.join) "string" should point to the (global) string module. Nadav. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-11-27 12:09 Message: Logged In: YES user_id=6656 Well, that's just how it works. This must be documented somewhere... see if http://www.python.org/doc/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python helps (and maybe the question before). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850110&group_id=5470 From noreply at sourceforge.net Sun Nov 30 17:12:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 17:13:12 2003 Subject: [ python-Bugs-738973 ] urllib2 CacheFTPHandler doesn't work on multiple dirs Message-ID: Bugs item #738973, was opened at 2003-05-16 23:18 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738973&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Shahms E. King (shahms) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 CacheFTPHandler doesn't work on multiple dirs Initial Comment: using the CacheFTPHandler for ftp requests in urllib2 works as expected for files in the same directory as the original file, however, as ftpwrapper() changes the directory only after the initial connection, any urllib2.urlopen('ftp://...') that is in a different directory that the initial urlopen() call will fail with a "450: File Not Found" ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 22:12 Message: Logged In: YES user_id=261020 I've submitted a fix for this as patch 851736. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738973&group_id=5470 From noreply at sourceforge.net Sun Nov 30 17:13:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 17:13:20 2003 Subject: [ python-Bugs-851056 ] winreg can segfault Message-ID: Bugs item #851056, was opened at 2003-11-29 01:57 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851056&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: winreg can segfault Initial Comment: (I need this fixed before 2.3.3 since it is critical to something at work. I therefore promise to do it myself.) I tracked down a segfault on Windows (XP) in some windows registry traversal code I wrote. It uses _winreg.c, the crash is in PyEnumValue. I I think the cause is that the requested value was very large (several 100 KB) and the code does an alloca() for that much. I'm guessing this overflows the stack. The code needs to be rewritten to avoid alloca() I fear... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-30 17:13 Message: Logged In: YES user_id=6380 I've fixed this in 2.4 and 2.3. (I still need to do a test with a truly large registry value, but the only machine where I can reproduce this is not in my possession, so it may take a while). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=851056&group_id=5470 From noreply at sourceforge.net Sun Nov 30 17:18:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 17:19:01 2003 Subject: [ python-Bugs-820583 ] urllib2 silently returns None when auth_uri is mismatched Message-ID: Bugs item #820583, was opened at 2003-10-09 13:11 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Armstrong (radeex) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 silently returns None when auth_uri is mismatched Initial Comment: Code like the following, where the `uri' argument which I pass to add_password is not actually the URI that the web server gives me in its request for basic auth, makes the return value of OpenDirector.open None. This is either a code bug or a documentation bug. I expected director.open to raise an error, but saying something like "open will return None in these cases: ...." would also be a valid solution, if one that's not as good, IMO... the AuthHandler could raise an error once it realizes that none of the URIs we have match, perhaps? import urllib2 realm = "Linksys BEFW11S4 V4" passman = urllib2.HTTPPasswordMgr() passman.add_password(realm, 'NOT_WHAT_THE_SERVER_GIVES_ME', 'user', 'password') auther = urllib2.HTTPBasicAuthHandler(passman) getter = urllib2.HTTPHandler() director = urllib2.OpenerDirector() director.add_handler(auther) director.add_handler(getter) f = director.open('http://192.168.1.1/Status.htm') print f, "is None" ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 22:18 Message: Logged In: YES user_id=261020 Uploaded doc fix as patch 851752. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-29 23:56 Message: Logged In: YES user_id=261020 It's a doc bug. I'll add a doc patch later. Returning None from a handler means "I can't handle this, but another handler might". So AuthHandler is correct to return None, and shouldn't raise an exception. If you want to get a URLError in cases where all relevant handlers return None, you need to do: director.add_handler(UnknownHandler) (which build_opener will do for you, actually) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470 From noreply at sourceforge.net Sun Nov 30 18:24:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 18:24:18 2003 Subject: [ python-Bugs-745097 ] urllib2 doesn't handle urls without scheme Message-ID: Bugs item #745097, was opened at 2003-05-28 19:54 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle urls without scheme Initial Comment: urllib2.urlopen does not handle URLs without a scheme, so the following code will not work: url = urllib.pathname2url('/etc/passwd') urllib2.urlopen(url) The same code does work with urllib.urlopen. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-11-30 23:24 Message: Logged In: YES user_id=261020 Is it wise to allow this? Maybe it's unlikely to cause bugs, but "/etc/passwd" could refer to any URI scheme, not only file:. Since it seems reasonable to only allow absolute URLs, I think it's a bad idea to guess the scheme is file: when given a relative URL. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=745097&group_id=5470 From noreply at sourceforge.net Sun Nov 30 19:14:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 19:14:49 2003 Subject: [ python-Bugs-680577 ] urllib2 authentication problem Message-ID: Bugs item #680577, was opened at 2003-02-05 00:22 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&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: urllib2 authentication problem Initial Comment: I've found a problem using the authentication in urllib2. When matching up host-names in order to find a password, then putting the protocol in the address makes it seem like a different address. eg... I create a HTTPBasicAuthHandler with a HTTPPasswordMgrWithDefaultRealm, and add the tuple (None, "http://proxy.blah.com:17828", "foo", "bar") to it. I then setup the proxy to use http://proxy.blah.com:17828 (which requires authentication). When I connect, the password lookup fails, because it is trying to find a match for "proxy.blah.com:17828" rather than "http://proxy.blah.com:17828" This problem doesn't exist if I pass "proxy.blah.com:17828" to the password manager. There seems to be some stuff in HTTPPasswordMgr to deal with variations on site names, but I guess it's not working in this case (unless this is intentional). Version Info: Python 2.2 (#1, Feb 24 2002, 16:21:58) [GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)] on linux-i386 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-12-01 00:14 Message: Logged In: YES user_id=261020 The problem seems to be with the port (:17828), not the URL scheme (http:), because HTTPPasswordMgr.reduce_uri() removes the scheme. RFC 2617 (top of page 3) says nothing about removing the port from the URI. urllib2 does not remove the port, so this doesn't appear to be a bug. I guess gazzadee was doing a urlopen with a different canonical root URI (RFC 2617, top of page 3 again) to the one he gave in add_password (ie. the URL he passed to urlopen() had no explicit port number). ---------------------------------------------------------------------- Comment By: Gary Donovan (gazzadee) Date: 2003-02-09 23:17 Message: Logged In: YES user_id=693152 Okay, the same problem crops up in Python 2.2.2 running under cygwin on Win XP Version Info: Python 2.2.2 (#1, Dec 31 2002, 12:24:34) [GCC 3.2 20020927 (prerelease)] on cygwin Here's the pertinent section of my test file (passwords and URL changed to protect the innocent): # Setup proxy proxy_handler = ProxyHandler({"http" : "http://blah.com:17828"}) # Setup authentication pass_mgr = HTTPPasswordMgrWithDefaultRealm() for passwd in [ (None, "http://blah.com:17828", "foo", "bar"), # (None, "blah.com:17828", "foo", "bar"), \ # Works if this line is uncommented (None, "blah.com", "foo", "bar"), ]: print("Adding password set (%s, %s, %s, %s)" % passwd) pass_mgr.add_password(*passwd) auth_handler = HTTPBasicAuthHandler(pass_mgr) proxy_auth_handler = ProxyBasicAuthHandler(pass_mgr) # Now build a new URL opener and install it opener = build_opener(proxy_handler, proxy_auth_handler, auth_handler, HTTPHandler) install_opener(opener) # Now try to open a file and see what happens request = Request("http://www.google.com") try: remotefile = urlopen(request) except HTTPError, ex: print("Unable to download file due to HTTP Error %d (%s)." % (ex.code, ex.msg)) return ---------------------------------------------------------------------- Comment By: Gerhard H?ring (ghaering) Date: 2003-02-07 23:21 Message: Logged In: YES user_id=163326 Can you please retry with Python 2.2.2? It seems that a related bug was fixed for 2.2.2: http://python.org/2.2.2/NEWS.txt has an entry: """ - In urllib2.py: fix proxy config with user+pass authentication. [SF patch 527518] """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=680577&group_id=5470 From noreply at sourceforge.net Sun Nov 30 19:47:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Nov 30 19:47:51 2003 Subject: [ python-Bugs-835145 ] [2.3.2] zipfile test failure on AIX 5.1 Message-ID: Bugs item #835145, was opened at 2003-11-03 08:06 Message generated for change (Comment added) made by tww-china You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: [2.3.2] zipfile test failure on AIX 5.1 Initial Comment: $ cd /opt/build/Python-2.3.2 $ ./python -E -tt Lib/test/test_zipfile.py Traceback (most recent call last): File "Lib/test/test_zipfile.py", line 35, in ? zipTest(file, zipfile.ZIP_STORED, writtenData) File "Lib/test/test_zipfile.py", line 13, in zipTest zip.close() File "/opt/build/Python-2.3.2/Lib/zipfile.py", line 503, in close zinfo.header_offset) OverflowError: long int too large to convert Exception exceptions.OverflowError: 'long int too large to convert' in > ignored The test passes just fine on AIX 4.3.2. This is against a Python built with the IBM v6 C compiler and GCC 3.3.2. I added some debugging print statements to Lib/zipfile.py and it seems that zinfo.external_attr is out of whack. On AIX 4.3.2, the value for this variable is "2176057344" while on AIX 5.1 it is "10765991936". I tracked this back to the following line in the write method of Lib/zipfile.py: zinfo.external_attr = st[0] << 16L # Unix attributes On AIX 4.3.2, st[0] is 33204 while on AIX 5.1 it is 164276. In python 2.2.x, it was '<< 16' which resulted in a signed value on AIX 5.1. I really don't think you can use the 16L as mode_t on AIX is unsigned int. Ditto for other platforms. Why not just store st[0] unchanged? ---------------------------------------------------------------------- >Comment By: The Written Word (Albert Chin) (tww-china) Date: 2003-11-30 15:47 Message: Logged In: YES user_id=119770 Ok, your (st[0] & 0xffff) change should be ok. AIX has several file systems available, among them JFS and JFS2. zipfile.py works fine on JFS and NFS file systems but not JFS2. The 0xffff change throws away the extra bits but it shouldn't matter. I checked the zip source and they don't & with 0xffff but they have the same problem. However, because the shift by 16 is constrained by the maxint(unsigned short), we don't run into the same problem with the zip source as with Python which promotes the int to a long. ---------------------------------------------------------------------- Comment By: The Written Word (Albert Chin) (tww-china) Date: 2003-11-13 10:51 Message: Logged In: YES user_id=119770 The suggestion works. I want to look through the zip-2.3 source though. I'll do so this weekend. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-13 10:11 Message: Logged In: YES user_id=6380 So Albert, any luck with my suggestion? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-11-10 07:43 Message: Logged In: YES user_id=6380 It looks like what is happening is that the mode returned by stat() has a bit beyond the 16th set. I'm guessing that those extra bits should be ignored -- there is no room for them in the header it seems. Could you try replacing st[0] with (st[0] & 0xffff) in that expression and then try again? (Hm, I wonder why the Unix mode is left-shifted 16 bits. Maybe the real definition of "external attributes" is a bit different? What is supposed to be stored in those lower 16 bits that always appear to be zero? I don't have time to research this.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835145&group_id=5470 From noreply at sourceforge.net Tue Nov 18 18:07:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Dec 13 09:19:03 2003 Subject: [ 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: Closed >Resolution: Fixed 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-11-19 00:06 Message: Logged In: YES user_id=92689 So the problem was the test. Fixed in the trunk in rev. 1.11, and 1.10.4.1 in the release23-maint branch. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-08-29 16:43 Message: Logged In: YES user_id=200117 >>> import sys >>> print "zlib" in sys.builtin_module_names This gives 'True' on HP-UX11i. I edited the zlib line in Modules/Setup when I built Python2.3. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-08-29 16:26 Message: Logged In: YES user_id=92689 Wait, is the zlib module perhaps statically linked on these platforms? >>> import sys >>> print "zlib" in sys.builtin_module_names ? ---------------------------------------------------------------------- Comment By: Shawn Leard (sleard1) Date: 2003-08-29 15:43 Message: Logged In: YES user_id=328879 Below is the output of this problem on Solaris 8 with gcc 3.3.1. vette$ ./python -v Lib/test/test_zipimport.py # installing zipimport hook import zipimport # builtin # installed zipimport hook # /files/local/src/Python-2.3/Lib/site.pyc matches /files/local/src/Python-2.3/Lib/site.py import site # precompiled from /files/local/src/Python-2.3/Lib/site.pyc # /files/local/src/Python-2.3/Lib/os.pyc matches /files/local/src/Python-2.3/Lib/os.py import os # precompiled from /files/local/src/Python-2.3/Lib/os.pyc import posix # builtin # /files/local/src/Python-2.3/Lib/posixpath.pyc matches /files/local/src/Python-2.3/Lib/posixpath.py import posixpath # precompiled from /files/local/src/Python-2.3/Lib/posixpath.pyc # /files/local/src/Python-2.3/Lib/stat.pyc matches /files/local/src/Python-2.3/Lib/stat.py import stat # precompiled from /files/local/src/Python-2.3/Lib/stat.pyc # /files/local/src/Python-2.3/Lib/UserDict.pyc matches /files/local/src/Python-2.3/Lib/UserDict.py import UserDict # precompiled from /files/local/src/Python-2.3/Lib/UserDict.pyc # /files/local/src/Python-2.3/Lib/copy_reg.pyc matches /files/local/src/Python-2.3/Lib/copy_reg.py import copy_reg # precompiled from /files/local/src/Python-2.3/Lib/copy_reg.pyc # /files/local/src/Python-2.3/Lib/types.pyc matches /files/local/src/Python-2.3/Lib/types.py import types # precompiled from /files/local/src/Python-2.3/Lib/types.pyc import distutils # directory /files/local/src/Python-2.3/Lib/distutils # /files/local/src/Python-2.3/Lib/distutils/__init__.pyc matches /files/local/src/Python-2.3/Lib/distutils/__init__.py import distutils # precompiled from /files/local/src/Python-2.3/Lib/distutils/__init__.pyc # /files/local/src/Python-2.3/Lib/distutils/util.pyc matches /files/local/src/Python-2.3/Lib/distutils/util.py import distutils.util # precompiled from /files/local/src/Python-2.3/Lib/distutils/util.pyc # /files/local/src/Python-2.3/Lib/string.pyc matches /files/local/src/Python-2.3/Lib/string.py import string # precompiled from /files/local/src/Python-2.3/Lib/string.pyc # /files/local/src/Python-2.3/Lib/re.pyc matches /files/local/src/Python-2.3/Lib/re.py import re # precompiled from /files/local/src/Python-2.3/Lib/re.pyc # /files/local/src/Python-2.3/Lib/sre.pyc matches /files/local/src/Python-2.3/Lib/sre.py import sre # precompiled from /files/local/src/Python-2.3/Lib/sre.pyc # /files/local/src/Python-2.3/Lib/sre_compile.pyc matches /files/local/src/Python-2.3/Lib/sre_compile.py import sre_compile # precompiled from /files/local/src/Python-2.3/Lib/sre_compile.pyc import _sre # builtin # /files/local/src/Python-2.3/Lib/sre_constants.pyc matches /files/local/src/Python-2.3/Lib/sre_constants.py import sre_constants # precompiled from /files/local/src/Python-2.3/Lib/sre_constants.pyc # /files/local/src/Python-2.3/Lib/sre_parse.pyc matches /files/local/src/Python-2.3/Lib/sre_parse.py import sre_parse # precompiled from /files/local/src/Python-2.3/Lib/sre_parse.pyc # /files/local/src/Python-2.3/Lib/distutils/errors.pyc matches /files/local/src/Python-2.3/Lib/distutils/errors.py import distutils.errors # precompiled from /files/local/src/Python-2.3/Lib/distutils/errors.pyc # /files/local/src/Python-2.3/Lib/distutils/dep_util.pyc matches /files/local/src/Python-2.3/Lib/distutils/dep_util.py import distutils.dep_util # precompiled from /files/local/src/Python-2.3/Lib/distutils/dep_util.pyc # /files/local/src/Python-2.3/Lib/distutils/spawn.pyc matches /files/local/src/Python-2.3/Lib/distutils/spawn.py import distutils.spawn # precompiled from /files/local/src/Python-2.3/Lib/distutils/spawn.pyc # /files/local/src/Python-2.3/Lib/distutils/log.pyc matches /files/local/src/Python-2.3/Lib/distutils/log.py import distutils.log # precompiled from /files/local/src/Python-2.3/Lib/distutils/log.pyc # /files/local/src/Python-2.3/Lib/warnings.pyc matches /files/local/src/Python-2.3/Lib/warnings.py import warnings # precompiled from /files/local/src/Python-2.3/Lib/warnings.pyc # /files/local/src/Python-2.3/Lib/linecache.pyc matches /files/local/src/Python-2.3/Lib/linecache.py import linecache # precompiled from /files/local/src/Python-2.3/Lib/linecache.pyc import encodings # directory /files/local/src/Python-2.3/Lib/encodings # /files/local/src/Python-2.3/Lib/encodings/__init__.pyc matches /files/local/src/Python-2.3/Lib/encodings/__init__.py import encodings # precompiled from /files/local/src/Python-2.3/Lib/encodings/__init__.pyc # /files/local/src/Python-2.3/Lib/codecs.pyc matches /files/local/src/Python-2.3/Lib/codecs.py import codecs # precompiled from /files/local/src/Python-2.3/Lib/codecs.pyc import _codecs # builtin # /files/local/src/Python-2.3/Lib/encodings/iso8859_1.pyc matches /files/local/src/Python-2.3/Lib/encodings/iso8859_1.py import encodings.iso8859_1 # precompiled from /files/local/src/Python-2.3/Lib/encodings/iso8859_1.pyc Python 2.3 (#2, Aug 27 2003, 18:12:40) [GCC 3.3.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. import marshal # builtin import imp # builtin dlopen("/files/local/src/Python-2.3/build/lib.solaris-2.8-sun4u-2.3/struct.so", 2); import struct # dynamically loaded from /files/local/src/Python-2.3/build/lib.solaris-2.8-sun4u-2.3/struct.so dlopen("/files/local/src/Python-2.3/build/lib.solaris-2.8-sun4u-2.3/time.so", 2); import time # dynamically loaded from /files/local/src/Python-2.3/build/lib.solaris-2.8-sun4u-2.3/time.so # /files/local/src/Python-2.3/Lib/zipfile.pyc matches /files/local/src/Python-2.3/Lib/zipfile.py import zipfile # precompiled from /files/local/src/Python-2.3/Lib/zipfile.pyc dlopen("/files/local/src/Python-2.3/build/lib.solaris-2.8-sun4u-2.3/binascii.so", 2); import binascii # dynamically loaded from /files/local/src/Python-2.3/build/lib.solaris-2.8-sun4u-2.3/binascii.so import zlib # builtin import test # directory /files/local/src/Python-2.3/Lib/test # /files/local/src/Python-2.3/Lib/test/__init__.pyc matches /files/local/src/Python-2.3/Lib/test/__init__.py import test # precompiled from /files/local/src/Python-2.3/Lib/test/__init__.pyc # /files/local/src/Python-2.3/Lib/test/test_support.pyc matches /files/local/src/Python-2.3/Lib/test/test_support.py import test.test_support # precompiled from /files/local/src/Python-2.3/Lib/test/test_support.pyc # /files/local/src/Python-2.3/Lib/unittest.pyc matches /files/local/src/Python-2.3/Lib/unittest.py import unittest # precompiled from /files/local/src/Python-2.3/Lib/unittest.pyc # /files/local/src/Python-2.3/Lib/traceback.pyc matches /files/local/src/Python-2.3/Lib/traceback.py import traceback # precompiled from /files/local/src/Python-2.3/Lib/traceback.pyc # /files/local/src/Python-2.3/Lib/test/test_importhooks.pyc matches /files/local/src/Python-2.3/Lib/test/test_importhooks.py import test.test_importhooks # precompiled from /files/local/src/Python-2.3/Lib/test/test_importhooks.pyc import zlib # previously loaded (zlib) testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip # /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc has bad mtime import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testBadMTime (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip # /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc has bad magic import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testBadMagic (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip # /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc has bad magic testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc testBoth (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 3 names in /files/local/src/Python-2.3/junk95142.zip import ziptestpackage # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestpackage2 # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/ziptestpackage2/__init__.pyc import ziptestpackage.ziptestpackage2.ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/ziptestpackage2/ziptestmodule.pyc testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip testGetData (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testImport_WithStuff (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import ziptestpackage # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/ziptestmodule.pyc testPackage (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testPy (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc testPyc (__main__.UncompressedZipImportTestCase) ... ok import zlib # previously loaded (zlib) testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import zlib # previously loaded (zlib) # zipimport: zlib available # /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc has bad mtime import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testBadMTime (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip # /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc has bad magic import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testBadMagic (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip # /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc has bad magic testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc testBoth (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 3 names in /files/local/src/Python-2.3/junk95142.zip import ziptestpackage # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestpackage2 # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/ziptestpackage2/__init__.pyc import ziptestpackage.ziptestpackage2.ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/ziptestpackage2/ziptestmodule.pyc testDeepPackage (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testEmptyPy (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip testGetData (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testImport_WithStuff (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc testImporterAttr (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /files/local/src/Python-2.3/junk95142.zip import ziptestpackage # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestpackage/ziptestmodule.pyc testPackage (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.py testPy (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /files/local/src/Python-2.3/junk95142.zip import ziptestmodule # loaded from Zip /files/local/src/Python-2.3/junk95142.zip/ziptestmodule.pyc testPyc (__main__.CompressedZipImportTestCase) ... ok ====================================================================== ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/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 "Lib/test/test_zipimport.py", line 102, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 78, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ---------------------------------------------------------------------- Ran 26 tests in 0.221s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 215, in ? test_main() File "Lib/test/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 # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] distutils # cleanup[1] encodings # cleanup[1] site # cleanup[1] distutils.util # cleanup[1] distutils.dep_util # cleanup[1] sre_constants # cleanup[1] re # cleanup[1] _codecs # cleanup[1] test # cleanup[1] zipimport # cleanup[1] warnings # cleanup[1] zipfile # cleanup[1] struct # cleanup[1] sre # cleanup[1] signal # cleanup[1] distutils.errors # cleanup[1] marshal # cleanup[1] distutils.spawn # cleanup[1] posix # cleanup[1] exceptions # cleanup[1] sre_parse # cleanup[1] encodings.iso8859_1 # cleanup[1] distutils.log # cleanup[1] sre_compile # cleanup[1] _sre # cleanup[1] test.test_importhooks # cleanup[1] test.test_support # cleanup[1] imp # cleanup[1] binascii # cleanup[1] codecs # cleanup[1] unittest # cleanup[1] string # cleanup[1] time # cleanup[1] traceback # cleanup[1] types # cleanup[1] linecache # cleanup[2] copy_reg # cleanup[2] posixpath # cleanup[2] os.path # cleanup[2] stat # cleanup[2] UserDict # cleanup[2] os # cleanup sys # cleanup __builtin__ [7751 refs] # cleanup ints: 11 unfreed ints in 8 out of 113 blocks # cleanup floats vette$ ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-08-29 14:32 Message: Logged In: YES user_id=200117 Hi Just, Here is the output: capulet:Lib/test > ../../python -v test_zipimport.py # installing zipimport hook import zipimport # builtin # installed zipimport hook # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/site.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/site.py import site # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/site.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/os.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/os.py import os # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/os.pyc import posix # builtin # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/posixpath.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/posixpath.py import posixpath # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/posixpath.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/stat.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/stat.py import stat # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/stat.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/UserDict.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/UserDict.py import UserDict # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/UserDict.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/copy_reg.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/copy_reg.py import copy_reg # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/copy_reg.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/types.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/types.py import types # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/../../Lib/types.pyc import distutils # directory /home/richardt/python.new/Python-2.3/Lib/distutils # /home/richardt/python.new/Python- 2.3/Lib/distutils/__init__.pyc matches /home/richardt/python.new/Python- 2.3/Lib/distutils/__init__.py import distutils # precompiled from /home/richardt/python.new/Python- 2.3/Lib/distutils/__init__.pyc # /home/richardt/python.new/Python-2.3/Lib/distutils/util.pyc matches /home/richardt/python.new/Python- 2.3/Lib/distutils/util.py import distutils.util # precompiled from /home/richardt/python.new/Python- 2.3/Lib/distutils/util.pyc # /home/richardt/python.new/Python-2.3/Lib/string.pyc matches /home/richardt/python.new/Python-2.3/Lib/string.py import string # precompiled from /home/richardt/python.new/Python-2.3/Lib/string.pyc # /home/richardt/python.new/Python-2.3/Lib/re.pyc matches /home/richardt/python.new/Python-2.3/Lib/re.py import re # precompiled from /home/richardt/python.new/Python-2.3/Lib/re.pyc # /home/richardt/python.new/Python-2.3/Lib/sre.pyc matches /home/richardt/python.new/Python-2.3/Lib/sre.py import sre # precompiled from /home/richardt/python.new/Python-2.3/Lib/sre.pyc # /home/richardt/python.new/Python-2.3/Lib/sre_compile.pyc matches /home/richardt/python.new/Python- 2.3/Lib/sre_compile.py import sre_compile # precompiled from /home/richardt/python.new/Python- 2.3/Lib/sre_compile.pyc import _sre # builtin # /home/richardt/python.new/Python- 2.3/Lib/sre_constants.pyc matches /home/richardt/python.new/Python- 2.3/Lib/sre_constants.py import sre_constants # precompiled from /home/richardt/python.new/Python- 2.3/Lib/sre_constants.pyc # /home/richardt/python.new/Python-2.3/Lib/sre_parse.pyc matches /home/richardt/python.new/Python- 2.3/Lib/sre_parse.py import sre_parse # precompiled from /home/richardt/python.new/Python-2.3/Lib/sre_parse.pyc # /home/richardt/python.new/Python- 2.3/Lib/distutils/errors.pyc matches /home/richardt/python.new/Python- 2.3/Lib/distutils/errors.py import distutils.errors # precompiled from /home/richardt/python.new/Python- 2.3/Lib/distutils/errors.pyc # /home/richardt/python.new/Python- 2.3/Lib/distutils/dep_util.pyc matches /home/richardt/python.new/Python- 2.3/Lib/distutils/dep_util.py import distutils.dep_util # precompiled from /home/richardt/python.new/Python- 2.3/Lib/distutils/dep_util.pyc # /home/richardt/python.new/Python- 2.3/Lib/distutils/spawn.pyc matches /home/richardt/python.new/Python- 2.3/Lib/distutils/spawn.py import distutils.spawn # precompiled from /home/richardt/python.new/Python- 2.3/Lib/distutils/spawn.pyc # /home/richardt/python.new/Python-2.3/Lib/distutils/log.pyc matches /home/richardt/python.new/Python- 2.3/Lib/distutils/log.py import distutils.log # precompiled from /home/richardt/python.new/Python- 2.3/Lib/distutils/log.pyc # /home/richardt/python.new/Python-2.3/Lib/warnings.pyc matches /home/richardt/python.new/Python- 2.3/Lib/warnings.py import warnings # precompiled from /home/richardt/python.new/Python-2.3/Lib/warnings.pyc # /home/richardt/python.new/Python-2.3/Lib/linecache.pyc matches /home/richardt/python.new/Python- 2.3/Lib/linecache.py import linecache # precompiled from /home/richardt/python.new/Python-2.3/Lib/linecache.pyc import encodings # directory /home/richardt/python.new/Python- 2.3/Lib/encodings # /home/richardt/python.new/Python- 2.3/Lib/encodings/__init__.pyc matches /home/richardt/python.new/Python- 2.3/Lib/encodings/__init__.py import encodings # precompiled from /home/richardt/python.new/Python- 2.3/Lib/encodings/__init__.pyc # /home/richardt/python.new/Python-2.3/Lib/codecs.pyc matches /home/richardt/python.new/Python- 2.3/Lib/codecs.py import codecs # precompiled from /home/richardt/python.new/Python-2.3/Lib/codecs.pyc import _codecs # builtin # /home/richardt/python.new/Python- 2.3/Lib/encodings/aliases.pyc matches /home/richardt/python.new/Python- 2.3/Lib/encodings/aliases.py import encodings.aliases # precompiled from /home/richardt/python.new/Python- 2.3/Lib/encodings/aliases.pyc Python 2.3 (#4, Aug 28 2003, 14:10:33) [C] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. import marshal # builtin import imp # builtin shl_load /home/richardt/python.new/Python-2.3/build/lib.hp- ux-B.11.11-9000/785-2.3/struct.sl shl_findsym initstruct import struct # dynamically loaded from /home/richardt/python.new/Python-2.3/build/lib.hp-ux- B.11.11-9000/785-2.3/struct.sl shl_load /home/richardt/python.new/Python-2.3/build/lib.hp- ux-B.11.11-9000/785-2.3/time.sl shl_findsym inittime import time # dynamically loaded from /home/richardt/python.new/Python-2.3/build/lib.hp-ux- B.11.11-9000/785-2.3/time.sl import zlib # builtin # /home/richardt/python.new/Python-2.3/Lib/zipfile.pyc matches /home/richardt/python.new/Python-2.3/Lib/zipfile.py import zipfile # precompiled from /home/richardt/python.new/Python-2.3/Lib/zipfile.pyc shl_load /home/richardt/python.new/Python-2.3/build/lib.hp- ux-B.11.11-9000/785-2.3/binascii.sl shl_findsym initbinascii import binascii # dynamically loaded from /home/richardt/python.new/Python-2.3/build/lib.hp-ux- B.11.11-9000/785-2.3/binascii.sl import test # directory /home/richardt/python.new/Python- 2.3/Lib/test # /home/richardt/python.new/Python- 2.3/Lib/test/__init__.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/__init__.py import test # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/__init__.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/test_support.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/test_support.py import test.test_support # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/test_support.pyc # /home/richardt/python.new/Python-2.3/Lib/unittest.pyc matches /home/richardt/python.new/Python- 2.3/Lib/unittest.py import unittest # precompiled from /home/richardt/python.new/Python-2.3/Lib/unittest.pyc # /home/richardt/python.new/Python-2.3/Lib/traceback.pyc matches /home/richardt/python.new/Python- 2.3/Lib/traceback.py import traceback # precompiled from /home/richardt/python.new/Python- 2.3/Lib/traceback.pyc # /home/richardt/python.new/Python- 2.3/Lib/test/test_importhooks.pyc matches /home/richardt/python.new/Python- 2.3/Lib/test/test_importhooks.py import test.test_importhooks # precompiled from /home/richardt/python.new/Python- 2.3/Lib/test/test_importhooks.pyc import zlib # previously loaded (zlib) testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip # /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc has bad mtime import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testBadMTime (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip # /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc has bad magic import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testBadMagic (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip # /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc has bad magic testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc testBoth (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 3 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestpackage # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestpackage2 # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/ziptestpackage2/__i nit__.pyc import ziptestpackage.ziptestpackage2.ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/ziptestpackage2/zip testmodule.pyc testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip testGetData (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testImport_WithStuff (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestpackage # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/ziptestmodule.pyc testPackage (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testPy (__main__.UncompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc testPyc (__main__.UncompressedZipImportTestCase) ... ok import zlib # previously loaded (zlib) testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import zlib # previously loaded (zlib) # zipimport: zlib available # /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc has bad mtime import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testBadMTime (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip # /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc has bad magic import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testBadMagic (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip # /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc has bad magic testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc testBoth (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 3 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestpackage # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestpackage2 # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/ziptestpackage2/__i nit__.pyc import ziptestpackage.ziptestpackage2.ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/ziptestpackage2/zip testmodule.pyc testDeepPackage (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testEmptyPy (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip testGetData (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testImport_WithStuff (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc testImporterAttr (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 2 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestpackage # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/__init__.pyc import ziptestpackage.ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestpackage/ziptestmodule.pyc testPackage (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.py testPy (__main__.CompressedZipImportTestCase) ... ok # zipimport: found 1 names in /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip import ziptestmodule # loaded from Zip /home/richardt/python.new/Python- 2.3/Lib/test/junk95142.zip/ziptestmodule.pyc 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.287s 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 "/home/richardt/python.new/Python- 2.3/Lib/test/test_support.py", line 262, in run_unittest run_suite(suite, testclass) File "/home/richardt/python.new/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 # clear __builtin__._ # clear sys.path # clear sys.argv # clear sys.ps1 # clear sys.ps2 # clear sys.exitfunc # clear sys.exc_type # clear sys.exc_value # clear sys.exc_traceback # clear sys.last_type # clear sys.last_value # clear sys.last_traceback # clear sys.path_hooks # clear sys.path_importer_cache # clear sys.meta_path # restore sys.stdin # restore sys.stdout # restore sys.stderr # cleanup __main__ # cleanup[1] distutils # cleanup[1] encodings # cleanup[1] site # cleanup[1] distutils.util # cleanup[1] distutils.dep_util # cleanup[1] sre_constants # cleanup[1] re # cleanup[1] _codecs # cleanup[1] test # cleanup[1] zipimport # cleanup[1] warnings # cleanup[1] zipfile # cleanup[1] codecs # cleanup[1] struct # cleanup[1] sre # cleanup[1] signal # cleanup[1] distutils.errors # cleanup[1] marshal # cleanup[1] distutils.spawn # cleanup[1] posix # cleanup[1] encodings.aliases # cleanup[1] exceptions # cleanup[1] sre_parse # cleanup[1] distutils.log # cleanup[1] sre_compile # cleanup[1] _sre # cleanup[1] test.test_importhooks # cleanup[1] test.test_support # cleanup[1] imp # cleanup[1] binascii # cleanup[1] unittest # cleanup[1] string # cleanup[1] time # cleanup[1] traceback # cleanup[1] types # cleanup[1] linecache # cleanup[2] copy_reg # cleanup[2] posixpath # cleanup[2] os.path # cleanup[2] stat # cleanup[2] UserDict # cleanup[2] os # cleanup sys # cleanup __builtin__ # cleanup ints: 11 unfreed ints in 7 out of 108 blocks # cleanup floats capulet:Lib/test > [there aren't any widgets at the bottom of this web page for attaching a file, do they only appear for the originator?] ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-08-29 10:43 Message: Logged In: YES user_id=92689 Hm, I seem to be able to reproduce the problem if I remove these lines if "zlib" in sys.modules: del sys.modules["zlib"] from the offending testAFakeZlib method (line 98 and 99 in test_zipimport.py). rptownsend: could you run test_zipimport.py with python -v, and attach the output as a file to this bug? Maybe that gives us a clue as to what is going on. ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-08-29 09:21 Message: Logged In: YES user_id=200117 I also get this error using Python2.3 (final release) on HP- UX11i ---------------------------------------------------------------------- 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